w jaki sposób zabieracie się do zrozumienia kodu aplikacji która używa dziedziczenia w taki sposób że: klasa abstrakcyjna Pets ma jakieś metody domyślne które rozwiązują problem klasa abstrakcyjna BDogs dziedziczy po A, i tworzy domyślne metody przetwarzania dla jakiejś grupy problemów klasa abstrakcyjna BCats dziedziczy po A, ale rozwiązuje trochę inne grupy problemów klasa final CDogs dziedziczy po BDogs, i rozwiązuje konkretny specyficzny problem (i jej output już trafia do usera przez controller) klasa final CCats dziedziczy po BCats, i rozwiązuje konkretny specyficzny problem (i jej output już trafia do usera przez
drzewo dla uproszczenia, format "nazwa klasy[A,F]" gdzie A to abstract, F to final
Pets[A] / \ BDogs[A] ---------- BCats[A] ----|------------------|--- CDogs[F] ------------ CCats[F] oczywiście to uproszczenie bo w każdym rzędzie jest o wiele więcej implementacji każda z tych ścieżek może napisać lub może pozostawić jakieś metody z nadrzędnych co powoduje że ciężko nawigować po takim kodzie co więcej czasami w metodach podrzędnych wywoływany jest parent metody nadrzędnej, a czasami jest napisywany taka struktóra powoduje wiele utudnień np. IDE nie zawsze wie do jakiej metody powinien przeskoczyć (gdzie jest kod) lub znaleźć wystąpienia/ użycia metody
-------------------------------------------- 1. czy to normalne i akceptowalne projektowanie interfejsu obiektów? w clean code nie udało mi się czegoś podobnego znaleźć, słyszałem o regule prefer composition over inheritance, ale chcę się upewnić. 2. czy to normalne że zrozumienie takiego czegoś zajmuje dużo czasu? są jakieś metody by sobie to ułatwić? 3. b. trudno było mi znaleźć wystąpienia / użycia metody by spr gdzie zmiana w moim kodzie może spowodować problemy, są na to jakieś sposoby 4. ciężko mi było odnaleźć ścieżkę wykonywania aplikacji w takim kodzie, i musiałem się ucieć do debugowania, ale jest to dość wolne i trzeba było je wiele razy powtarzać bo ciężko było zapamiętać co się dzieje w różnych przypadkach, ale może istnieje jakaś lepsza metoda ogarnięcia tego?
@lukasz1985m: To chyba idealne miejsce na użycie patternu delegator, ale nie mam aż takiego ekspa żeby się o tym w 100% wypowiadać. Jestem ciekaw, dlaczego lepiej twoim zdaniem użyć dziedziczenia w tym wypadku?
@lukasz1985m: Dzięki za odpowiedź. Widać, że masz sporą wiedzę jak na wykopowe standardy - z ciekawości, zamujesz się ogólnie projektowaniem oprogramowania i architekturą, czy to po prostu twój konik? Podchodzisz do tematu "po bożemu", tzn. na początku analiza wymagań, UML, DFD, a dopiero potem implementacja.
#rosja #ukraina Niesamowite jest to, że my polacy pomagamy w upadku wschodniej kultury europejskiej. Przez stulecia nasza kultura była bliska kulturze rosyjskiej. Nagle wszyscy chcą zachodu, który dąży do likwidacji tego co budowaliśmy przez setki lat. Upadek Rosji, nie jest nam na rękę.
klasa abstrakcyjna Pets ma jakieś metody domyślne które rozwiązują problem
klasa abstrakcyjna BDogs dziedziczy po A, i tworzy domyślne metody przetwarzania dla jakiejś grupy problemów
klasa abstrakcyjna BCats dziedziczy po A, ale rozwiązuje trochę inne grupy problemów
klasa final CDogs dziedziczy po BDogs, i rozwiązuje konkretny specyficzny problem (i jej output już trafia do usera przez controller)
klasa final CCats dziedziczy po BCats, i rozwiązuje konkretny specyficzny problem (i jej output już trafia do usera przez
drzewo dla uproszczenia, format "nazwa klasy[A,F]" gdzie A to abstract, F to final
Pets[A]/ \
BDogs[A] ---------- BCats[A]
----|------------------|---
CDogs[F] ------------ CCats[F]
oczywiście to uproszczenie bo w każdym rzędzie jest o wiele więcej implementacji
każda z tych ścieżek może napisać lub może pozostawić jakieś metody z nadrzędnych co powoduje że ciężko nawigować po takim kodzie
co więcej czasami w metodach podrzędnych wywoływany jest parent metody nadrzędnej, a czasami jest napisywany
taka struktóra powoduje wiele utudnień np. IDE nie zawsze wie do jakiej metody powinien przeskoczyć (gdzie jest kod) lub znaleźć wystąpienia/ użycia metody
--------------------------------------------
1. czy to normalne i akceptowalne projektowanie interfejsu obiektów? w clean code nie udało mi się czegoś podobnego znaleźć, słyszałem o regule prefer composition over inheritance, ale chcę się upewnić.
2. czy to normalne że zrozumienie takiego czegoś zajmuje dużo czasu? są jakieś metody by sobie to ułatwić?
3. b. trudno było mi znaleźć wystąpienia / użycia metody by spr gdzie zmiana w moim kodzie może spowodować problemy, są na to jakieś sposoby
4. ciężko mi było odnaleźć ścieżkę wykonywania aplikacji w takim kodzie, i musiałem się ucieć do debugowania, ale jest to dość wolne i trzeba było je wiele razy powtarzać bo ciężko było zapamiętać co się dzieje w różnych przypadkach, ale może istnieje jakaś lepsza metoda ogarnięcia tego?
#programowanie
Komentarz usunięty przez autora
Komentarz usunięty przez autora
Komentarz usunięty przez autora