Zpo-7-wyk-Slajd8: 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:
==Change Reference to Value==
==Bridge: uczestnicy==


[[Image:zpo-7-wyk-Slajd8.PNG|Change Reference to Value]]
[[Image:zpo-7-wyk-Slajd8.PNG|Bridge: uczestnicy]]




Potrzeba wykonania odwrotnego przekształcenia dotyczy zwykle sytuacji, w której obiekt dostępny przez referencję traci stopniowo swoją funkcjonalność, jego zakres odpowiedzialności staje się coraz mniejszy, a proces tworzenia obiektu nie wymaga istotnych nakładów czasowych. Wówczas warto zmienić taki obiekt w obiekt-wartość.
Z punktu widzenia klienta obiekt Abstraction jest wykonawcą jego poleceń. Aby pełnić swoją rolę, obiekt ten musi posiadać referencję do obiektu Implementor, definiującego interfejs wewnętrzny i faktycznie realizującego wymaganą funkcjonalność. Co ważne, obiekty Abstraction i Implementor nie muszą w żaden sposób (przez dziedziczenie, implementację interfejsu etc.) być ze sobą spokrewnione.
 
Mechanika przekształcenia składa się z następujących kroków: Najpierw należy sprawdzić, czy obiekt ten po przekszałceniu faktycznie może być niezmienny. Jeżeli ten warunek nie jest spełniony, wówczas przekształcenie nie może być poprawnie zakończone. Jeżeli jednak tak jest, wtedy należy przygotować obiekt do porównywania jego stanu z innymi obiektami, tzn. zaimplementować jego metody ''equals'' ''(),'' służącą do bezpośrednich porównań, oraz ''hashCode'' ''(),'' często wykorzystywaną w tym celu metodę pomocniczą.
 
Po wykonaniu tych dwóch kroków obiekt w zasadzie może być traktowany jako obiekt-wartość. Opcjonalnie można zakończyć przekształcenie upubliczniając konstruktor, aby było możliwe bezpośrednie tworzenie instancji tej klasy, bez pośrednictwa metody-fabryki.




[[zpo-7-wyk-Slajd7 | << Poprzedni slajd]] | [[zpo-7-wyk-toc|Spis treści ]] | [[zpo-7-wyk-Slajd9 | Następny slajd >>]]
[[zpo-7-wyk-Slajd7 | << Poprzedni slajd]] | [[zpo-7-wyk-toc|Spis treści ]] | [[zpo-7-wyk-Slajd9 | Następny slajd >>]]

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

Bridge: uczestnicy

Bridge: uczestnicy


Z punktu widzenia klienta obiekt Abstraction jest wykonawcą jego poleceń. Aby pełnić swoją rolę, obiekt ten musi posiadać referencję do obiektu Implementor, definiującego interfejs wewnętrzny i faktycznie realizującego wymaganą funkcjonalność. Co ważne, obiekty Abstraction i Implementor nie muszą w żaden sposób (przez dziedziczenie, implementację interfejsu etc.) być ze sobą spokrewnione.


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