基于命令的协议解析器中每个命令的唯一类？

Question

我正在用C＃编写一个MSN Messenger客户端，并选择为MSNP协议编写我自己的解析器，因为我查看了其他客户端的源代码，并且没有找到符合我惯常标准的代码 - 特别是对线程同步缺乏深思熟虑。首先，我写了一个通用解析器，它接受“规则”，告诉它如何解析命令。

例如，我设置了一个规则，规定命令代码“VER”具有事务ID和参数列表。

这工作正常，但它一直是一个临时解决方案。我的意图是成为一个完全成熟的解析器，它分别查看每个命令和参数。

例如

如果命令代码是“VER”然后创建一个VersionCommand类，并向其传递与所接受的协议列表沿事务ID。

然后我的代码可以很容易地不与参数指标等（verCmd.TrId & verCmd.AcceptedProtocols）

我担心的是，这是资源的浪费使用一个单独的类的每个命令类型搞乱解释命令。

所以我的问题是 - 是浪费吗？有没有其他基于命令的协议实现采用类似的方法？对于我想做的事有没有先例，还是这是一个虚无主意？

Answer 1

你的建议不是浪费;相反，你只是在“功能丰富”和“简单”（关于接口和解析）之间进行折衷。

我们已经完成了你建议的lot。关键问题：我是否可以简化它（例如，像一个平面解析“跳转表”），还是我的解析需求和实现需要基础结构来允许将来的特定于应用程序的扩展？

根据答案的问题，我们已经做了两个，一个很多：

如果“否”，你有（平）解析的离散（长）列表，您尝试解析一个命令（使用它的参数），失败，然后下降到下一个尝试等等，直到你放弃了所有被“测试”的二十个（或一些数字）命令。 好处：扁平，简单，每个命令都可以有自己的自定义参数（因为每个解析尝试都可以验证特定于该命令的参数）。这是而不是要求你有一个每个命令的类（但你可以如果你想）。例如，您可能有一个类，它试图以20种不同的方式解析自己，以暗示具有不同参数的20种不同的枚举命令类型。

如果“是”，您正在投资框架。通常，这是为了获得一个可以按照应用程序特定的方式扩展的“引擎”。在我们的例子中，它也倾向于反映几个命令的层次结构，其中每个层次结构可以针对特定于应用程序的方式“扩展”命令。而且，由于这些是独立的层次结构，我们在重用状态和逻辑（对于不同层次结构具有公共基类）中获得了巨大的好处。在这种情况下，每个层次结构的“基础”“嗅探”命令，如果匹配，则找出哪些派生最多的实例应该执行解析和实例化。这个显着地简化了分析，因为你对不同的层次结构有不同的数据处理需求（并且这个代码是在基础中建立的），并且你没有单独的分析器。通常，我们为每个命令类型都有一个派生类，并具有自己的自定义参数要求。这些派生类被分组在“分层结构”中，这些分层结构可能（或不可能）共享一个公共基类（例如“树”或“森林”模型）。

如果您希望您的协议相对有界/不变，并且具有一致的命令参数和类型，那么“扁平”就很好。如果您想要特定于应用程序的可扩展性，请继续并投资于每个类型的单一命令基础架构 - 在初始实现的“步法”之后，它非常适用，尤其是当您后来认识到您的参数不正确时需要改变实现（这一直发生）。这是很多更容易做到与每个类一个命令（它也包含您的命令特定的解析，而不是一个超级怪物主解析器），虽然我承认这是更多的代码来获得基础设施到位。