Uważam ECS za zasadniczo odmienny od OOP i zwykle postrzegam go w ten sam sposób, co Ty, jako bliższy funkcjonalnemu lub szczególnie proceduralnemu charakterowi z bardzo wyraźnym oddzieleniem danych od funkcjonalności. Istnieje również pozór programowania w rodzaju centralnych baz danych. Oczywiście jestem najgorszą osobą, jeśli chodzi o formalne definicje. Martwię się tylko tym, jak się rzeczy mają, a nie tym, czym są koncepcyjnie zdefiniowane.
Zakładam rodzaj ECS, w którym komponenty agregują pola danych i udostępniają je publicznie / globalnie, podmioty agregują komponenty, a systemy zapewniają funkcjonalność / zachowanie tych danych. Prowadzi to do radykalnie trudnych cech architektonicznych z tego, co zwykle nazywamy obiektową bazą kodową.
I oczywiście jest pewne zatarcie granic w sposobie, w jaki ludzie projektują / wdrażają ECS, i jest debata na temat tego, co dokładnie stanowi ECS. Jednak takie granice są również zatarte w kodzie napisanym w języku, który nazywamy językiem funkcjonalnym lub proceduralnym. Wśród tych wszystkich zagadek podstawowa stała ECS z oddzieleniem danych od funkcjonalności wydaje mi się znacznie bliższa programowaniu funkcjonalnemu lub proceduralnemu niż OOP.
Jednym z głównych powodów, dla których nie uważam za przydatne uznanie ECS za należące do klasy OOP, jest to, że większość praktyk SE związanych z OOP obraca się wokół stabilności interfejsu publicznego, z funkcjami modelowania interfejsów publicznych , a nie danymi. Podstawową ideą jest to, że większość publicznych zależności płynie w kierunku funkcji abstrakcyjnych, a nie konkretnych danych. Z tego powodu OOP powoduje, że zmiana podstawowych zachowań projektowych jest bardzo kosztowna, a zmiana konkretnych szczegółów (takich jak dane i kod wymagane do wdrożenia funkcji) jest bardzo tania.
ECS jest pod tym względem diametralnie różny, biorąc pod uwagę sposób łączenia, ponieważ większość zależności publicznych płynie w kierunku konkretnych danych: od systemów do komponentów. W rezultacie wszelkie praktyki SE związane z ECS obracałyby się wokół stabilności danych , ponieważ najbardziej publiczne i powszechnie używane interfejsy (komponenty) są w rzeczywistości tylko danymi.
W rezultacie ECS bardzo ułatwia takie rzeczy, jak zamiana silnika renderującego OpenGL na DirectX, nawet jeśli oba są zaimplementowane z radykalnie różną funkcjonalnością i nie dzielą tych samych projektów, pod warunkiem, że zarówno silnik DX, jak i GL mieć dostęp do tych samych stabilnych danych. Tymczasem byłoby to bardzo kosztowne i wymagałoby przepisania kilku systemów, aby zmienić, powiedzmy, reprezentację danych MotionComponent.
Jest to zupełnie odwrotne od tego, co tradycyjnie kojarzymy z OOP, przynajmniej pod względem cech sprzężenia i tego, co stanowi „interfejs publiczny” vs. „prywatne szczegóły implementacji”. Oczywiście w obu przypadkach „szczegóły implementacji” są łatwe do zmiany, ale w ECS jest to projekt danych, które są kosztowne do zmiany (dane nie są szczegółami implementacji w ECS), aw OOP to projekt funkcjonalności, która jest kosztowna do zmiany (projektowanie funkcji nie jest szczegółem implementacji w OOP). To zupełnie inny pomysł na „szczegóły implementacji”, a jednym z głównych apelacji do ECS z punktu widzenia konserwacji było to, że w mojej domenie, dane potrzebne do zrobienia rzeczy łatwiej było ustabilizować i poprawnie zaprojektować raz na zawsze, niż wszystkie różne rzeczy, które moglibyśmy zrobić z tymi danymi (co zmieniałoby się cały czas, gdy klienci zmieniali zdanie i napływały nowe sugestie użytkowników). W rezultacie zauważyłem, że koszty utrzymania gwałtownie spadły, kiedy zaczęliśmy kierować zależności od funkcji abstrakcyjnych w kierunku surowych, centralnych danych (ale nadal z troską o to, które systemy uzyskują dostęp do których komponentów, aby umożliwić utrzymywanie niezmienników w rozsądnym stopniu, pomimo wszystkich danych koncepcyjnie globalnie dostępne).
I przynajmniej w moim przypadku zestaw SDK ECS z interfejsem API i wszystkimi komponentami jest faktycznie zaimplementowany w języku C i nie jest podobny do OOP. Uważam, że C jest bardziej niż wystarczające do takiego celu, biorąc pod uwagę nieodłączny brak OO w architekturach ECS i chęć posiadania architektury wtyczek, która mogłaby być używana przez najszerszą gamę języków i kompilatorów. Systemy są nadal zaimplementowane w C ++, ponieważ C ++ sprawia, że jest tam bardzo wygodnie, a systemy modelują większość złożoności i tam znajduję zastosowanie do wielu rzeczy, które mogą być uważane za bliższe OOP, ale to dotyczy szczegółów implementacji. Sam projekt architektoniczny nadal bardzo przypomina procedurę C.
Sądzę więc, że przynajmniej nieco mylące jest stwierdzenie, że ECS jest z definicji OO. Przynajmniej podstawy wykonują rzeczy, które są całkowicie obrócone o 180 stopni w stosunku do wielu podstawowych zasad ogólnie związanych z OOP, zaczynając od enkapsulacji, a może kończąc na czymś, co można by uznać za pożądane cechy sprzężenia.