Каковы недостатки архитектурного шаблона ECS (Entity-Component-System) по сравнению с ООП (или другими парадигмами)?

Question

Из-за Unity ECS я в последнее время много читал о ECS.

У архитектуры ECS есть много очевидных преимуществ:

ECS ориентирован на данные: Данные, как правило, хранятся линейно, что является наиболее оптимальным способом доступа к ним системы. В приличных реализациях ECS данные хранятся и обрабатываются последовательно, с небольшими перерывами или без прерываний для какой-либо системы, обрабатывающей свой набор компонентов.

ECS очень разделен: Естественно отделяет данные от поведения, обеспечивает «композицию по наследованию» (google it) и т. д.

ECS очень удобен для параллельной обработки и многопоточности: Из-за структуры вещей многие сущности икомпоненты могут избегать конфликтов и обрабатываться параллельно с другими системами.

---

Однако недостатки ECS (по сравнению с OOP или Entity-Component [без систем], как это часто бывает в игровых движках, включая Unityдо недавнего времени) редко, если вообще когда-либо говорили. Они существуют? И если они делают, что они?

Answer 1

Когда дело доходит до Unity3D, один недостаток, который мне приходит в голову, заключается в том, что ECS там весьма ограничен классами Unity (например, MonoBehaviour) и жизненным циклом. Это означает, что компоненты нелегко делить с другим кодом C #, в то время как хорошо разработанный класс ООП можно использовать в других платформах, кроме Unity.

Еще один момент, который мне приходит в голову, заключается в том, что использование интерфейсов с компонентами иногдане просто в Unity, потому что только в новейшей версии поддерживается сериализация интерфейсов. Без сериализации внутри инспектора не появится.