Czy wielokrotne dziedziczenie nie rozwiązuje wszystkich problemów występujących w systemach encji?

Pytanie jest dość samo wyjaśniające: czy wielokrotne dziedziczenie nie rozwiązuje wszystkich problemów, które rozwiązują również systemy encji?

Właśnie przypomniałem sobie termin zwany „wielokrotnym dziedziczeniem”, który wydaje się rozwiązywać wiele wzdęć, które narzuciło klasyczne dziedzictwo.

— jcora
źródło

Wielokrotne dziedziczenie jest podobne do systemów encji, ale nie jest takie samo. Na przykład wiele elementów dziedziczenia nie może mieć składników dodawanych i usuwanych w czasie wykonywania. Nie wszystkie języki obsługują również wielokrotne dziedziczenie. Można również uznać kompozycję za należącą do tej samej kategorii vs byt / komponenty.

— MichaelHouse

Jeśli twoje klasy są już tak schludne, że możesz bezproblemowo dziedziczyć je razem w dowolny sposób, równie dobrze mogą już być komponentami. Komponenty umożliwiają także kompozycję / agregację w czasie wykonywania

Cóż, jest bardziej złożony i mniej podatny na błędy, więc dlaczego wolisz?

— API-Beast

MI tak naprawdę nie rozwiązuje problemów „wzdęcia”, ponieważ dziedziczenie nadmiaru interfejsu z klasy lub klas nadrzędnych jest raczej objawem złego użycia mechanizmu dziedziczenia, a nie pojedynczego lub wielokrotnego dziedziczenia. Ten sam „wzdęcie” można również osiągnąć w podejściu do problemu zorientowanym na kompozycję.

@MrBeast, czy masz na myśli bardziej złożony / bardziej podatny na błędy, mniej złożony / podatny na błędy, czy „dlaczego nie wolisz?”

— 3Dave

Odpowiedzi:

Nie, wielokrotne dziedziczenie nie rozwiązuje wszystkich tych samych problemów, które robią systemy encji: systemy encji i wielokrotne dziedziczenie to dwie bardzo różne rzeczy. Możesz zbudować system encji z wielokrotnym lub bez wielokrotnego dziedziczenia i podobnie możesz korzystać z wielokrotnego dziedziczenia bez budowania systemu encji.

Tradycyjnie systemy jednostek skupione na komponentach są opracowywane z powodu chęci odejścia od ciężkiego dziedziczenia w dowolnej formie, zamiast tego dążenia do kompozycji . Istnieje wystarczająca literatura i dyskusja w innym miejscu na temat tego powiedzenia, na przykład na temat samych programistów SE lub SO , a większe pytanie, dlaczego preferować kompozycję, jest trochę nie na temat tworzenia gier. Krótko mówiąc, jest to podejście, które zwykle poprawia zmienność i łatwość konserwacji.

— Społeczność
źródło

Odpowiedź Josha jest niesamowita, ale chciałbym dodać:

Jedną z najfajniejszych funkcji Entity / Component jest oparty na danych sposób, w jaki każda „rzecz” w grze jest tworzona i zarządzana. Z tego, co widziałem, po utworzeniu ładnej biblioteki typów komponentów i systemów możesz budować praktycznie wszystko przy minimalnych modyfikacjach kodu. (Uwaga: minimalna! = 0 )

Definiując grę pod kątem zachowania i dając sobie możliwość modyfikowania tych zachowań w locie - w czasie wykonywania, podczas inicjalizacji poprzez ładowanie ich ze skryptu lub bazy danych itp. - otwieracie cały świat nowych możliwości. Chcesz się dowiedzieć, dlaczego twoje cienie nie lądują tam, gdzie można się spodziewać? Dodaj element kamery / POV do swojego światła.

Podmiot / komponent pozwala budować, co tylko chcesz, o ile utworzyłeś bloki.

Ponadto wielokrotne dziedziczenie powoduje ten sam problem, co pojedyncze dziedziczenie. Po dodaniu atrybutu lub zachowania w hierarchii następuje jego propagacja. Tak długo, jak tworzysz głębokie hierarchie, napotykasz niepotrzebne ciężary, powielasz kod lub rozwiązujesz konflikty. Większości tego można uniknąć, wyobrażając sobie grę jako dane.

Właśnie zacząłem grać z tym w ciągu ostatnich kilku tygodni, ale jestem pod wrażeniem, jak proste stały się rzeczy. To nie jest srebrna kula - natknąłem się na kilka przypadków, w których przymocowanie lambdy do komponentu było najczystszym i najwygodniejszym sposobem rozwiązania problemu - ale jest to całkiem dobry wzór, jeśli można to tak nazwać.

Z nieco pokrewną uwagą: jeden z dużych, nudnych generatorów konserwacji w aplikacjach zorientowanych na dane (strony internetowe itp.) Mapuje obiekty hierarchiczne na relacyjne bazy danych. Mamy wiele fajnych rozwiązań, ale ostatecznie są to wszystkie hacki zaprojektowane w celu spłaszczenia hierarchii. Zamiast budować model w taki sposób, aby spełniał cel aplikacji, kończy się kompromis między efektywną hierarchią a logiczną reprezentacją relacyjną. Pomyślałem o przebudowaniu dość dużej hierarchii w jednej z moich aplikacji jako systemu encji / komponentów - porzuć hierarchię i uczyń bazę danych Złotym Standardem do końca wdrożenia - i jest obiecująca.

Po zintegrowaniu funkcji takich jak dynamiczne generowanie kodu / buforowanie kodu, które mogą rozwiązać problemy z wydajnością, uzyskuje się szybką, elastyczną, logiczną architekturę, która może po prostu zrealizować cel OOP wielokrotnego użytku w znacznie, znacznie lepszy sposób.

— 3Dave
źródło