Wzorce Konstrukcyjne Część II Tomasz Borzyszkowski Budowniczy

Transkrypt

Wzorce Konstrukcyjne Część II Tomasz Borzyszkowski Budowniczy
Budowniczy: kiedy stosować?
Wzorce
Konstrukcyjne
Część II
Wzorzec Budowniczy należy stosować w następujących
sytuacjach:
●
●
●
Tomasz Borzyszkowski
Budowniczy: diagram
jeżeli algorytm tworzenia obiektu złożonego powinien być
niezależny od składników tego obiektu
proces konstrukcji musi umożliwiać tworzenie różnych
reprezentacji generowanego obiektu
celem jest rozdzielenie sposobu tworzenia obiektów od ich
reprezentacji
Budowniczy: struktura
Budowniczy składa się z dwóch podstawowych obiektów:
●
●
●
●
Budowniczy: dostarcza interfejs do tworzenia produktów
(często jest to klasa z pustymi metodami).
BudowniczyKonkretny: tworzy konkretne produkty
korzystając z interfejsu obiektu Budowniczy.
Kierownik: konstruuje obiekt, używając interfejsu
Budowniczego.
Produkt: reprezentuje konstruowany obiekt;
BudowniczyKonkretny buduje wewnętrzną reprezentację
produktu i definiuje proces jego składania; zawiera klasy
definiujące części składowe.
Budowniczy: komentarz
Budowniczy: diagram sekwencji
Budowniczy w odróżnieniu od fabryki abstrakcyjnej
skupia się na sposobie tworzenia obiektów.
Za każdym swoim wywołaniem tworzy drobną część produktu
kontrolując stan wykonanej pracy.
Klient dostaje produkt po zakończeniu pracy Budowniczego a nie
- tak jak w przypadku Fabryki abstrakcyjnej - od razu.
Budowniczy: diagram sekwencji: opis
●
●
●
●
Klient tworzy obiekt Kierownik i konfiguruje go za pomocą
pożądanego obiektu Budowniczy.
Kierownik informuje budowniczego o potrzebie zbudowania części
Produktu.
Budowniczy: przykłady
●
●
Builder (VehicleBuilder): specyfikacja interfejsu tworzenia
obiektów typu Product (Vehicle)
ConcreteBuilder (MotorCycleBuilder, CarBuilder, ScooterBuilder):
●
Budowniczy przetwarza żądania Kierownika i dodaje części do
Produktu.
Klient odbiera Produkt od Budowniczego.
●
●
wytwarza i składa części Produktu przez implementację
interfejsu Builder
●
nadzoruje proces wytwarzania Produktu
●
dostarcza mechanizm pobierania Produktu
Director (Shop): zamawia produkty korzystając z interfesu
Builder
Product (Vehicle): opisuje konstruowany produkt
Prototyp: kiedy stosować?
●
●
●
●
system powinien być niezależny od tego, jak jego produkty
są tworzone, składane i reprezentowane
klasy, których egzemplarze należy tworzyć są specyfikowane
w czasie wykonywania programu, np. przez dynamiczne
ładowanie
istnieje potrzeba uniknięcia budowania hierarchii klas
fabryk, która jest porównywalna z hierarchią klas produktów
stan obiektów klasy może przyjmować tylko jedną z kilku
wartości; wówczas wygodniej zainstalować odpowiednią
liczbę prototypów i klonować je niż ręcznie tworzyć
egzemplarze klasy za każdym razem
Prototyp: struktura
●
●
●
Prototyp: diagram
Prototyp: deklaruje interfejs klonowania się (często jest to
kopia głęboka).
PrototypKonkretny: implementuje operację klonowania się.
Klient: tworzy nowy obiekt, prosząc prototyp o sklonowanie
się.
Współpraca: Klient prosi prototyp o sklonowanie się.
Konsekwencje:
●
odawanie i usuwanie obiektów w czasie przebiegu programu
●
przyspiesza kreowanie dużych obiektów.
Prototyp: przykłady
●
Prototype (ColorPrototype):
●
●
ConcretePrototype (Color):
●
●
deklaruje interfejs klonowania samego siebie
implementuje interfejs klonowania samego siebie
Client (ColorManager):
●
tworzy nowe obiekty prosząc prototyp o sklonowanie się
Object Pool: kiedy stosować?
●
●
●
●
istnieje kilku klientów korzystających okresowo z tego
samego zasobu bezstanowego
tworzenie i niszczenie zasobu jest kosztowne
zasoby same mają martwić się ewentualnym współbieżnym
wykorzystaniem
mamy ograniczone zaufanie do klienta (autoryzacja, proces
zwalniania zasobów, ... )
Object Pool: struktura
●
●
●
Object Pool: diagram
Client: używa obiektów typu Reusable.
Object Pool: problemy
●
Reusable: opakowuje ograniczone zasoby, które maja być
współdzielone przez wielu klientów w ograniczonym czasie.
ReusablePool: zarządza współdzielonymi obiektami.
●
●
Działanie:
●
●
Client prosi o Reusable obiekt
●
●
znajdź w ReusablePool wolny obiekt i oddaj klientowi, jeżeli
taki istnieje
●
jeżeli nie istnieje, stwórz i oddaj klientowi
●
jeżeli nie można utworzyć obiektu, czekaj aż się zwolni.
Ograniczona liczba zasobów w puli
Zaimplementować pulę z ograniczoną liczbą zasobów i
oczekiwaniem na wolny zasób
Obsługa sytuacji, w której próba tworzenia nowego zasoby
kończy się niepowidzeniem (np.: wyjątek, ... )
Synchronizacja wielu współbieżnych klientów.
Problem z nieużywanymi i niezwolnionymi zasobami (np.:
zwalniać po jakimś czasie bezczynności)

Podobne dokumenty