Blog techniczny i nie tylko

Dzisiejszym tematem będzie…

ABSTRACT FACTORY, czyli Metoda fabrykująca

Cel:
Określenie interfejsu dla tworzenia obiektu z pozostawieniem podklasom decyzji o wyborze klasy tworzonego obiektu

Stosowalność:
Używamy go, gdy:
- Klasa nie jest w stanie przewidzieć klas obiektów, które musi tworzyć.
- Klasa chce, aby jej podklasy określały obiekty, które tworzy.
- Klasy delegują odpowiedzialność do jednej z kilku pomocniczych podklas i chcemy zlokalizować wiedzę o tym, która z tych podklas jest aktualnym delegatem.

Konsekwencje używania:
- Metody fabrykujące eliminują potrzebę umieszczania w kodzie klas specyficznych dla aplikacji.
- Potencjalna wada FM – klienci mogą być zmuszeni do specjalizowania klasy Twórcy tylko po to, żeby stworzyć szczególny Konkretny Produkt.
- Dostarczenie „wskazówek” podklasom
- Połączenie równoległych hierarchii klas

Diagram:

Na łamach bloga przytoczę teraz pewną powtórzeniową dawkę wiedzy dla wszystkich absolwentów kursu wzorców projektowych na swoich studiach informatycznych (i nie tylko;). Ponieważ szczegółowych opisów wzorców (i antywzorców) projektowych w sieci jest dużo skupię się tutaj tylko i wyłącznie na kilku najistotniejszych sprawach – mianowicie na opisie celu wprowadzenia wzorca, opisie przypadków, w którym go używamy, konsekwencji jego zastosowania oraz przybliżającego sprawę diagramu UML. Dzisiejszy odcinek sponsoruje…

CHAIN OF RESPONSIBILITY, czyli łańcuch odpowiedzialności

Cel:

Uniknięcie sprzężenia nadawcy żądania z odbiorcą przez umożliwienie większej liczbie obiektów realizacji tego żądania. Obiekty odbiorcze są łączone w łańcuch, wzdłuż którego przekazywane jest żądanie do czasu, gdy któreś z ogniw je zrealizuje.

Stosowalność:

Używamy go, gdy:
- Więcej niż jeden obiekt może zrealizować żądanie, a odbiorca nie jest znany a priori (zatem powinien być ustalony automatycznie).
- Chcemy wysłać żądanie do jednego z pewnej liczby obiektów nie specyfikując jawnie odbiorcy.
- Zbiór obiektów mogących zrealizować żądanie ma być ustalony dynamicznie.

 Konsekwencje stosowania:

- Zredukowane sprzężenie
- Dodatkowa elastyczność w rozdzieleniu odpowiedzialności pomiędzy obiekty
- Brak gwarancji obsłużenia żądania

Diagram:

Na łamach bloga przytoczę teraz pewną powtórzeniową dawkę wiedzy dla wszystkich absolwentów kursu wzorców projektowych na swoich studiach informatycznych (i nie tylko;). Ponieważ szczegółowych opisów wzorców (i antywzorców) projektowych w sieci jest dużo skupię się tutaj tylko i wyłącznie na kilku najistotniejszych sprawach – mianowicie na celu wprowadzenia wzorca, opisie przypadków, w którym go używamy, konsekwencji jego zastosowania oraz przybliżającego sprawę diagramu UML. Dzisiejszy odcinek sponsoruje…

FLYWEIGHT, czyli waga musza

Cel:
Użycie współdzielenia do efektywnego wsparcia dużej liczby drobnoziarnistych obiektów.

Stosowalność:
Używamy go, gdy wszystkie poniższe warunki są spełnione:
-Aplikacja używa dużej liczby obiektów
- Koszty składowania są wysokie z powodu znacznej liczebności obiektów.
- Większość stanu obiektu może być przeniesiona na zewnątrz.
-Wiele grup obiektów może być zastąpionych przez stosunkowo niewiele współdzielonych obiektów po usunięciu zewnętrznego stanu.
-Aplikacja nie zależy od tożsamości obiektów.

Konsekwencje użycia:
Oszczędność pamięci – tym większa im:
–większa redukcja liczby instancji wynikająca z ich współdzielenia;
–mniej stanu wewnętrznego;
–więcej stanu zewnętrznego można wyliczyć (a nie przechowywać).

Przykłady użycia: wydzielenie chemikaliów o stałych danych, wydzielenie obiektów reprezentujących znaki drukarskie

Diagram: