我有 2 个应用程序（我们称它们为 AppA 和 AppB）相互通信。
AppA 正在向 AppB 发送对象。
可能有不同的对象，AppB 并不支持每个对象。
一个对象可以是一个模型（想象一下游戏，其中模型是车辆、房屋、人等）。
可能有不同的 AppB。每个都支撑着另一个物体基础。
例如。可能有一个仅支持车型的 AppB。另一个 AppB 仅支持特定的飞机型号。
目前的情况如下：
有一个BasicModel它有一个位置和一个方向。
如果另一个用户想要额外的属性，他会继承一个ExpandedModel。并添加例如属性颜色。
现在，每个需要附加属性的用户都继承自更通用的模型。过了一会儿有一个VehicleModel它可以激活挡风玻璃雨刷器AircraftModel可能有着陆灯或PersonModel当某个布尔值设置为 true 时，它可能会挥手告别。
如果 AppB 要支持新模型，则始终需要进行定制。
这种方法有一个很大的缺点：在几次继承之后它会变得极其复杂。或许会有裁员之类的ExpandedAircraftModel也可以使用挡风玻璃雨刷。
另一种方法：
我只创建一个Model-具有属性列表的类。最简单的实现是 std::map，其中 Key 是属性名称，Value 是属性值。
用户现在可以输入任意数量的信息。如果他想使用挡风玻璃刮水器，他只需添加一个"windshieldwiper - ON"-pair.
如果 AppB 支持挡风玻璃雨刷器，它只会查看列表中是否存在这样的属性并读取相关值。
AppB 的开发人员需要很好地记录他支持哪些属性。每个开发人员都必须检查特定属性是否已经存在以及如何调用它（例如，一个开发人员可以将他的属性命名为windshieldwiper另一个称之为windshield-wiper)
这也可能变得极其复杂，用户唯一能涉及到的就是必须保存在中心空间的文档或特定的标准规范。
最后，问题：
哪种方法更好？
您还发现其他缺点吗？
是否应该使用第三种方法来代替这两种方法？
只是为了进行比较，Google 的 Protocol Buffers 使用了两者的组合，但更倾向于您的第二个示例。
如果您需要通过通道发送明显不同的数据，则可以使用该工具生成“消息”类的派生类，但每个消息都可以包含其他消息，并且您可以在其自身中嵌套消息定义。当消息发送出去时，接收者检查字段以确定消息的类型以及其中包含哪些字段。
缺点是您的代码很快就会变得过于冗长，因为您无法真正使用继承来自动执行传入消息的处理过程，但优点是您的协议消息保持高度组织性并且易于调试，因为您使用各种自反属性列表。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
