Zpo-5-wyk-Slajd41: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
WizualnieWikikod
Bwalter (dyskusja | edycje)
2376 edycji
Nie podano opisu zmian
 
Bwalter (dyskusja | edycje)
2376 edycji
Nie podano opisu zmian
 
Linia 1: Linia 1:
==Inappropriate Intimacy==
==Command: konsekwencje==


[[Image:zpo-5-wyk-Slajd41.PNG|Inappropriate Intimacy]]
[[Image:zpo-5-wyk-Slajd41.PNG|Command: konsekwencje]]




Niewłaściwa hermetyzacja jest dość częstym i dobrze znanym problemem. Wiąże się ona nie tylko z niepoprawnym użyciem kwalifikatorów dostępu, ale przede wszystkim z niewłaściwym podziałem odpowiedzialności pomiędzy klasy: jeżeli wymagają one bezpośredniego dostępu do swoich prywatnych części, oznacza to, że są zbyt ze sobą związane.
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ń.


Podstawowym rozwiązaniem jest przesunięcie metod i pól prywatnych do klas, które najbardziej ich potrzebują. Można także ograniczyć wiedzę o sobie dwóch klas, zmieniając relację dwukierunkową na jednokierunkową. Wrażliwe i współdzielone elementy dwóch klas można wyłączyć do nowej klasy, której obiekty będą współdzielone pomiędzy nie, zachowując jednocześnie hermetyzację. Niepoprawna hermetyzacja jest również możliwa wewnątrz hierarchii dziedziczenia – wówczas w celu odseparowania nadklasy od podklas można zmienić dziedziczenie w delegację.
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.




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

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

Command: konsekwencje

Command: konsekwencje


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ń.

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.


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

Źródło: „https://wazniak.mimuw.edu.pl/index.php?title=Zpo-5-wyk-Slajd41&oldid=63973”