2013-02-17 16 views
6

Piszę prostą grę i wiele obiektów gry udostępnia atrybuty. Mam do tego dwie potencjalne implementacje.Czy powinienem używać w tym przypadku dziedziczenia lub kompozycji?

Pierwszym jest użycie dziedziczenia, jak określono w następujący obraz:

Class Hierarchy

pogrubiony klasy są klasy abstrakcyjne, jak można się było spodziewać. Gałęzie są klasami pochodnymi, które są faktycznie używane. Należy zauważyć, że te klasy przechowują dane o obiektach, nie ma z nimi żadnej funkcjonalności.

Na przykład, Troop i Vehicle mają wspólny interfejs, którego używają zarówno do ataków() i move(). Hierarchia klas przedstawiona powyżej to tylko surowe statystyki. Ponadto wszystkie one są prawdziwymi relacjami ISA.

Drugie zastosowanie wykorzystuje kompozycję. Zamiast powyższej hierarchii klas każda z klas abstrakcyjnych to "moduły" przechowujące określone elementy danych. Tak więc SpecialAbility ma element danych o nazwie PointsValueObject (chociaż zmieniłem nazwy abstraktów (choć nie są już one abstrakcyjne), aby odzwierciedlić ich charakter modularno-atrybutowy). A Troop ma członków danych: PointsValueObject, PhysicalObject, PhysicalAttackObject i BattleOBject, z których każdy jest modułem przechowującym dane o oddziale. Ponownie, w tych modułach nie istnieje żadna funkcjonalność, służą one wyłącznie do przechowywania danych. Zachowanie i funkcjonalność są nadal implementowane za pośrednictwem klas interfejsu.

Moje pytanie brzmi następująco: ludzie na ogół wolą kompozycję niż dziedziczenie, ale w tym przypadku jestem skłonny trzymać się spadku, ponieważ relacje ISA są utrzymywane, a hierarchia nie zawiera zachowań, tylko dane. Czy ta hierarchia jest dobra OOD, czy buduje klasy za pomocą atrybutu "modules" lepiej?

+1

Podejście "moduły" jest podobne do podejścia opartego na komponentach (system encji) (http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of -mmog-development-part-1 /) używane generalnie w tworzeniu gier. Sugeruje to pewną dodatkową złożoność, ale jest naprawdę przyjemna z punktu widzenia ponownego wykorzystania i rozszerzalności. Nie wiem, który byłby lepszy, każde podejście ma swoje zalety i wady, ale to zależy od ciebie, aby je zrównoważyć i zdecydować, które podejście pasuje do twojego problemu. – asermax

Odpowiedz

4

Jeśli nie ma kodu, który zostanie ponownie użyty, jaką korzyść widzisz w korzystaniu z dziedziczenia? Dziedziczenie jest przydatne dla DRY (Nie powtarzaj się), gdy zachowanie jest takie samo, ale bez zachowania wszystko, co robisz, potencjalnie ogranicza się - jeśli później zdecydujesz się na sub hierarchię, która potrzebuje mniej danych, nie ma dobrego rozwiązania za to.

+0

Przepraszamy, co to jest DRY? – Slims

+0

Nie powtarzaj się – KidTempo

Powiązane problemy