与 OOP（或其他范式）相比，ECS（实体-组件-系统）架构模式的缺点是什么？答案

【问题标题】：What are the disadvantages of the ECS (Entity-Component-System) architectural pattern, compared to OOP (or other paradigms)?与 OOP（或其他范式）相比，ECS（实体-组件-系统）架构模式的缺点是什么？
【发布时间】：2020-02-24 01:43:03
【问题描述】：

因为 Unity ECS，最近看了很多关于 ECS 的文章。

ECS 架构有许多明显的优势：

ECS 是面向数据的： 数据倾向于线性存储，这是系统访问数据的最佳方式。在体面的 ECS 实施中，数据是按顺序存储和处理的，对于任何给定的系统处理它的组件集，几乎没有中断或没有中断。

ECS 非常分区：它自然地将数据与行为分开，强制执行“组合优于继承”（google it）等。

ECS 对并行处理和多线程非常友好：由于事物的结构化方式，许多实体和组件可以避免冲突并与其他系统并行处理。

然而，ECS 的缺点（与 OOP 或实体组件 [无系统] 相比，直到最近在包括 Unity 在内的游戏引擎中很常见）很少被谈论，如果有的话。它们存在吗？如果有，它们是什么？

【问题讨论】：

我想到了“组合优于继承”
转向 ecs 编码有点像我们许多人从线性到 oo 所经历的大脑放屁。虽然如何使用 ecs 仍在改变，unity 继续尝试使用它，但核心原则并没有改变一些如何使用，如果你没有时间投资，它有点追逐一个移动的目标。我认为这对于更多电影作品来说是必须的，比如说 5 军之战风格的作品，但对于随机平台游戏或浪费时间的游戏不太可能，rpg 风格......也许但只是也许

标签： oop unity3d architecture entity-component-system data-oriented-design

【解决方案1】：

以下是我从研究中收集到的几点：

系统非常依赖于它们的顺序。在现有系统之间引入新系统可能是一项挑战。
您还需要尽可能提前计划您的数据，因为它们可能会被许多系统使用。更改组件的内容可能会破坏相当多的系统。
虽然调试系统的流程很容易，但调试单个组件的更改也比较困难，并且无法全面了解实体在其所有组件中发生的情况。我不确定 Unity 是否为此引入了新的调试功能。
如果您计划在您的团队中使用 ECS，向不熟悉它的开发人员介绍一种新的范例可能是一个挑战。入职时间可能更长，开销更大。

希望这能给你一个好的起点。

【讨论】：

在第一点上，OOP 和普通 EC（“标准统一”）不是已经如此了吗？通常，您已经必须使组件和系统足够自给自足，不依赖于其他东西的执行顺序，或者足够抽象以至于顺序并不重要（？），所以我没有看到这一点ECS 的一个缺点，而是编程中的一般问题。 --- 第 2 点有点相同。这不是结构化数据的普遍问题吗（？）
#1 主要是为了指出不，您并没有消除 ECS 的所有依赖问题，您仍然依赖于系统执行顺序。对于＃2，由于您应该将数据封装在 OOP 中，我倾向于说问题没有那么大？ ECS 中并不真正存在封装（也不应该）

【解决方案2】：

谈到 Unity3D，我想到的一个缺点是那里的 ECS 非常受限于 Unity 类（例如 MonoBehaviour）和生命周期。这意味着组件不容易与其他 C# 代码共享，而设计良好的 OOP 类可以被 Unity 以外的其他平台重用。

我想到的另一点是，在 Unity 中使用带有组件的接口有时并不容易，因为只有在最新版本中才支持接口的序列化。没有序列化就不会出现在检查器内部。

【讨论】：