Zpo-7-wyk-Slajd12: 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:
==Change Unidirectional Association with Bi==
==Flyweight: uczestnicy==


[[Image:zpo-7-wyk-Slajd12.PNG|Change Unidirectional Association with Bi]]
[[Image:zpo-7-wyk-Slajd12.PNG|Flyweight: uczestnicy]]




Przekształcenie to dotyczy zmiany nawigowalności relacji asocjacji z jednokierunkowej na dwukierunkową. W asocjacji takiej wyróżnia się dwie strony: kontrolującą, do której dostęp ma klient i która zarządza relacją, oraz kontrolowaną, odgrywającą bardziej pasywną rolę. Na rysunku rolę kontrolującą (oznaczoną niebieską obwódką) odgrywa obiekt A, natomiast rolę kontrolowaną – obiekt B.
Obiekt Flyweight musi posiadać interfejs do obsługi stanu zewnętrznego. Zwykle są to metody dostępowe typu get/set, które konfigurują obiekt.


Przekształcenie polega na stworzeniu po stronie kontrolowanej referencji do obiektu kontrolującego oraz wprowadzeniu mechanizmu synchronizującego referencje po obu stronach relacji.
Flyweight Factory stanowi (z punktu widzenia klienta) fabrykę do tworzenia obiektów. Obiekt ten posiada pamięć (pulę obiektów), w której przechowuje wcześniej utworzone instancje. Zajmuje się także zapisem i odtwarzaniem (serializacją i deserializacją) stanu zewnętrznego obiektu.
 
Pierwszym krokiem jest wprowadzenie pola, które będzie przechowywać referencje powrotne typu A. W przypadku relacji o krotności 1 wystarczy zwykła referencja typu A, natomiast w przypadku krotności n typem tym może być Set<A>, czyli zbiór referencji typu A.
 
Następnie należy utworzyć po stronie kontrolowanej metodę, która będzie wywoływana przez stronę kontrolującą w celu aktualizacji referencji. Ponieważ metoda ta powinna być niedostępna dla klienta, w języku C++ należy ją uczynić prywatną, a następnie zaprzyjaźnić z klasą A. Ponieważ jednak w języku Java pojęcie klas zaprzyjaźnionych nie istnieje, dlatego konieczne jest oznaczenie metody w sposób jednoznacznie wskazujący na jej przeznaczenie tylko do użytku klasy A.
 
Ostatnim krokiem jest modyfikacja metody w klasie A, która odpowiada za dodawanie obiektów typu B, tak aby za pomocą metody w klasie B aktualizowała  także referencje powrotne.




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

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

Flyweight: uczestnicy

Flyweight: uczestnicy


Obiekt Flyweight musi posiadać interfejs do obsługi stanu zewnętrznego. Zwykle są to metody dostępowe typu get/set, które konfigurują obiekt.

Flyweight Factory stanowi (z punktu widzenia klienta) fabrykę do tworzenia obiektów. Obiekt ten posiada pamięć (pulę obiektów), w której przechowuje wcześniej utworzone instancje. Zajmuje się także zapisem i odtwarzaniem (serializacją i deserializacją) stanu zewnętrznego obiektu.


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

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