适合C# Actor的消息执行方式（4）：阶段性总结

核心提示： 这里带来的最大问题在于耦合地过于强烈，例如Chat消息的第一个参数是Person，适合C# Actor的消息执行方式（4）：阶段性总结(7)，表示聊天的对象，但是很可能在同一个系统中，从一定角度上来说，老赵认为这个描述非常妥当，可以聊天的对象不一定仅限于是人（Person），还可能是一个机器人（

这里带来的最大问题在于耦合地过于强烈。例如Chat消息的第一个参数是Person，表示聊天的对象。但是很可能在同一个系统中，可以聊天的对象不一定仅限于是人（Person），还可能是一个机器人（Robot）；同理Work的汇报者也可能是一个记录系统。事实上，我们可能只要求Chat的目标是一个可以处理IChater消息的Actor即可，这意味着Chat方法的第一个参数的类型需要是Actor<Action<IChater>>。但是，这个Actor还需要接受其他类型的消息，如IWorkReportHandler，这又意味着它的类型需要是Actor<Action<IWorkResultHandler>>。一个Actor又如何成为两种类型？

在实际运用中，这点无法回避，因此我们必须得变。

使用“消息总线”来解耦？

风云兄提出，既然问题的关键在于强耦合，为什么不使用消息总线来解耦呢？其实这问题很容易回答。

首先，“强耦合”并不是我们想要解决的问题。我们想要解决的是“消息执行”（见文章标题）而不是“消息传递”，“强耦合”只是我们得到满意的解决方案之前所遇到的困难而已。“消息总线”是消息传递时，系统（大粒度）组件之间的解耦方式。而现在我们要解开的，是Actor这种小粒度对象之间消息传递造成的耦合。在.NET消息传递过程中，消息是一个对象，一般在框架中使用TMessage表示。例如风云兄给出的代码，TMessage即为字符串。我们的目标是如何从一个TMessage类型的对象（如字符串）分配至不同的逻辑片断——还要携带参数过去。风云兄的例子回避了这一点。

事实上，正如文章一开始所说的那样，我们文章得出的解决方案并不仅限于Actor模型，它适合各种消息传递场景——这些场景里自然包括“消息总线”的使用。关于文章的目的，“亚历山大同志”同学称之为“要在C#里面实现优雅的模式匹配的问题”。从一定角度上来说，老赵认为这个描述非常妥当，因为Erlang中模式匹配的目的便是消息执行。