Zpo-6-wyk-Slajd28: 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:
==Split Temporary Variable==
==Memento: konsekwencje==


[[Image:zpo-6-wyk-Slajd28.PNG|Split Temporary Variable]]
[[Image:zpo-6-wyk-Slajd28.PNG|Memento: konsekwencje]]




To przekształcenie służy dotyczy problemu wielokrotnego użycia zmiennych lokalnych do przechowywania nie związanych ze sobą danych. W efekcie nazwa użytej w ten sposób zmiennej nie oznacza już swego pierwotnego przeznaczenia, co pogarsza czytelność i obniża zrozumienie kodu. Celem refaktoryzacji jest podział jej na nowe zmienne, tak aby przypisanie wartości zawsze dotyczyło nowej zmiennej lokalnej.
W ten sposób obiekt Memento posiada dwa logiczne interfejsy: szeroki, umożliwiający pełen dostęp do ich zawartości, przeznaczony wyłącznie dla obiektu Originator, oraz wąski, w praktyce blokujący dostęp do większości metod, przeznaczony dla pozostałych obiektów, w tym obiektu Caretaker.


Przekształcenie jest realizowane przy istotnym wsparciu ze strony kompilatora. Pierwszym krokiem jest zadeklarowanie zmiennej jako sfinalizowanej. To powoduje, że próba kompilacji automatycznie wskazuje miejsce ponownego przypisania wartości do tej zmiennej. W tym miejscu należy zadeklarować nową zmienną o nazwie odpowiadającej jej przeznaczeniu, i kontynuować pracę aż do usunięcia wszystkich przypisań.
Takie rozwiązanie przede wszystkim zachowuje hermetyczność obiektu Memento, ale również upraszcza obiekt Originator i zmniejsza jego zakres odpowiedzialności. Nie musi już on zajmować się w żaden sposób przechowywaniem migawek stanu, usuwaniem ich etc; Funkcje te zostały wydzielone do obiektów Memento i Caretaker.
 
Pełna hermetyzacja obiektów Memento w stosunku do klasy Caretaker ma także pewne wady: stan przechowywany w tych obiektach może mieć znaczny rozmiar, i zarządzanie nim może wymagać optymalizacji, stosowania heurystycznych algorytmów usuwania niektórych migawek etc. Niestety, ponieważ obiekt Caretaker nie może stwierdzić rozmiaru migawki, nie może również podjąć skutecznego działania w tym kierunku.




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

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

Memento: konsekwencje

Memento: konsekwencje


W ten sposób obiekt Memento posiada dwa logiczne interfejsy: szeroki, umożliwiający pełen dostęp do ich zawartości, przeznaczony wyłącznie dla obiektu Originator, oraz wąski, w praktyce blokujący dostęp do większości metod, przeznaczony dla pozostałych obiektów, w tym obiektu Caretaker.

Takie rozwiązanie przede wszystkim zachowuje hermetyczność obiektu Memento, ale również upraszcza obiekt Originator i zmniejsza jego zakres odpowiedzialności. Nie musi już on zajmować się w żaden sposób przechowywaniem migawek stanu, usuwaniem ich etc; Funkcje te zostały wydzielone do obiektów Memento i Caretaker.

Pełna hermetyzacja obiektów Memento w stosunku do klasy Caretaker ma także pewne wady: stan przechowywany w tych obiektach może mieć znaczny rozmiar, i zarządzanie nim może wymagać optymalizacji, stosowania heurystycznych algorytmów usuwania niektórych migawek etc. Niestety, ponieważ obiekt Caretaker nie może stwierdzić rozmiaru migawki, nie może również podjąć skutecznego działania w tym kierunku.


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