Zpo-9-wyk-Slajd36: 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:
==Proxy: konsekwencje==
==Self-Encapsulate Field==


[[Image:zpo-9-wyk-Slajd36.PNG|Proxy: konsekwencje]]
[[Image:zpo-9-wyk-Slajd36.PNG|Self-Encapsulate Field]]




Istnieją trzy podstawowe rodzaje wzorca Proxy:
Fowler wyróżnił dwa przekształcenia dotyczące hermetyzacji pól, w zależności od celu ich stosowania. W pierwszym przypadku jest on związany z koniecznością zmiany sposobu odczytywania wartości pola w podklasach. Ponieważ pola nie są polimorficzne, dlatego konieczne jest hermetyzowanie ich poprzez metody get/set.


Zdalny obiekt Proxy (ang. ''remote'' ''proxy'' ) służy do reprezentacji obiektu znajdującego się w innej przestrzeni adresowej, np. na innym komputerze. Dzięki temu dla lokalnych klientów wszystkie odwołania są pozornie lokalne. Proxy przejmuje wówczas odpowiedzialność za zdalne wywołania metod poprzez sieć, serializację parametrów i odebranie wyników. Mechanizm ten jest stosowany w większości środowisk przetwarzania rozproszonego np. CORBA lub EJB.
Mechanika jest intuicyjnie prosta: należy utworzyć parę metod get/set i zadeklarować w nich niepubliczny poziom widoczności (ponieważ użytkownikami tych metod mają być podklasy, a nie klasy dostępne w inny sposób). Następnie odwołania do pola występujące w podklasach należy zastąpić wywołaniami metod get/set i zadeklarować pole jako prywatne.
 
Wirtualny obiekt Proxy zastępuje obiekt RealSubject o dużych wymaganiach zasobowych, np. alokującego duży obszar pamięci. Aby opóźnić (a w szczególnych przypadkach nawet zastąpić) proces tworzenia takiego obiektu, Proxy obsługuje wszystkie zadania obiektu RealSubject, które nie wymagają odwołań do tego obszaru pamięci.  
 
Ochronny obiekt Proxy zajmuje się zabezpieczeniem dostępu do obiektu RealSubject przed nieautoryzowanym dostępem. Obiekt RealSubject nigdy nie jest bezpośrednio dostępny dla klientów; w ich imieniu występuje Proxy, który określa, którym z nich można udostępnić usługi oferowane przez RealSubject, a którym nie.




[[zpo-9-wyk-Slajd35 | << Poprzedni slajd]] | [[zpo-9-wyk-toc|Spis treści ]] | [[zpo-9-wyk-Slajd37 | Następny slajd >>]]
[[zpo-9-wyk-Slajd35 | << Poprzedni slajd]] | [[zpo-9-wyk-toc|Spis treści ]] | [[zpo-9-wyk-Slajd37 | Następny slajd >>]]

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

Self-Encapsulate Field

Self-Encapsulate Field


Fowler wyróżnił dwa przekształcenia dotyczące hermetyzacji pól, w zależności od celu ich stosowania. W pierwszym przypadku jest on związany z koniecznością zmiany sposobu odczytywania wartości pola w podklasach. Ponieważ pola nie są polimorficzne, dlatego konieczne jest hermetyzowanie ich poprzez metody get/set.

Mechanika jest intuicyjnie prosta: należy utworzyć parę metod get/set i zadeklarować w nich niepubliczny poziom widoczności (ponieważ użytkownikami tych metod mają być podklasy, a nie klasy dostępne w inny sposób). Następnie odwołania do pola występujące w podklasach należy zastąpić wywołaniami metod get/set i zadeklarować pole jako prywatne.


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