Dziedziczenie a kompozycja

Zarabiam pieniądze w C # Ogólnie w tym języku lubię rozdzielać wszystko do niebios za pomocą interfejsów. Pomogło mi to dobrze w kodzie korporacyjnym, ale przy pisaniu gier w C # mam tendencję do dziedziczenia, ponieważ jestem w stanie zdefiniować pewne domyślne zachowania dla klas podstawowych. Czuję się przy tym brudny, jakbym był nieposłuszny jakimś bogom architektury, który kiedyś powiedział „faworyzuj kompozycję zamiast dziedziczenia”. Wiem, że nie jest czarno-biały, ale wydaje mi się, że mógłbym użyć interfejsów z nieco większą pracą i osiągnąć mniej więcej to samo.

Co robią inni ludzie? Czy dziedziczenie jest właściwym podejściem do gier, czy powinienem dokonać refaktoryzacji w niektórych interfejsach?

Dziedziczenie w grach jest w rzeczywistości jedną z najgorszych rzeczy, które możesz zrobić - w szczególności w odniesieniu do bytów. Przeczytaj to, dlaczego. Kompozycja zamiast dziedziczenia zabiera Cię w gry. Jeśli chodzi o inne obszary silnika, tak naprawdę nie ma to znaczenia. Załóżmy na przykład, że wykonujesz połączenie z zewnętrzną usługą sieciową, a następnie możesz odziedziczyć jedną rodzajową usługę np. HTTPService i SocketService - bardzo podobnie jak w aplikacjach korporacyjnych, do których jesteś przyzwyczajony.

Chyba, że gra jest bardzo prosta, to będzie chciał użyć jednostki (CBE) architekturę modułową. Ogólna idea jest taka, że ​​w przypadku encji przyczyną tak powszechnego tworzenia, a nie dziedziczenia jest to, że nie można wiedzieć do czasu uruchomienia, jakie możliwości będzie miała dana jednostka. Weźmy na przykład statek gracza w kosmicznej strzelance. Do pewnego momentu podczas gry nie wiesz, jaką broń, zbroję, systemy (tj. Komponenty) ten gracz będzie zbierał, kupował, sprzedawał, gubił, zniszczył itp. Tak więc jedynym realistycznym sposobem modelowania tego jest poprzez kompozycję obiektu. Zaletą tego scenariusza jest to, że możesz mieć w pełni konfigurowalnych wrogów zbudowanych w ten sam sposób, a nie wrogów, którzy są zawsze tacy sami za każdym razem, gdy widzisz tego typu wroga. Tak więc w przypadku CBE możesz zobaczyć marsjańskiego frachtowca i pomyśleć: „Ach, ma tylko małe lasery, zdejmę go”, i zwykle byłoby to prawdą, ale kiedy nagle znajdziesz się w zasięgu, zdajesz sobie sprawę, że ma duży tyłek pistolet czasoprzestrzenny. Niespodzianka niespodzianka!

Komponentizacja usuwa niejawne sprzężenie logiki, i to jest DOBRE.

Dla tych, którzy mówią po niemiecku, interesująca książka: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Implementierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Bliższe spojrzenie na to, kiedy i dlaczego wykorzystać którą architekturę można znaleźć tutaj: /programming/1901251/component-based-game-engine-design

Dla siebie decyduję o mojej architekturze w zależności od wielkości projektu i możliwości rozszerzenia lub ponownego użycia kodu. Po co inwestować godziny w architekturę mikroprojektów, w których nie ma szans na ponowne użycie kodu? W tym samym czasie możesz zakończyć projekt.

Kompozycja a komponenty Komponenty to fajne, fantazyjne rzeczy, ale w większości projektów / architektur kompozycja również to robi (bez narzutu na komponenty). To zależy od tego, co twój system komponentów może zapewnić, czego kompozycja nie może.

Weźmy na przykład statek gracza w kosmicznej strzelance. Do pewnego momentu podczas gry nie wiesz, jaką broń, zbroję, systemy (tj. Komponenty) ten gracz będzie zbierał, kupował, sprzedawał, gubił, zniszczył itp. Tak więc jedynym realistycznym sposobem modelowania tego jest poprzez kompozycję obiektu.

wszystko to było dawno możliwe także bez komponentów