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]

@Pilsener
Nie zrozumiałeś mnie. Zdarzyło Ci się kiedyś przepisywać zbyt elastyczny kod obiektowy ? Mi tak. Przepisywałem też wiele "kodów proceduralnych". Trzeba umieć znaleźć złoty środek i nie robić niczego na wyrost zarówno w podejściu proceduralnym jak i obiektowym. O to mi tylko chodziło. Projektowanie i implementacja powinny iść za wymaganiami, a nie na odwrót. Wielokrotnie zastosowałem jakiś wzorzec zbyt wcześnie. Fan wzorców to wada, a nie zaleta. Ortodoksja w obiektowości jest tak samo zła jak w podejściu proceduralnym.

Jeśli same imiona będą wyróżnikami zupełnie innej roli klasy to dlaczego nie możnabyłoby nazywać klas imionami ? Zakładam sytuację, że są 3 osoby w grze komputerowej. Każda z nich ma imiona. Daniel - gotuje, myje okna, daje jedzenie psom na podworku. Ania - myje okna, wyrzuca smieci, odkurza, Krzysiek - myje podlogi, wyciera kurze. Jak widzimy każda z tych osób to zupełnie inna rola (dziedzinowa) w aplikacji. Jeśli założymy, że w naszej grze w pierwszej wersji nie ma możłiwości wymiany rolami między osobami po co robić osobne interfejsy i uelastyczniać ? Na co uelastyczniać ? Oczywiście tworzenie obiektów osób w takiej sytuacji jest dziwactwem, ale nie trzeba tego robić można przecież zrobić: Krzysiek::umyjPodloge(). Odrazu widzimy w kodzie Kto i Co. Na takim etapie rozwoju programu elastyczność jest bezużyteczna. Jeśłi natomiast chcielibyśmy aby nagle Krzyś również mógł robić to co Ania - wtedy dopiero elastyczność ma sens i można zastosować to co pisał Crozin i inni.

Ten post edytował LSM 2.12.2011, 10:52:36