Я считаю, что ECS принципиально отличается от ООП и склонен рассматривать его так же, как вы, более близкий к функциональному или особенно процедурному по своей природе с очень четким разделением данных от функциональных возможностей. Есть также некоторое подобие программированию, имеющему дело с центральными базами данных. Конечно, я худший человек, когда дело доходит до формальных определений. Меня интересует только то, как обстоят дела, а не то, чем они концептуально определены.
Я предполагаю что-то вроде ECS, где компоненты агрегируют поля данных и делают их общедоступными / глобально доступными, сущности агрегируют компоненты, а системы обеспечивают функциональность / поведение этих данных. Это приводит к радикально сложным архитектурным характеристикам, которые мы обычно называем объектно-ориентированной кодовой базой.
И, конечно, есть некоторые размытые границы в том, как люди проектируют / внедряют ECS, и идут споры о том, что именно представляет собой ECS. Все же такие границы также размыты в коде, написанном на том, что мы называем функциональными или процедурными языками. Среди всей этой нечеткости фундаментальная константа ECS с отделением данных от функциональности кажется мне гораздо ближе к функциональному или процедурному программированию, чем ООП.
Одна из главных причин, по которой я не думаю, что полезно считать ECS принадлежащим к классу ООП, заключается в том, что большинство практик SE, связанных с ООП, вращаются вокруг стабильности общедоступного интерфейса с функциями моделирования общедоступных интерфейсов , а не с данными. Основная идея заключается в том, что основная часть общедоступных зависимостей направлена на абстрактные функции, а не на конкретные данные. И из-за этого ООП, как правило, делает очень дорогостоящим изменение фундаментального поведения при проектировании, в то же время удешевляя изменение конкретных деталей (таких как данные и код, необходимые для реализации функциональности).
ECS радикально отличается в этом отношении, учитывая, как все взаимосвязано, поскольку основная часть общедоступных зависимостей направляется к конкретным данным: от систем к компонентам. В результате любая практика SE, связанная с ECS, будет вращаться вокруг стабильности данных , потому что наиболее общедоступные и широко используемые интерфейсы (компоненты) на самом деле являются просто данными.
В результате ECS позволяет очень легко выполнять такие вещи, как замена движка рендеринга OpenGL на DirectX, даже если эти два реализованы с радикально отличающимися функциональными возможностями и не имеют одинаковых конструкций вообще, при условии, что и движок DX, и GL иметь доступ к таким же стабильным данным. Между тем это было бы очень дорого и потребовало бы переписывания нескольких систем для изменения, скажем, представления данных a MotionComponent.
Это очень противоположно тому, что мы традиционно связываем с ООП, по крайней мере, с точки зрения характеристик связи и того, что составляет «открытый интерфейс» и «частные детали реализации». Конечно, в обоих случаях «детали реализации» легко изменить, но в ECS изменение данных требует больших затрат (данные не являются деталями реализации в ECS), а в ООП - изменение функциональности, которое стоит изменить. (дизайн функций не является деталью реализации в ООП). Так что это совсем другое представление о «деталях реализации», и одно из главных обращений ко мне с ECS с точки зрения обслуживания было то, что в моей области, данные, необходимые для того, чтобы что-то делать, было проще раз и навсегда стабилизировать и спроектировать правильно, чем все различные вещи, которые мы могли бы сделать с этими данными (которые будут меняться все время, когда клиенты меняют свое мнение и приходят новые предложения пользователей). В результате я обнаружил, что затраты на обслуживание резко упали, когда мы начали направлять зависимости от абстрактных функций к необработанным, центральным данным (но все же с осторожностью относимся к тому, какие системы обращаются к каким компонентам, чтобы обеспечить возможность сохранения инвариантов в разумной степени, несмотря на то, что все данные концептуально существуют глобально доступный).
И в моем случае, по крайней мере, SDK ECS с API и всеми компонентами фактически реализован на C и не имеет никакого сходства с ООП. Я нашел C более чем достаточным для такой цели, учитывая присущий ей недостаток OO в архитектурах ECS и желание иметь архитектуру плагинов, которая может использоваться самым широким диапазоном языков и компиляторов. Системы по-прежнему реализованы на C ++, поскольку C ++ делает их там очень удобными, и системы моделируют большую часть сложности, и там я нахожу применение многим вещам, которые можно рассматривать ближе к ООП, но это для деталей реализации. Сам архитектурный проект все еще напоминает очень процедурный С.
Так что я думаю, что несколько сбивает с толку попытка сказать, что ECS является OO по определению. По крайней мере, основы делают вещи, которые на 180 градусов поворачиваются от многих фундаментальных принципов, обычно связанных с ООП, начиная с инкапсуляции и, возможно, заканчивая тем, что считается желаемыми характеристиками связи.