Zpo-8-wyk-Slajd43: 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:
==Replace Constructor with Factory Method==
==Feature Envy==


[[Image:zpo-8-wyk-Slajd43.PNG|Replace Constructor with Factory Method]]
[[Image:zpo-8-wyk-Slajd43.PNG|Feature Envy]]




Przekształcenie to pozwala zmienić sposób tworzenia obiektu pewnej klasy (i jej podklas) z wywołania konstruktora na użycie wzorca Factory Method. Dzięki niemu możliwe jest stworzenie logicznego konstruktora – metody, która, w odróżnieniu od "zwykłego" konstruktora może zachowywać się polimorficznie, a także dokonywać wyboru konkretnej klasy (wśród klas posiadających ten sam typ, np. dziedziczonych). Zwykły konstruktor w momencie wywołania operuje na utworzonym już obiekcie własnej klasy, dlatego takiej możliwości nie posiada. Zatem celem przekształcenia jest zastąpienie konstruktora jako metody tworzenia obiektów przez klientów – wywołaniem metody-fabryki.
Problem ten dotyczy sytuacji, w której metoda częściej odwołuje się do metod obcych klas niż do metod własnej klasy. Zazdrość o funkcje jest także związana z niewłaściwą hermetyzacją, jednak podstawowym problemem opisywanym przez ten przykry zapach jest niepoprawne rozmieszczenie metod w klasach. Typowym ilościowym wskaźnikiem tego przykrego zapachu jest niska spójność klasy: jej metody nie realizują spójnego zbioru funkcji.


Przekształcenie składa się z trzech kroków. Pierwszym jest stworzenie metody-fabryki (czyli zwykle metody statycznej przyjmującej parametry pozwalające dokonać wyboru klasy, i które można przekazać konstruktorowi), która jedynie wywołuje konstruktor. Następnie wywołania konstruktora w kodzie klientów są zastępowane wywołaniami metody-fabryki. Aby uniemożliwić tworzenie obiektów bez pośrednictwa metody-fabryki, należy zadeklarować konstruktor jako prywatny.
Podobnie jak w opisanym wcześniej przypadku niewłaściwej hermetyzacji, z problemem tym można poradzić sobie przenosząc składowe do klasy najbardziej je wykorzystujących. Czasem jednak jest to niemożliwe, ponieważ zwiększałoby liczbę powiązań między pozostałymi klasami. Wówczas zastosowanie znajduje np. wzorzec projektowy Visitor, w którym obiekt wywołując metodę przekazuje jej referencję do samego siebie, umożliwiając tzw. odwrócenie sterowania. Pozwala to ograniczyć liczbę zbędnych asocjacji między klasami.
 
Po wykonaniu przekształcenia można rozwijać logikę metody-fabryki: wyposażyć ją w pamięć utworzonych obiektów lub dokonywać w niej wyboru klasy tworzonego obiektu.




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

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

Feature Envy

Feature Envy


Problem ten dotyczy sytuacji, w której metoda częściej odwołuje się do metod obcych klas niż do metod własnej klasy. Zazdrość o funkcje jest także związana z niewłaściwą hermetyzacją, jednak podstawowym problemem opisywanym przez ten przykry zapach jest niepoprawne rozmieszczenie metod w klasach. Typowym ilościowym wskaźnikiem tego przykrego zapachu jest niska spójność klasy: jej metody nie realizują spójnego zbioru funkcji.

Podobnie jak w opisanym wcześniej przypadku niewłaściwej hermetyzacji, z problemem tym można poradzić sobie przenosząc składowe do klasy najbardziej je wykorzystujących. Czasem jednak jest to niemożliwe, ponieważ zwiększałoby liczbę powiązań między pozostałymi klasami. Wówczas zastosowanie znajduje np. wzorzec projektowy Visitor, w którym obiekt wywołując metodę przekazuje jej referencję do samego siebie, umożliwiając tzw. odwrócenie sterowania. Pozwala to ograniczyć liczbę zbędnych asocjacji między klasami.


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