behavioral design patterns

Get Started. It's Free
or sign up with your email address
Rocket clouds
behavioral design patterns by Mind Map: behavioral design patterns

1. polecenie (command)

1.1. kapsułkuje żądanie w formie obiektu. Umożliwia to oparametryzację klienta przy użyciu różnych żądań oraz umieszczanie żądań w kolejkach i dziennikach, a także zapewnia obsługę cofania operacji

1.1.1. może zmieniać

1.1.1.1. warunki i sposób obsługi żądania

1.1.2. zalety

1.1.2.1. można łączyć polecenia w grupy polceń

1.1.2.2. oddzielenie operacji (Command) od obiektów (Model)

1.1.2.3. łączenie poleceń w łańcuch zapytań

1.1.3. wady

1.1.3.1. wymaga dodatkowe pamięci na zapamiętanie stanu obiektu

1.1.4. budowa

1.1.4.1. Command

1.1.4.1.1. interfejs definujący opracje jakie musi wykonać każde polecenie (np. wykonanie polecenia, wycofanie zmian )

1.1.4.2. ConcreteCommand

1.1.4.2.1. implementacja interfejsu polecenia

1.1.4.2.2. koncentruje się na obsłudze pojedyńczego zadania

1.1.4.2.3. do każdego rodzaju polecenia tworzymy oddzielną klasę

1.1.4.3. Invoker

1.1.4.3.1. dowolny obiekt który potrafi generować obiekty poleceń

1.1.4.4. Receiver

1.1.4.4.1. obiekt wykonujący polecenia za pomocą metody np. wykonaj()

1.1.4.4.2. może też robić doatkowe czynnności jaki zapisywanie do pliku etc

1.1.4.5. Model

1.1.4.5.1. obiekt na którym polecenia mogą wykonywać operacje

1.1.4.6. Client

1.1.4.6.1. obiekt który potrafi wykonać polecenie

1.1.4.6.2. w praktyce duża liczba klasa i obiektów

1.1.5. przekazuje polecenia w formie obiektów

1.2. implementacja

1.2.1. java

1.2.2. php

1.2.3. c++

2. interpreter

2.1. Określa reprezentację gramatyki danego języka oraz interpreter który wykorzystuje reprezentację do interpretowania zdań z danego języka

3. iterator

3.1. Zapewna sekwencyjny dostęp do elementów obiektu złożonego bez ujawniania jego wewnętrznej reprezentacji.

3.1.1. może zmieniać

3.1.1.1. sposób dostępu do elementów i przechodzenia po nich

3.2. implementacja

3.2.1. C++

4. mediator

4.1. Określa obiekt kapsułkujący informacje o interakcji między obiektami z danego zbioru. Wzorzec ten pomaga zapewnić luźne powiązanie, ponieważ zapobiega bezpośredniemu odwoływaniu się do obiektów do siebie i umożliwia niezależne modyfikowanie interakcji między nimi

4.1.1. uproszczenie komunikacji obiektów

4.1.2. hermetyzacja wymiany komunikatów

4.1.3. Obiekty nie muszą one nic o sobie wiedzieć, jedynie przekazują polecenia mediatorowi, a ten rozsyła je do odpowiednich obiektów

4.1.4. może zmieniać

4.1.4.1. jakie i które obiekty wchodzą ze sobą w interakcję

4.2. implementacja

4.2.1. C#

5. pamiątka (memento)

5.1. bez naruszania kapsułkowania rejestruje i zapisuje w zewnętrzne jednostce wewnętrzny stan obiektu, co umożliwia jego późniejsze przywrócenie według zapamiętanego stanu

5.1.1. może zmieniać

5.1.1.1. które prywatne informacje są przechowywane poza obiektem i kiedy

5.1.2. wzorzec nie zarządza stanem, ale zapewnia bezpośredni dostęp do niego

5.1.3. konsekwencje

5.1.3.1. hermetyzacja obiektu dla którego tworzymy pamiątkę

5.1.4. budowa

5.1.4.1. klasa Originator

5.1.4.1.1. setMemento()

5.1.4.1.2. createMemento()

5.1.4.2. klasa Memento

5.1.4.2.1. setState()

5.1.4.2.2. getState()

5.1.4.3. klasa Caretaker

5.1.4.3.1. do przechowywania pamiątek

5.2. implementacja

5.2.1. C++

6. obserwator (observer)

6.1. określa zależność "jeden do wielu" między obiektami. Kiedy zmieni się tan jednego z obiektów, wszystkie obiekty zależne od niego są o tym automatycznie powiadamiane i aktualizowane

6.1.1. konsekwencje

6.1.1.1. luźna relacja między obserwowanym i obserwującym

6.1.1.1.1. może się ona zmieniać w trakcie wykonania programu

6.1.1.2. domyślnie powiadamiane są wszystkie obiekty, można jednak zarządzać subskrybcją jakby

6.1.2. może zmieniać

6.1.2.1. liczbę obiektów zależnych od danego obiektu

6.1.2.2. sposób aktualizowania zależnych obiektów

6.1.3. budoes

6.1.3.1. Subject

6.1.3.1.1. obiekt obserwowane

6.1.3.2. Observer

6.1.3.2.1. obiekt obserwujący

6.1.4. model

6.1.4.1. push

6.1.4.1.1. obiekt przekazuje samego siebie w argumencie przez referencję i inne obserwatorzy wyciągają od niego informacje

6.1.4.2. pull

6.1.4.2.1. obiekt obserwowany przygotowywuje listę zmian i przekazuje ją w argumencie wywołania

6.2. implementacj

6.2.1. php

6.2.2. C++

7. stan (state)

