[PHP][OOP] wielokrotne dziedziczenie, pytanie natury projektowo-filozoficzno-dywagacyjnej Opcje

[Kedan]

Mam zależność tego typu:

[PHP] pobierz, plaintext 
<?php
class myObject{
    //...
}
 
class myModule extends myObject {
    //....
}
 
class myModuleExt extends myModule {
    //....
}
?>
[PHP] pobierz, plaintext 

ale do tego mam zależność:

[PHP] pobierz, plaintext 
<?php
class myConcreteModule extends myModule {
    //...
}
 
// i tu pojawia się problem
class myConcreteModuleExt extends myModuleExt, myConcreteModule {
    //...
}
?>
[PHP] pobierz, plaintext 

Od jakiegoś czasu główkuję jak to rozwiązać, ale nic sensownego nie przychodzi mi do głowy.

Ten post edytował Kedan 11.05.2009, 11:29:35

[Zyx]

Nieraczek -> mała uwaga, że dyskusja nie dotyczy wskaźników, tylko wielokrotnego dziedziczenia.

Wszystkiego trzeba używać z umiarem. Jak ktoś pakuje kompozycję wszędzie, gdzie się da, "bo można cośtam", to jest to takie samo nadużycie, jak próba rozwiązywania wszystkich problemów świata przez dziedziczenie albo wielokrotne dziedziczenie. Więc nie żadne książki itd. a zwykłe myślenie i ludzka inteligencja są najważniejsze, bo to programista pisze kod i programista wie (a przynajmniej powinien), w jakim kierunku powinien on podążać i co powinno być dozwolone. Co komu z tego, że przeczyta książkę o wzorcach projektowych i później najchętniej to by rozszerzanie modelu o własną funkcjonalność w Doctrine w oparciu o kompozycję robił "bo a nuż mu przyjdzie jakiś hardcore'owy pomysł na rozszerzanie tego w trakcie działania". Nieukiem to można być, rzucając się bez głębszego zastanowienia na każdą nowinkę, jaką się gdzieś przeczytało, a nie dlatego, że tu się użyło dziedziczenia, a tam nie. Mój przykład jako rozbudowa przykładu ndx:

1. Piszę szachy. Zasady tej gry powstały 1000 lat temu. Jaka jest szansa, że będę dodawać nowe ruchy itd? Zerowa. Więc dziedziczenie, bo jest prostsze i rozwiązywane w czasie kompilacji, zatem nie ma co się męczyć i spowalniać programu, bo jakaś książka mówi cośtam (mówi to przy założeniu, że autor myśli, co robi).
2. Piszę aplikację do grania w różne odmiany szachów. Każda odmiana ma różne specyficzne reguły, a ponadto np. w "szachach chłopskich" sposób poruszania się figury na planszy może ulegać zmianie w trakcie gry (a użytkownik może chcieć robić własne odmiany). Paradoksalnie, ilość możliwych kombinacji jest wystarczającym argumentem na to, aby tych ruchów nie kodować na sztywno w postaci mnóstwa klas - można je dość prosto opisać jakimś abstrakcyjnym językiem, napisać parser i zrobić jedną klasę, która potrafi się poruszać na podstawie zadanych reguł. Dopiero aby ruchy mogły zmieniać się w trakcie gry, użyłbym kompozycji, i to zorientowanej bardziej na zmianę danych opisujących ruch, a nie jednego obiektu na inny.

Dziedziczenie, wielokrotne dziedziczenie, kompozycja, to tylko narzędzia, a nie cel sam w sobie. Niektóre bardziej niebezpieczne i stwarzające problemy w samym języku (wielokrotne dziedziczenie), inne mniej, ale niewłaściwe użycie to niewłaściwe użycie. Czasem istnieje więcej, niż jedno dobre rozwiązanie i liczą się potrzeby. Dwie możliwe wypowiedzi dotyczące tego samego hipotetycznego kawałka kodu:

1. Użyłem tego rozwiązania, ponieważ daje ono możliwość XXX, z której w istotny sposób korzysta część aplikacji Y. Ponadto użytkownik musi mieć możliwość PPP do wykonania czynności Z, niezbędnej w niektórych sytuacjach.
2. Użyłem tego rozwiązania, ponieważ daje ono możliwość XXX. Jest ona bardzo przydatna, w przeciwieństwie do rozwiązania Y, które wielu często nadużywa, a które jej nie posiada, a wiele zalet tej możliwości można znaleźć np. w książce PPP.

Pozostawiam wam to do przemyślenia i dodam jedynie, że wolałbym pracować z programistą #1...