Zpo-8-wyk-Slajd44: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Linia 1: Linia 1:
==Przykład==
==Parallel Inheritance Hierarchies==


[[Image:zpo-8-wyk-Slajd44.PNG|Przykład]]
[[Image:zpo-8-wyk-Slajd44.PNG|Parallel Inheritance Hierarchies]]




W tym przykładzie przekształceniu ulega obiekt KartaCzytelnicza. W miejsce publicznego konstruktora tworzona jest metoda-fabryka, która wywołuje ten sam konstruktor, ale już zadeklarowany jako prywatny.
Równoległe hierarchie dziedziczenia mogą oznaczać błąd w przydziale odpowiedzialności do klas, ponieważ stworzenie klasy w jednej hierarchii oznacza również konieczność stworzenia jej odpowiednika w drugiej. Jednak ocena nie jest całkowicie jednoznaczna: podobne rozwiązania stosuje się w kilku wzorcach projektowych z rodziny Factory (np. Factory Method czy Abstract Factory). Wówczas obiekt tworzący jest także odseparowany od produktu, i dodanie jednego z nich wymaga dodania także drugiego. Zatem obecność tego przykrego zapachu należy badać dość ostrożnie.


Dzięki temu przekształceniu tworzenie instancji klasy KartaCzytelnicza stało się procesem bardziej abstrakcyjnym, niepowiązanym z konkretną klasą. Pozwala to na dalszą rozbudowę i ewolucję metody-fabryki.
Rozwiązanie polega na przeniesieniu odpowiedzialności z klas jednej hierarchii do drugiej, połączone z unifikacją ich interfejsów. Prowadzi to w dużej mierze do pozostawienia jednej hierarchii klas i usunięcia zbędnych odpowiedników w drugiej.




[[zpo-8-wyk-Slajd43 | << Poprzedni slajd]] | [[zpo-8-wyk-toc|Spis treści ]] | [[zpo-8-wyk-Slajd45 | Następny slajd >>]]
[[zpo-8-wyk-Slajd43 | << Poprzedni slajd]] | [[zpo-8-wyk-toc|Spis treści ]] | [[zpo-8-wyk-Slajd45 | Następny slajd >>]]

Aktualna wersja na dzień 18:14, 4 lis 2006

Parallel Inheritance Hierarchies

Parallel Inheritance Hierarchies


Równoległe hierarchie dziedziczenia mogą oznaczać błąd w przydziale odpowiedzialności do klas, ponieważ stworzenie klasy w jednej hierarchii oznacza również konieczność stworzenia jej odpowiednika w drugiej. Jednak ocena nie jest całkowicie jednoznaczna: podobne rozwiązania stosuje się w kilku wzorcach projektowych z rodziny Factory (np. Factory Method czy Abstract Factory). Wówczas obiekt tworzący jest także odseparowany od produktu, i dodanie jednego z nich wymaga dodania także drugiego. Zatem obecność tego przykrego zapachu należy badać dość ostrożnie.

Rozwiązanie polega na przeniesieniu odpowiedzialności z klas jednej hierarchii do drugiej, połączone z unifikacją ich interfejsów. Prowadzi to w dużej mierze do pozostawienia jednej hierarchii klas i usunięcia zbędnych odpowiedników w drugiej.


<< Poprzedni slajd | Spis treści | Następny slajd >>