我的Unity工作室，但任何引擎的建议都有价值。

我最初使用简单的继承来组织并处理我的模块系统。它适用于直接资产，但它被限制了不允许多继承。

例如，这些工作很好:

- 人物 > 敌人 > 狼
- 电子 > 温度供应商 > 温控器

因为这很直接，它们分享所有相关代码。但是，这会在我想要创建像狼电子这样的东西，或 Heater 敌人时打碎。

然后我尝试过接口，也有其局限性。

- 狼 : IElectronic
- 敌人：IHeater

现在我有可以处理 Electronic 狼和 Heater 敌人的接口。但我无法在这些接口中暴露或存储任何变量，如 powerDrain 或 targetTemperature; 他们无法携带任何实际信息。我还无法在 Unity 仪表板中暴露接口，有时需要将 wolf 强制转换为 IElectronic。所以，它有它的用途，但仅包含方法，因此太有限了。

最后，我尝试过组件，它在功能方面很好，但难以实现。

我尝试过的例子中，我为什么感觉它们很痛苦的几点具体如下：

- 总是 > 结构 > 商店 > jobProvider > 等等

这里有我所有需要的零部件，但由于需要为不同零部件分配和引用而导致了疼痛，尤其是在 Unity 中。此外，如果 Structure 有 onCharacterEnter 事件，但我想让 GeneralStore 处理该事件，可能还需要设置事件订阅者的方法。这样只会增加额外的设置和臃肿，实际上我希望能尽可能轻松，流畅地实现（可能是百余件）内容。

另一个例子是：

- 温控器（需要来自电池的电力）
- 电力承载器 > 电池
- 电池 > 电力承载器

功能上正常，但是由于我使用电力承载器来处理电力传递，我要在涉及电力的所有物体上添加电力承载器组件（以避免重复的混淆）。由于我不希望在一个游戏对象上有多个电力承载器组件（可能会使它们关联的哪个组件不明确），所以我将电池设为子项-game-object。它工作得可以，但仍然难以处理。如果我想访问电池，我需要进入 Heater 的子项-game-object 中，并找到它；这仅仅是游戏中最简单的一件资产。这种层次结构很快就会变得非常混乱，尤其是对于具有许多模块化，多层次的零部件的资产。

这些是适用于这样的模块化框架的唯有可行的选项吗？还是存在更优雅的替代方案？理想情况下，如果存在多继承，就会对我有所帮助。