Zpo-6-wyk-Slajd7: 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:
==Add Parameter==
==Abstract Factory: struktura==


[[Image:zpo-6-wyk-Slajd7.PNG|Add Parameter]]
[[Image:zpo-6-wyk-Slajd7.PNG|Abstract Factory: struktura]]




Przekształcenie Add Parameter dotyczy sytuacji, w której metoda potrzebuje od klienta więcej informacji, niż otrzymuje w tej chwili. Zatem konieczne jest przekazanie jej nowego parametru.
Klient, analogicznie do rozwiązania stosowanego w Factory Method, odwołuje się do klasy AbstractFactory służącej do tworzenia grupy różnych produktów. Każdy produkt jest tworzony przez osobną metodę, która sama stosuje wzorzec Factory Method. AbstractFactory jest klasą abstrakcyjną, tzn. nie definiuje, w jaki sposób mają być tworzone odpowiednie produkty; deklaruje jedynie obecność odpowiedzialnych za to metod. Tworzeniem konkretnych produktów zajmują się jej implementacje, w których każda z metod tworzy odpowiedni obiekt należący do typu danego produktu.


Mechanika tej refaktoryzacji przebiega w taki sposób, aby maksymalnie wydłużyć okres, w którym istnieją jednocześnie dwie wersje metody, dotychczasowa i nowa, z dodanym parametrem. Jest to charakterystyczny sposób postępowania występujący w wielu przekształceniach, pozwala bowiem zapewnić drogę odwrotu w przypadku niepowodzenia.
Klient postrzega instancje produktów wyłącznie poprzez zdefiniowane interfejsy AbstractProdyct. Poniżej warstwy abstrakcji znajdują się implementacje tych interfejsów (np. ProductA1 i ProductA2) które są tworzone właśnie przez obiekty ConcreteFactory.


Pierwszym krokiem (poza sprawdzeniem czy metoda jest polimorficzna, co uniemożliwiłoby prawidłowe zakończenie przekształcenia) jest stworzenie nowej metody z dodanym parametrem, do której skopiować należy ciało starej metody (warto zauważyć, że nowy parametr pozostaje w niej niewykorzystany). Następnie należny zmienić starą metodę w ten sposób, aby delegowała przychodzące wywołania do nowej wersji, przekazując dowolną wartość w miejsce nowego parametru. W kolejnym kroku należy zmodyfikować klientów metody, tak aby odwoływali się do nowej wersji metody. Ostatnim etapem może być usunięcie starej metody, o ile nie jest ona potrzebna z innych względów (np. uczestnictwa w interfejsie).
Klient, wybierając odpowiednią fabrykę ConcreteFactory, decyduje jednocześnie o wyborze całej rodziny Produktów. To pozwala zmieniać całe rodziny produktów w prosty sposób – posługując się inną implementacją fabryki.




[[zpo-6-wyk-Slajd6 | << Poprzedni slajd]] | [[zpo-6-wyk-toc|Spis treści ]] | [[zpo-6-wyk-Slajd8 | Następny slajd >>]]
[[zpo-6-wyk-Slajd6 | << Poprzedni slajd]] | [[zpo-6-wyk-toc|Spis treści ]] | [[zpo-6-wyk-Slajd8 | Następny slajd >>]]

Aktualna wersja na dzień 11:11, 17 paź 2006

Abstract Factory: struktura

Abstract Factory: struktura


Klient, analogicznie do rozwiązania stosowanego w Factory Method, odwołuje się do klasy AbstractFactory służącej do tworzenia grupy różnych produktów. Każdy produkt jest tworzony przez osobną metodę, która sama stosuje wzorzec Factory Method. AbstractFactory jest klasą abstrakcyjną, tzn. nie definiuje, w jaki sposób mają być tworzone odpowiednie produkty; deklaruje jedynie obecność odpowiedzialnych za to metod. Tworzeniem konkretnych produktów zajmują się jej implementacje, w których każda z metod tworzy odpowiedni obiekt należący do typu danego produktu.

Klient postrzega instancje produktów wyłącznie poprzez zdefiniowane interfejsy AbstractProdyct. Poniżej warstwy abstrakcji znajdują się implementacje tych interfejsów (np. ProductA1 i ProductA2) które są tworzone właśnie przez obiekty ConcreteFactory.

Klient, wybierając odpowiednią fabrykę ConcreteFactory, decyduje jednocześnie o wyborze całej rodziny Produktów. To pozwala zmieniać całe rodziny produktów w prosty sposób – posługując się inną implementacją fabryki.


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