C++ 属性列表还是继承丛林？

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

目前的情况如下： 有一个具有位置和方向的

BasicModel

如果另一个用户需要额外的属性，他将继承一个

ExpandedModel

。并添加属性颜色等。
现在，每一个需要附加属性的用户都从一个更通用的模型继承。过了一会儿，有一个

VehicleModel

可以激活挡风玻璃雨刮器，一个

AircraftModel

可以有着陆灯，或者一个

PersonModel

可以在某个布尔值设置为true时挥手告别

如果AppB应支持新模型，则始终需要对其进行自定义

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

另一种方法： 我只创建了一个具有属性列表的

模型
-类。最简单的实现是std:：map，其中键是属性名，值是属性值。

用户现在可以输入他想要的任何信息。如果他想使用挡风玻璃雨刮器，他只需添加一对
“挡风玻璃雨刮器-开启”
-即可

如果AppB支持挡风玻璃雨刮器，它只会查看列表中是否有此类属性，并读取相关值

AppB的开发人员需要很好地记录他支持的属性。每个开发人员都必须检查特定属性是否已经存在以及如何调用（例如，一个开发人员可以将其属性命名为
windshieldwiper
，另一个开发人员将其命名为
windshieldwiper
）

这可能会变得非常复杂，用户唯一能涉及的就是文档或特定的标准规范，它们必须保存在中心位置

最后，问题是：
哪种方法更好？

您是否发现了其他缺点？

有第三种方法可以代替这两种吗？
为了比较，谷歌的协议缓冲区使用了这两种方法的组合，但很难倾向于第二种方法

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

缺点是您的代码很快就会变得过于冗长，因为您无法真正使用继承来自动化处理传入消息的过程，但好处是，您的协议消息保持高度组织，易于调试，因为您使用的是自反属性排序列表。
您不应该将继承与组合进行比较吗？啊，一周前查看了Google协议缓冲区，因为我正在考虑使用它通过网络发送数据。我将对此进行更深入的研究。非常感谢！