7.1. Umożliwia obiektowi modyfikację zachowania w wyniku zmiany wewnętrznego stanu. Wygląda to tak, jakby obiekt zmienił klasę.

7.1.1. klasa Context używa metod z klasy State poprzez delegację

7.1.2. obiekty klasa State wewnątrze Context może mieć róźne stany, gdyż jest klasa state jest Polimorficzna

7.2. implementacja

7.2.1. C++

7.2.2. java

8. łańcuch zobowiązań (chain of responsibility)

8.1. pozwala nadawcy żądani uniknąć wiązania go z odbiorcą umożliwia obsłużenie żądania więcej niż jednemu obiektowi

9. strategia (straregy)

9.1. Określa rodzinę algorytmów, kapsułkuje każdy z nich i umożliwia ich zamienne stosowanie. Wzorzec ten pozwala zmieniać algorytmy niezależnie od korzystający z nich klientów

9.1.1. w łatwy sposób można zmieniać algorytm

9.1.1.1. w czasie działania programu

9.1.1.2. bez rekompilacji

9.1.2. elementy

9.1.2.1. interfejs Strategy

9.1.2.1.1. interfejs definiujący metody które muszą obsługiwać wszystkie dostępne algorytmy

9.1.2.2. klasa ConcreteStrategy

9.1.2.2.1. z którą skojarzony jest konkretny algorytm

9.1.2.3. Context

9.1.2.3.1. użytkownik rodziny algorytmów, mający referencję do Strategi

9.1.3. konsekwencje

9.1.3.1. zalety

9.1.3.1.1. pozwala na zdefiniowanie rodzin ściśle rozszerzalnych algorytmów za pomocą interfejsu strategia

9.1.3.1.2. bazuje na kompozycji, a nie dziedziczeniu

9.1.3.1.3. eliminuje instrukcje warunkowe

9.1.3.1.4. umożliwia wybór implementacji

9.1.3.1.5. umożliwia niezależne testowanie klientów i strategi

9.1.3.2. wady

9.1.3.2.1. zwiększona ilość obiektów

9.1.3.2.2. koszt komunikacji między klientem i strategią

9.2. implementacja

9.2.1. C++

9.2.2. php

10. metoda szablonowa (template method)

10.1. określa szkielet algorytmu i pozostawia doprecyzowanie niektórych jego kroków podklasom. Umożliwia modyfikację niektórych etapów algorytmu w podklasach bez zmiany jego stuktury

10.1.1. nie znam dokładnie zachowania obiektu, ale znam pewien schemat

10.1.2. szczegółowe zachowanie dostarczą inni programiści

10.1.3. konsekwencje

10.1.3.1. klasa bazowa wywołuje elementy klas pochodnych

10.1.3.2. klient definuje algorytm składający się z niezmiennej liczby kroków i zmienia tylko niektóre wywołania metod

10.1.3.3. stosowanie tego wzorca

10.1.3.3.1. zasada hollywood

10.1.3.3.2. nie dzwoń do nas, my zadzwonimy do Ciebie

10.1.4. może zmieniać

10.1.4.1. kroki alogrytmu

10.2. implementacja

10.2.1. C#

10.2.2. java

11. odwiedzający (visitor)

11.1. reprezentuje operację wykonywaną na elementach struktury obiektowej. Wzorzec ten umożliwia zdefiniowanie nowej operacji bez zmieniania klas elementów na których działa.

11.1.1. może zmieniać

11.1.1.1. operacje które można zastosować do obiektów bez zmiany ich klas

11.1.2. budowa

11.1.2.1. metoda accept()

11.1.2.2. metoda visit()

11.1.3. różne implemetacje Visitroa mogą mieć różne funkcjonalności, które mogą być wykonywane dla całych struktur

11.1.4. przykład

11.1.4.1. Mam jakąś strukturę danych i potrzebuję nawigować po tej strukturze, wykonując operacje na niej.

11.2. implementacja

11.2.1. C++

11.2.2. java

11.2.3. php

12. pusty obiekt (null object)

12.1. może zmieniać

12.1.1. obiekt zastępujący brak obiektu

12.2. konsekwencje

12.2.1. zalety

12.2.1.1. upraszcza kod programu

12.2.1.2. eliminuje zbędne i powtarzające się instrukcje warunkowe

12.2.1.3. hermetyzuję puste zachowanie poprzez metodę o pustym ciele

12.2.1.4. umożliwia wielokrotne wykorzystanie pustego zachowania

12.2.2. wady

12.2.2.1. niepotrzebny rozrost klasy

12.2.2.2. może powodować, że normalne wykonanie programu potraktowane jest jako błąd

12.2.2.3. trudno puste zachowanie upowszechnić wśród kilku współpracujących ze sobą obiektów

12.2.2.3.1. bo silna hermetyzacja

12.2.2.3.2. ?

12.3. budowa

12.3.1. Client

12.3.2. AbstractObject

12.3.2.1. klasa abstrakcyjna realizowana przez normalną klasę lub pustą

12.3.3. RealObject

12.3.3.1. rzeczywista realizacja klasy AbstractObject wykonująca konkretne działanie

12.3.4. NullObject

12.3.4.1. realizacja klasy AbstractObject w której nic nie jest wykonywane

12.4. implementacja

12.4.1. C++

12.5. zastosowanie

12.5.1. jako pusty Singleton

12.5.2. nic nie wykonujący przypdadek ConcreteStrategy w Strategi

12.5.2.1. NullObject

12.5.3. w wzorcu Stan, jeśli ConcreteState wykonuje przynajmniej puste metody

12.5.3.1. NullState

12.5.4. w Visitor. aby bezpiecznie odwiedzić obiekty w hierarchii