基于命令的协议解析器中每个命令的唯一类
本文关键字：命令 唯一 协议 于命令 | 更新日期: 2023-09-27 17:48:59
我正在用c#编写一个MSN Messenger客户端，并选择为MSNP协议编写我自己的解析器，因为我看过其他客户端的源代码，我没有发现代码达到我通常的标准——特别是非常缺乏对线程同步的考虑。
首先，我编写了一个通用的解析器，它接受告诉它如何解析命令的"规则"。
例如，我设置了一个规则，该规则规定命令代码"VER"有一个事务id和一个参数列表。
这工作正常，但它一直是一个临时解决方案。我的意图是制作一个完全成熟的解析器，它可以单独查看每个命令和参数。
例如如果命令代码为"VER"，则创建一个VersionCommand类，将事务id与接受的协议列表一起传递给它。
，那么我的代码可以很容易地解释命令，而不需要混淆参数索引和(verCmd。TrId,verCmd.AcceptedProtocols)
我担心的是对每种命令类型使用单独的类是对资源的浪费。
所以我的问题是——这是浪费吗?是否有其他基于命令的协议实现采用类似的方法?我想做的事有先例可循吗，还是说这是个愚蠢的想法?
你的建议并不浪费;相反，您只是在"功能丰富"answers"简单"(关于接口和解析)之间进行权衡。
我们已经按你的建议做了lot。关键的问题是:我是否可以简化它(例如，像一个平面解析"跳转表")，或者我的解析需求和实现是否需要一个基础设施来允许将来特定于应用程序的扩展?
根据问题的答案，我们已经做了两个，一个lot:
如果"no"，则有一个离散的(长)(平面)解析列表，其中您"尝试"解析命令(及其参数)，失败，然后继续进行下一次尝试，等等，直到您放弃了"测试"的所有二十个(或一些数字)命令。优点:简单、简单，每个命令都可以有自己的自定义参数(因为每次解析尝试都可以验证特定于该命令的参数)。这并不要求为每个命令都有一个类(但是如果您愿意，可以这样做)。例如，您可以有一个单个 MyCommand类，它尝试用20种不同的方式解析自己，以暗示带有不同参数的20种不同的枚举命令类型。
如果"是"，你是在投资一个框架。通常，这是为了获得一个可以以特定于应用程序的方式扩展的"引擎"。在我们的例子中，它还倾向于反映命令的多个层次结构，其中每个层次结构都可以以特定于应用程序的方式"扩展"命令。而且，由于这些是独立的层次结构，我们在重用状态和逻辑(使用不同层次结构的公共基类)方面获得了很大的好处。在这种情况下，每个层次结构的"基"将"嗅探"命令，如果匹配，则找出应该执行解析和实例化的派生大多数实例中的哪一个。这个显著地简化了解析，因为您对不同的层次结构有不同的数据处理需求(并且该代码是在基中建立的)，并且您没有一个怪物解析器。通常，我们对每个命令类型都有一个派生类，具有自己的自定义参数需求。这些派生类在"层次结构"中分组，这些层次结构可以(也可以不)共享一个公共基类(例如，"树"或"森林"模型)。
如果你希望你的协议是相对有限的/不变的，具有一致的命令参数和类型，"flat"工作得很好。如果您想要特定于应用程序的可扩展性，请继续投资于每个类类型的一个命令的基础设施——在初始实现的"步法"之后，它非常有效，特别是当您后来意识到参数不正确并且需要更改实现时(这种情况经常发生)。使用每个类一个命令(其中还包含特定于命令的解析，而不是一个超级怪物-主人-解析器)来实现这一点要容易得多，尽管我承认需要编写更多的代码来实现该基础结构。