适合C# Actor的消息执行方式（2）：C# Actor的尴尬

核心提示： 有朋友可能会说，C#既然是一门强类型的语言，适合C# Actor的消息执行方式（2）：C# Actor的尴尬(5)，为什么要学Erlang的Tag Message？为什么不把Ping定义为Actor<PingMessage>，同时把Pong定义为Actor<PingMessag

有朋友可能会说，C#既然是一门强类型的语言，为什么要学Erlang的Tag Message？为什么不把Ping定义为Actor<PingMessage>，同时把Pong定义为Actor<PingMessage>呢？

呃……我承认，在这里使用Tag Message的确有种“画虎不成反类犬”的味道。不过，事情也不是您想象的那么简单。因为在实际情况中，一个Actor可能与各种外部服务打交道，它会接受到各式各样的消息。例如，它先向Service Locator发送一个请求，用于查询数据服务的位置，这样它会接受到一个ServiceLocatorResponse消息。然后，它会向数据服务发送一个请求，再接受到一个DataAccessResponse消息。也就是说，很可能我们必须把每个Actor都定义为Actor<object>，然后对消息进行类型判断，转换，再加以处理。

诚然，这种方法相对于Tag Message拥有了一定的强类型优势（如静态检查）。但是如果您选择这么做，就必须为各种消息定义不同的类型，在这方面会带来额外的开发成本。要知道，消息的数量并不等于Actor类型的数量，即使是如Ping这样简单的Actor，都会发送两种不同的消息（Ping和Finished），而且每种消息拥有各自的参数。一般来说，某个Actor会接受2-3种消息都是比较正常的状况。在面对消息类型的汪洋时，您可能就会怀念Tag Message这种做法了。到时候您可能就会发牢骚说：

“弱类型就弱类型吧，Erlang不也用的好好的么……”

F#中的模式匹配

提到模式匹配，熟悉F#的同学们可能会欢喜不已。模式匹配是F#中的重要特性，它将F#中静态类型系统的灵活性体现地淋漓尽致。而且——它还很能节省代码（这点在老赵以前的文章中也有所提及）。那么我们再来看一次F#在乒乓测试中的表现。