多重继承是否可以解决实体系统所解决的所有问题？

问题是很自我解释的：多重继承不能解决实体系统也解决的所有问题吗？

我只记得一个叫做“多重继承”的术语，它似乎解决了传统继承带来的许多膨胀问题。

不，多重继承不能解决与实体系统相同的所有问题：实体系统和多重继承是两个截然不同的事物。您可以构建具有或不具有多重继承的实体系统，并且类似地，您可以在不构建实体系统的情况下利用多重继承。

传统上，开发基于组件的实体系统是因为它希望摆脱任何形式的繁重继承，而转向组合。关于此格言的其他地方，例如关于程序员SE或SO本身，有足够的文献和讨论，而对于为什么更喜欢构图的更大问题是游戏开发的偏题。简而言之，这是一种倾向于改善可变性和可维护性的方法。

Josh的回答很棒，但我想补充一下：

实体/组件的最酷功能之一是数据驱动的方式，您可以在其中创建和管理游戏中的每个“事物”。从我所看到的，一旦您创建了一个不错的组件类型和系统库，就可以用最少的代码修改就可以构建几乎任何东西。（注意：最小！= 0）

通过根据行为来定义游戏，并赋予自己即时修改这些行为的能力-在运行时，在初始化期间通过从脚本或数据库中加载这些行为等，您可以打开一个全新的可能性世界。想看看为什么您的阴影没有落在您期望的位置吗？将相机/ POV组件添加到灯光中。

只要创建了块，实体/组件就可以使您构建所需的任何东西。

同样，多重继承会导致与单一继承相同的问题。在层次结构中添加属性或行为时，它会传播。只要要进行深层次结构设计，就会遇到不必要的负担，重复的代码或解决冲突的情况。当您将游戏视为数据时，可以避免大多数情况。

在过去的几周中，我才刚刚开始玩这个游戏，但是事情变得如此简单，给我留下了深刻的印象。这不是灵丹妙药-我碰到过一些案例，其中将lambda附加到组件是解决问题的最干净，最方便的方法-但这是一个很好的模式，如果可以这样称呼。

稍微相关一点：在以数据为中心的应用程序（网站等）中，庞大而乏味的维护生成器之一就是将层次结构对象映射到关系数据库中。我们周围有很多漂亮的解决方案，但最终它们都是旨在平整层次结构的所有hack。您不必构建模型以使其满足应用程序的目的，而是在有效的层次结构和逻辑关系表示之间妥协。我一直在想在我的一个应用程序中重建一个较大的层次结构作为实体/组件系统的想法-放弃层次结构并使数据库成为其余实现的黄金标准-这是有希望的。

当您集成诸如动态代码生成/代码缓存之类的功能来解决性能问题时，您将获得一种快速，灵活，逻辑的体系结构，该体系结构可能会以一种更好得多的方式实现OOP的可重用代码目标。