Zpo-11-wyk-Slajd14: 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:
==Command: konsekwencje==
==Przykład(4)==


[[Image:zpo-11-wyk-Slajd14.PNG|Command: konsekwencje]]
[[Image:zpo-11-wyk-Slajd14.PNG|Przykład(4)]]




Istotną korzyścią płynącą z zastosowania wzorca jest rozdzielenie zależności pomiędzy nadawcą (Klientem) i odbiorcą (obiektem Receiver) komunikatu. Zastosowanie polimorfizmu pozwala traktować poszczególne polecenia abstrakcyjnie, a co za tym idzie – dodawać nowe typy poleceń bez konieczności zmiany struktury systemu. Poszczególne obiekty Command mogą być dowolnie złożone, także w postaci kompozytów innych poleceń.
Po zakończeniu integracji należy usunąć możliwość wywołania konstruktora klasy KartaCzytelnicza. W tym celu, zamiast fizycznie go usuwać, najlepiej stworzyć pusty prywatny konstruktor, ponieważ w przeciwnym przypadku kompilator i tak wygeneruje domyślny konstruktor bezparametrowy.


Dodatkową zaletą użycia obiektu do hermetyzacji poleceń jest możliwość utworzenia w typie Command przeciwstawnej metody, która odwraca efekt wykonania polecenia. W takiej sytuacji obiekt ConcreteCommand musi zapamiętać stan obiektu Receiver sprzed wykonania operacji lub np. skorzystać z wzorca Memento.
Drugą czynnością jest usunięcie ciała metody ''typKarty'' ''()'' w tej samej klasie i oznaczenie jej jako prywatnej. Od tego momentu klasa KartaCzytelnicza służy jedynie do przechowywania metody-fabryki i jako nadklasa dla klas reprezentujących poszczególne stany. Z punktu widzenia klienta jednak podklasy te są widoczne jedynie poprzez interfejs KartaCzytelnicza.
 
Efektem tego przekształcenia była zamiana pola reprezentującego stan klasy w grupę podklas, z których każda reprezentuje klasę w określonym stanie.




[[zpo-11-wyk-Slajd13 | << Poprzedni slajd]] | [[zpo-11-wyk-toc|Spis treści ]] | [[zpo-11-wyk-Slajd15 | Następny slajd >>]]
[[zpo-11-wyk-Slajd13 | << Poprzedni slajd]] | [[zpo-11-wyk-toc|Spis treści ]] | [[zpo-11-wyk-Slajd15 | Następny slajd >>]]

Aktualna wersja na dzień 17:36, 4 lis 2006

Przykład(4)

Przykład(4)


Po zakończeniu integracji należy usunąć możliwość wywołania konstruktora klasy KartaCzytelnicza. W tym celu, zamiast fizycznie go usuwać, najlepiej stworzyć pusty prywatny konstruktor, ponieważ w przeciwnym przypadku kompilator i tak wygeneruje domyślny konstruktor bezparametrowy.

Drugą czynnością jest usunięcie ciała metody typKarty () w tej samej klasie i oznaczenie jej jako prywatnej. Od tego momentu klasa KartaCzytelnicza służy jedynie do przechowywania metody-fabryki i jako nadklasa dla klas reprezentujących poszczególne stany. Z punktu widzenia klienta jednak podklasy te są widoczne jedynie poprzez interfejs KartaCzytelnicza.

Efektem tego przekształcenia była zamiana pola reprezentującego stan klasy w grupę podklas, z których każda reprezentuje klasę w określonym stanie.


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