Kompozycja vs dziedziczenie Opcje

[lukaskolista]

Cześć, mam problem z decyzją, czy zastosować kompozycję czy dziedziczenie.

Stan aktualny:
MatchInterface (interface)
Match (class, implementuje MatchInterface)

Chciałbym stworzyć nowy rodzaj Matcha (dopasowania), który zyskuje nową metodę "getName()" oraz argument konstruktora względem klasy Match. W tym celu dodałem nowy interface oraz klasę:
NamedMatchInterface (interface dziedziczący po MatchInterface dodający nową metodą getNamed())
NamedMatch (class, implementuje NamedMatchInterface)

Proszę nie zwracać uwagi na na nazewnictwo, jest to PSR ale nie wykluczone, że zmienię tę konwencję, bo mi trochę nie odpowiada.

Moje pytanie brzmi: klasa "NamedMatch" powinna dziedziczyć po klasie "Match" i dodawać nową metodę oraz nadpisać konstruktor, czy jednak zastosować kompozycję?
Z punktu widzenia testów jednostkowych oraz możliwości rozwoju skłaniam się do kompozycji, jednak chciałbym poznać Wasze zdanie.

Edit:
Niby to powinna być kompozycja, bo dochodzi nowa metoda, jednak 4 inne metody są identyczne jak w klasie Match i w przypadku zastosowania kompozycji będą po prostu proxowane do klasy Match.

Ten post edytował lukaskolista 4.12.2016, 14:24:52

[lukaskolista]

Chyba tak jak piszesz interface powinien dziedziczyć, bo opisuje kontrakt, a nie implementację, natomiast implementacja powinna być zrealizowana za pomocą kompozycji.

Tak z ciekawości zapytam:
Jak testujecie klasy, które po sobie dziedziczą? Przykładowo mamy klasę A z metodą x() i y() + mamy testy do tej klasy i metody. Do tego mamy klasę B też z metodą x(), która jest odziedziczona z klasy A, natomiast metoda y() jest inna. Jak testujecie klasę B? Piszecie testy dla metody x() w obu klasach? Dodatkowo co w przypadku, gdy klasa potomna korzysta z metody rodzica + dodaje swoją logikę - nie da się zamockować klasy rodzica, bo dziecziczenie to mechaizm języka.