Interfejs i klasa abstrakcyjna Opcje

[daniel1302]

Witam, mam problem teoretyczny. Jest taka sytuacja
Mam klasę abstrakcyjną Człowiek, która realizuje jakieś opcje.
I różni ludzie dziedziczą po tej klasie np:

[PHP] pobierz, plaintext 
class Daniel extends Czlowiek
{
...
}
[PHP] pobierz, plaintext 

i chcę aby każdy człowiek posiadał odpowiednie metody(które np ustalają co człowiek potrafi, jak myśli, dla każdego wykonanie tej metody ma być inna).

mogę zrealizować to za pomocą interfejsu np. Interface Genetyka

[PHP] pobierz, plaintext 
interface Genetyka
{
public function wyglad();
public function umiejetnosci();
}
[PHP] pobierz, plaintext 

i wtedy będę miał:

[PHP] pobierz, plaintext 
class Daniel extends Czlowiek implements Genetyka
{
...
}
[PHP] pobierz, plaintext 

ale coś mnie to kole w oczy. Ale mogę dodać metody do klasy abstrakcyjnej skoro i tak każdy człowiek po niej dziedziczy.
Co wy byście zrobili. Zastosowali interface czy dodali definicje metod do klasy.

Ten post edytował daniel1302 30.11.2011, 17:32:19

[LSM]

Jak zajdzie potrzeba zmian to kolega sobie to zrefaktoryzuje i juz

Dokładnie tak się powinno trworzyć aplikację. Uelastycznianie na wyrost to poważny błąd. A co jeśli w aplikacji będzie 4 aktorów o różnych imieniach i przez kolejne 10 lat nic poza tym ? Myślenie o elastyczności w takim przypadku nie ma sensu. Macie wszyscy po trochu racji, ale jak zwykle na tym forum.. eh nie ważne.
Każdy z was mówi o nieco innych przypadkach i podejściach. Najlogiczniejsze jest dla mnie to co pisze Orzeszekk. Dziedziczenie jest użyteczne, przy komplikowaniu się kodu w którym jest ono używane - należy go refaktoryzować w celu stosownia np. Strategii, ale nigdy tych czynności nie należy robić zbyt wcześnie ponieważ elastyczność potrafi niepotrzebnie skomplikować projekt.

A poza tym nie ma wiedzy jedynie prawdziwej, biorąc pod uwagę fakt oszczędzania czasu i nie marnowania go na "kombinatorykę elastyczną" - należy pójść na początku po najmniejszej linii oporu Orzeszka, jeśli zajdzie potrzeba użyć rozwiązania Crozina lub zupełnie innego, bo można ten apsekt zaprogramować na dziesiątki sposobów. Będzie to zależeć od wymagań jakie postawi nam dalszy rozwój aplikacji. Jeśli Crozin na początku zaczniesz wszystko uelastyczniać na "wydaje mi się" - możesz się zakopać w swoich kombinacjach i gdy przyjdzie czas na wdrożenie czegoś nowego okarze się, że tak uelastyczniłeś system, że stał się nieczytelny i trudny w rozwoju. Niekoniecznie to co napisałeś musi być jedynie prawdziwe i poprawne. Znajde Ci 10 sposobów różnych na to jak sprawić aby to rozwiązanie Człowieka było elastyczne i przygotowane na ewentualnie - każdą zmiane - ale takie myślenie nie ma zupełnie sensu, jest alogiczne, bo który sposób wybierzesz ? A jeśli strategia którą wybierzesz okarze się nieużyteczna i błędna to będziesz musiał zmienić większą ilość kodu niż przed wprowadzeniem strategii. Z elastycznością czeka się do ostatniego momentu - nigdy nie robi się tego na samym początku projektowania. Tak podpowiada mi moje doświadczenie.

(IMG:style_emoticons/default/oneeyedsmiley02.png)