属性列表还是继承丛林？

Question

我有 2 个应用程序（我们称它们为 AppA 和 AppB）相互通信。
AppA 正在向 AppB 发送对象。
可能有不同的对象，AppB 不支持每个对象。 一个对象可以是一个模型（想想一个游戏，其中模型是车辆、房屋、人等）。
可能有不同的 AppB。每个都支持另一个对象基础。
例如。可能有一个仅支持车辆模型的 AppB。另一个 AppB 只支持特定的飞机型号。

目前的情况如下：

有一个BasicModel，它有一个位置和一个方向。

如果另一个用户想要额外的属性，他会继承ExpandedModel。并添加例如属性颜色。
现在，每个需要附加属性的用户都继承自更通用的模型。过了一会儿，VehicleModel 可以激活挡风玻璃刮水器，AircraftModel 可以有着陆灯，PersonModel 当某个布尔值设置为 true 时可以挥手告别。

如果要支持新模型，AppB 总是需要定制。

这种方法有一个很大的缺点：经过几次继承后，它变得极其复杂。也许有像ExpandedAircraftModel 这样的冗余也可以使用windschield-wipers。

另一种方法：

我只创建了一个具有属性列表的Model-class。最简单的实现是 std::map，其中 Key 是属性名，Value 是属性值。
用户现在可以输入他想要的尽可能多的信息。如果他想使用挡风玻璃刮水器，他只需添加一个"windshieldwiper - ON"-pair。

如果 AppB 支持挡风玻璃雨刷，它只会查看列表中是否存在这样的属性并读取相关值。

AppB 的开发人员需要详细记录他支持的属性。每个开发人员都必须检查特定属性是否已经存在以及如何调用它（例如，一个开发人员可以将他的属性命名为 windshieldwiper，而另一个将其命名为 windshield-wiper）
这也可能变得非常复杂，用户唯一可以关联的是文档或必须保存在中心空间的特定标准规范。

最后，问题：

哪种方法更好？
您是否发现任何其他缺点？
是否应该使用第三种方法来代替这两种方法？

Answer 1

只是为了比较，Google 的 Protocol Buffers 将两者结合使用，但更倾向于您的第二个示例。

如果您有明显不同的数据需要通过通道发送，您可以使用该工具生成“消息”类的派生类，但每条消息都可以包含其他消息，并且您可以将消息定义嵌套在它们自身中。当消息发出时，接收方会检查字段以确定它是什么类型的消息以及其中包含哪些字段。

缺点是您的代码很快就会变得过于冗长，因为您不能真正使用继承来自动化处理传入消息的过程，但好处是您的协议消息保持高度组织性并且易于调试，因为您正在使用各种自反属性列表。