消息系统的C++设计模式？

我的任务是实现用于实时模拟的消息传递系统.此系统中需要存在多种不同类型的消息传递对象,并且将来可能会添加更多消息传递对象.这些对象代表了sim中玩家之间的主要通信方式.假设我完全理解我的要求,可以通过以下属性定义消息传递对象:

发送协议(播放器可以发送什么消息以及何时发送)

接收协议(播放器可以接收的消息和频率)

消息格式(正在发送的数据的结构)

模拟代码目前仅支持一种发送和接收协议以及一种消息格式.我的工作是使代码更具可扩展性,以便它可以支持将来对协议和消息结构的更改/添加.对此的第一个方法是为每个属性定义抽象基类,并让每个消息传递对象由它们的句柄组成.然后可以将每个消息传递对象写为协议和格式对象的不同组合.我担心的是,这种设计很快就会过度概括,从而成为维护的噩梦.我想通过十几个文件进行筛选只是为了弄清楚它是如何FooMessaging真正起作用的.

我将用C++编写这个,但我认为这更像是一个通用的设计问题.我可以在这里申请任何"标准"模式或最佳实践吗？

好的,我怀疑你正在从大约G开始进行A到Z的过程.

首先,你的用例是什么？你想做什么？您正在构建什么样的"消息系统"？电子邮件？IM？心灵感应？

其次,您从这些用例中获得的域名是什么？

现在,考虑过,然后是的,你经常发现为基础课制作ABC很方便.考虑改为创建一个接口(尽管C++中的接口和ABCs之间的区别比其他语言定义的要差.)在过去的20年中,基于继承的OO已经证明存在很多问题,因此接口和聚合都是现在很受欢迎.并不总是更好,但你应该先考虑它们.

现在,告诉我"协议"对应的物理内容是什么？你的意思是建模消息流吗？它是一种通讯媒介吗？

特别是格式听起来很可疑,如果不是立刻错误的话:消息格式往往与协议密切相关.

基本上,先备份一下,然后告诉我们更多关于你要做的事情.

更新

啊哈.好的,看,我们从中得到了很多帮助.首先,你指的是可用操作意义上的"协议" - 一个完全合理的用法,但是当你把它与TCP和UDP混淆时会让人感到困惑,就像我做的那样.

现在,那说,你确实至少有几个选择.在下文中,我对SIM中可以发送或接收消息的任何实体使用术语"播放器".

这里的关键概念是围绕基因座进行设计以进行更改,并围绕非功能性需求进行设计.明显的变化轨迹是

你可以在你的意义上有几个"协议",如果你有多达三个,你应该计划总有更多.如果您期望超过两个,请计划您可以任意多次.

你可以有几种不同的格式化消息的方式,比如JSON,XML或YAML.如果你期望超过两个,那么AGain计划你可以任意多.

您可以拥有多种传输机制.从事物的声音来看,你至少可以使用UNIX域套接字×共享内存×命名管道,但是我的直觉说你也可以选择本地和远程,这意味着你也可以选择UDP或TCP.绝对超过两个,计划可扩展性.

选项1:

使用代理模式,其中每个协议定义一个必须以多种方式之一实现的接口,具体取决于下面的消息传递格式.玩家宣传他们愿意收到的消息; 在他们准备接收消息时,他们构造一些东西,为他们收到的任何特定操作消息调用他们的代码.要发送,他们构造一个对象,为其接收伙伴Player实现适当的接口.

在幕后,这些对象可以有多个实现,每个实现用于不同的消息传递格式和传输机制.

像这样的系统的示例包括SOM/DSOM a/k/a CORBA和使用Remote接口的Java RMI.

您可以围绕Command模式构建一些东西.每个协议都有一个"发送给我"的具体实现,你的接收器只知道如何重建发送的对象.命令对象具有混合(多次继承,或在运行时作为对象传递),它知道如何编组和序列化Command对象; 你可以有第二个了解运输机制的人.

通过序列化对象并使用传输机制将序列化表单移动到接收器,您可以在特定协议上发送消息.接收器"重新水化"对象,并根据发送的实际类型调用适当的方法.

这方面的一个例子是带有Seri​​alizable接口的Java RMI,而不是使用Remote.