Я вважаю, що ECS є принципово відмінним від OOP і схильний бачити його так само, як і ви, як наближення до функціонального або особливо процесуального характеру з дуже чітким відмежуванням даних від функціональності. Існує також деяка подоба до програмування, що стосується центральних баз даних. Звичайно, я найгірша людина, коли мова йде про формальні визначення. Мене хвилює лише те, як виглядають справи, а не те, що вони концептуально визначені.
Я припускаю своєрідний ECS, де компоненти агрегують поля даних і роблять їх загальнодоступними / глобально доступними, сутності агрегують компоненти, а системи забезпечують функціональність / поведінку на цих даних. Це призводить до кардинально складних архітектурних характеристик від того, що ми зазвичай називаємо об'єктно-орієнтованою базою кодів.
І звичайно, є деяка розмитість меж у способі проектування / впровадження системи ECS, і дебати про те, що саме є ECS, в першу чергу. Однак такі межі також розмиті в коді, написаному на тому, що ми називаємо функціональною або процедурною мовою. Серед усієї цієї нечіткості фундаментальна константа ECS з відокремленням даних від функціональності здається мені набагато ближчою до функціонального чи процедурного програмування, ніж OOP.
Однією з головних причин, на яку я не думаю, що корисно вважати, що ECS належить до класу OOP, полягає в тому, що більшість практик SE, пов'язаних з OOP, обертаються навколо стабільності публічного інтерфейсу, з функціями моделювання публічних інтерфейсів , а не даних. Основна ідея полягає в тому, що основна частина суспільних залежностей спрямована на абстрактні функції, а не на конкретні дані. І через це OOP прагне дуже дорого змінити основні дизайнерські поведінки, при цьому дуже дешево змінювати конкретні деталі (наприклад, дані та код, необхідні для реалізації функціональності).
Система ECS докорінно відрізняється в цьому плані, враховуючи, як справи поєднуються в міру того, як основна частина суспільних залежностей протікає до конкретних даних: від систем до компонентів. Як результат, будь-яка практика SE, пов'язана з ECS, буде обертатися навколо стабільності даних , оскільки найбільш загальнодоступні та широко використовувані інтерфейси (компоненти) - це фактично дані.
Як результат, ECS дозволяє дуже легко робити такі речі, як заміна двигуна візуалізації OpenGL на DirectX, навіть якщо вони реалізовані з кардинально різними функціональними можливостями і взагалі не поділяють однакові конструкції за умови використання двигуна DX та GL. мати доступ до тих же стабільних даних. Тим часом це було б дуже дорого і вимагало б переписати купу систем, щоб змінити, скажімо, представлення даних MotionComponent.
Це зовсім протилежне тому, що ми традиційно асоціюємо з OOP, принаймні, з точки зору характеристик зв'язку та того, що являє собою "публічний інтерфейс" та "деталі приватної реалізації". Звичайно, в обох випадках "деталі впровадження" легко змінити, але в ECS - це дизайн даних, які дорого змінювати (дані не є деталізацією щодо впровадження в ECS), а в OOP - це функціональний дизайн, який дорого змінити. (розробка функцій не є деталізацією реалізації в OOP). Тож це зовсім інше уявлення про "деталі реалізації", і одне з головних звернень до мене за системою ECS з точки зору технічного обслуговування полягало в тому, що в моєму домені, Дані, необхідні для того, щоб зробити це було легше стабілізувати та правильно розробити правильно раз і назавжди, ніж усі різні речі, які ми могли зробити з цими даними (що змінюватиметься весь час, коли клієнти передумали, і нові пропозиції користувачів завалилися). Як результат, я виявив, що витрати на обслуговування зменшуються, коли ми почали спрямовувати залежності від абстрактних функцій до необроблених центральних даних (але все ще з обережністю, які системи отримують доступ до яких компонентів, щоб дозволити збереження інваріантів у належному ступені, незважаючи на всі дані, які концептуально є глобально доступні).
І в моєму випадку, принаймні, ECS SDK з API та всі компоненти реально реалізовані в C і не мають подібності з OOP. Я знайшов C більш ніж адекватним для такої мети, враховуючи притаманну відсутність OO в архітектурах ECS та бажання мати архітектуру плагінів, яку можна використовувати для найширшого кола мов та компіляторів. Системи все ще впроваджені в C ++, оскільки C ++ робить там речі дуже зручними, і системи моделюють основну частину складності, і там я знаходжу для багатьох речей, які можна вважати ближчими до OOP, але це для деталей щодо впровадження. Сам архітектурний дизайн все ще нагадує дуже процедурний C.
Тож я думаю, що дещо заплутано, принаймні, намагатися сказати, що ECS є ОО за визначенням. Принаймні, основи роблять речі, які є повним на 180 градусів, від багатьох фундаментальних принципів, зазвичай пов'язаних з ООП, починаючи з інкапсуляції і, можливо, закінчуючи тим, що вважатиметься бажаними характеристиками зв'язку.