Wzorce projektowe Szkolenie InMoST 21 lutego 2006 Bartosz Walter.

Prezentacja na temat: "Wzorce projektowe Szkolenie InMoST 21 lutego 2006 Bartosz Walter."— Zapis prezentacji:

1 Wzorce projektowe Szkolenie InMoST 21 lutego 2006 Bartosz Walter

2 Motywacja "Wzorzec opisuje problem, który pojawia się wielokrotnie w danym środowisku, i opisuje podstawę rozwiązania tego problemu, w taki sposób, że można użyć tego rozwiązania milion razy, bez konieczności ponownego wykonywania tych samych czynności" Christopher Alexander "A Pattern Language", 1977

3 Wzorce w budownictwie lądowym inspired by example by Ralph Johnson Czy zbudujemy most, opierając przęsło na kolejnych filarach połączonych łukiem, tak aby łuk usztywniał i naciągał przęsło stanowiąc jego podparcie na całej długości przęsła, czy też mocując płyty z obu stron za pomocą kilku lin stalowych o kolejno coraz krótszych długościach do pylonów umieszczonych pośrodku długości mostu?

4 Wzorce w budownictwie lądowym Czy zbudujemy most łukowy czy podwieszany?

5 Atrybuty wzorca kiedy? jak?zyski/straty?alternatywy?kontekst? warunki wstępne? Wzorzec

6 Wzorce w inżynierii oprogramowania "Wzorzec projektowy identyfikuje i specyfikuje pewną abstrakcję, której poziom znajduje się powyżej poziomu abstrakcji pojedynczej klasy, instancji lub komponentu" E. Gamma et al., 1993

7 Wzorce projektowe Katalog wzorców projektowych

8 Systematyka wzorców Kreacyjne  Abstract Factory  Builder  Factory Method  Prototype  Singleton Strukturalne  Adapter  Bridge  Composite  Decorator  Facade  Proxy  Flyweight Behawioralne  Chain of responsibility  Command  Interpreter  Iterator  Mediator  Memento  Observer  State  Strategy  Template method  Visitor

9 Observer: Cel Zdefiniowanie pomiędzy obiektami zależności jeden-do-wielu, dzięki której jeżeli jeden (nadrzędny) obiekt zmieni stan, pozostałe także zostaną o tym powiadomione i zaktualizowane

10 Observer: Struktura

11 Observer: Uczestnicy  Subject  zna swoje obserwatory  posiada interfejs pozwalający dołączać i odłączać obserwatory  Observer  definiuje ogólny interfejs dla obserwatorów  Concrete Subject  przechowuje stan, który obserwują obserwatory  wysyła powiadomienia do obserwatorów  Concrete Observer  dołącza i odłącza siebie do/od obiektu obserwowanego  aktualizuje swój stan przy zmianach w obiekcie obserwowanym

12 Observer: Konsekwencje  ułatwione utrzymanie spójności systemu  abstrakcyjne powiązanie pomiędzy obiektami Subject i Observer  Subject posiada znikomą wiedzę o swoich obserwatorach  Subject i obserwatory mogą należeć do różnych warstw aplikacji  programowy broadcasting  skalowalność aktualizacji obserwatorów  push: obserwatory otrzymują pełną informację o zmianie (czy jej potrzebują, czy nie)  pull: obserwatory otrzymują tylko powiadomienie i muszą zapytać Subject o szczegóły  "wiszące" referencje po stronie obiektu obserwowanego (rozwiązanie w Javie: "słabe" referencje)

13 Observer: Przykład Rachunek klienta może być powiązany z innymi rachunkami pobocznymi. Na przykład, z głównym rachunkiem jest związany rachunek kredytu odnawialnego. Wysokość otwartej linii kredytowej zależy od środków na rachunku głównym. Zmiana wysokości salda na tym rachunku skutkuje podwyższeniem lub obniżeniem dostępnej kwoty kredytu.

14 Factory Method: Cel  Zdefiniowanie interfejsu do tworzenia obiektu  Odsunięcie tworzenia obiektów określonej klasy do podklas  Podklasy decydują której klasy i którego konstruktora użyć do utworzenia obiektu produktu.

15 Factory Method: Zastosowanie  Klient nie może przewidzieć, jakiej klasy obiekt należy utworzyć  Klasa chce, aby jej podklasy określały jaki obiekt utworzyć; w tym celu przekazuje im część swojej odpowiedzialności

16 Factory Method: Struktura by the Gang of Four

17 Factory Method: Uczestnicy  Product  deklaruje interfejs dla obiektów utworzonych przez Factory Method  ConcreteProduct  implementuje interfejs Product  Creator  deklaruje interfejs dla metody fabryki obiektów typu Product  może posiadać domyślną implementację metody fabryki  ConcreteCreator  pokrywa metodę fabrykę, tak aby zwracała obiekt Concrete Product

18 Factory Method: Konsekwencje  przesunięcie akcentu na podklasy  podklasy w ich metodach fabrykach mogą tworzyć zmienioną lub rozszerzoną wersję produktu  parametryzowane FM vs. polimorficzne FM  Creator może wybrać obiekt, który chce utworzyć, lub przekazać tę odpowiedzialność do podklas  dwa poziomy wyboru: podklasy, która utworzy specyficzny produkt, oraz konstruktora wewnątrz podklasy

19 Factory Method: Przykład W zależności od wybranego sposobu drukowania wyciągów, są one tworzone codziennie, cotygodniowo lub comiesięcznie. Każdy z nich jest reprezentowany przez oddzielny obiekt.

20 Chain of Responsibility: Cel  Uniknięcie wiązania nadawcy żądania z jego odbiorcom poprzez utworzenie grupy potencjalnych odbiorców, którzy mogą obsłużyć żądanie  Odbiorcy są ułożeni w łańcuch i przekazują sobie żądanie wzdłuż łańcucha aż jeden z nich obsłuży je.

21 Chain of Responsibility: Structure by the Gang of Four

22 Chain of Responsibility: Participants  Handler  defines an interface for handling requests  (optional) implements the successor link  Concrete Handler  handles requests it is responsible for  can access its successor  if the ConcreteHandler can handle the request, it does so; otherwise it forwards the request to its successor  Client  initiates the request to a ConcreteHandler object on the chain by the Gang of Four

23 Chain of Responsibility: Consequences Chain of Responsibility allows for:  reduced coupling  Object does not need to know which other object handles the request  both Sender and Receiver have no knowledge of each other  chain elements do not know the chain's structure  added flexibility in assigning responsibilities to objects  responsibilities can be freely distributed among chain elements  no guarantee of receipt by the Gang of Four

24 Chain of Responsibility: Przykład 1

25

26 Chain of Responsibility: Przykład 2

27

28 State: Cel Umożliwienie obiektowi zmiany jego zachowania w odpowiedzi na zmianę jego wewnętrznego stanu. Obiekt będzie pozornie zmieniał swoją klasę.

29 State: Zastosowanie  Zachowanie obiektu zależy od jego stanu i podlega zmianom w trakcie wykonywania programu  Wewnątrz metody istnieją złożone, wieloczęściowe wyrażenia warunkowe, które zależą od stanu obiektu  Każdy stan jest oddzielnym obiektem, który może zmieniać się niezależnie od innych obiektów

30 State: Struktura

31 State: Uczestnicy  Context  defines the interface of interest to clients  maintains an instance of a ConcreteState subclass that defines the current state  State  defines an interface for encapsulating the behavior associated with a particular state of the Context  Concrete State subclasses  each subclass implements a behavior associated with a state of the Context

32 State: Konsewencje  partition of the behavior for different states  state-specific code lives in State subclasses  intent of the state-dependent behavior is clearer  explicit state transitions  protection from inconsistent internal states  possible sharing of state objects  States are stateless

33 State: Przykład Rachunek może znajdować się w stanie otwartym lub zamkniętym. W stanie otwartym właściciel może dokonywać wpłat na rachunek, podczas gdy w stanie zamkniętym stan rachunku nie może ulec zmianie.

34 State: Przykład public class Account { private int balance = 0; private String owner = null; private boolean isOpen = false; public Account(String owner, int balance) { this.owner = owner; this.balance = balance; this.isOpen = true; } public void credit(int amount) { if (isOpen) { balance += amount; } else { alert("The account is closed!"); }

35 State: Przykład public interface AccountState { public void credit(Account acc, int amount); } public class AccountOpen implements AccountState { public void credit(Account acc, int amount) { acc.balance += amount; } public class AccountClosed implements AccountState { public void credit(Account acc, int amount) { alert("The account is closed!"); }

36 State: Przykład public class Account { private int balance = 0; private String owner = null; private AccountState state = null; public Account(String owner, int balance) { this.owner = owner; this.balance = balance; this.state = new AccountOpen(); } public void credit(int amount) { this.state.credit(this, amount); } public void close() { this.state = new AccountClosed(); }

37 Decorator: Cel  Umożliwienie dynamicznego dołączania odpowiedzialności do obiektu  Dostarczenie elastycznej alternatywy dla dziedziczenia w celu rozszerzania funkcjonalności

38 Decorator: Problem public class Invoice { String buyer = null; String issuer = null; List elements = new ArrayList (); Header header = null; private boolean useHeader() { return header != null; } public void print() { if (useHeader()) { header.print(); } print("Issuer: " + issuer); print("Buyer: " + buyer); for (e : elements) { e.print(); }

39 Decorator: Problem public class Invoice { String buyer = null; String issuer = null; List elements = new ArrayList (); public void print() { print("Issuer: " + issuer); print("Buyer: " + buyer); for (e : elements) { e.print(); } public class HeaderInvoice extends Invoice { Header header = null; private boolean useHeader() { return header != null; } public void print() { if (useHeader()) { header.print(); } super.print(); }

40 Decorator: Problem

41 Decorator: Struktura

42 Decorator: Uczestnicy  Component  deklaruje interfejs dla obiektów, którym można zwiększyć zakres odpowiedzialności  Concrete Component  implementuje interfejs Component  Decorator  posiada interfejs zgodny z interfejsem Component  jest świadom istnienia dekorowanego Component u (który jest instancją Concrete Component lub innym Decorator em)  Concrete Decorator  dodaje odpowiedzialność do komponentu

43 Decorator: Konsekwencje  większa elastyczność niż w przypadku dziedziczenia  odpowiedzielność może być zwiększana dynamicznie  mniej złożona hierarchia klas  pay-as-you-go  poszczególne cechy są dodawane na żądanie  różnica w tożsamości obiektów  tożsamość obiektu jest inna od tożsamości dekoratora  tożsamość obiektu powinna być hermetyzowana i ukryta przed klientem  duża liczna małych, dobrze zdefiniowanych klas dekoratorów  poprawiona testowalność

44 Decorator: Przykład

45 Flyweight: Cel  Ponowne użycie i współdzielenie obiektów w celu zwiększenia efektywności ich wykorzystania  Oddzielenie wewnętrznego (współdzielnonego) i zewnętrznego (unikatowego) stanu obiektu

46 Flyweight: Struktura

47 Flyweight: Uczestnicy  Flyweight  deklaruje interfejs, przez który obiekty mogą otrzymywać swój stan zewnętrzny  Concrete Flyweight  musi być niezależny od swojego kontekstu (stanu zewnętrznego)  Unshared Concrete Flyweight  specjalny przypadek obiektu niewspółdzielnonego  Flyweight Factory  tworzy i zarządza obiektami Flyweight  zapewnia poprawność procesu zarządzania obiektami  Client  otrzymuje instancje Flyweight poprzez FlyweightFactory

48 Flyweight: Konsekwencje  rosnące oszczędności pamięci  ograniczenie całkowitej liczby instancji  ograniczenie współdzielonego stanu wewnętrznego  stan zewnętrzny może być wyliczony lub zapamiętany  wzrost kosztu obliczeniowego  zarządzanie stanem zewnętrznym

49 Flyweight: Przykład public abstract class TeaOrder { // Flyweight public abstract void serveTea(TeaOrderContext teaOrderContext); } public class TeaFlavor extends TeaOrder { // ConcreteFlyweight String teaFlavor;// stan wewnętrzny TeaFlavor(String teaFlavor) { this.teaFlavor = teaFlavor; } public String getFlavor() { return this.teaFlavor; } // teaOrderContext jest zewnętrznym stanem public void serveTea(TeaOrderContext teaOrderContext) { System.out.println("Serving tea flavor " + teaFlavor + " to table number " + teaOrderContext.getTable()); }

50 Flyweight: Przykład public class TeaOrderCtx { // kontekst dostarcza stan zewnętrzny int tableNumber; TeaOrderContext(int tableNumber) { this.tableNumber = tableNumber; } public int getTable() { return this.tableNumber; }

51 Flyweight: Przykład public class TeaFlavorFactory { // Flyweight Factory TeaFlavor[] flavors = new TeaFlavor[10];// <10 flavors can be made int teasMade = 0; // Factory Method public TeaFlavor getTeaFlavor(String flavorToGet) { for (int i = 0; i < teasMade; i++) { if (flavorToGet.equals((flavors[i]).getFlavor())) { return flavors[i]; } flavors[teasMade] = new TeaFlavor(flavorToGet); return flavors[teasMade++]; } public int getTotalTeaFlavorsMade() { return teasMade; } by Lawrence Trurett

52 Flyweight: Przykład class TestFlyweight { static TeaFlavor[] flavors = new TeaFlavor[100]; // zamówienia static TeaOrderCtx[] tables = new TeaOrderCtx[100]; // stoły static int ordersMade = 0; static TeaFlavorFactory teaFlavorFactory; static void takeOrders(String flavorIn, int table) { flavors[ordersMade] = teaFlavorFactory.getTeaFlavor(flavorIn); tables[ordersMade++] = new TeaOrderCtx(table); } public static void main(String[] args) { teaFlavorFactory = new TeaFlavorFactory(); takeOrders("chai", 2); takeOrders("camomile", 1); takeOrders("earl grey", 1); takeOrders("camomile", 897); for (int i = 0; i < ordersMade; i++) { flavors[i].serveTea(tables[i]); } System.out.println(" "); System.out.println("total teaFlavor objects made: " + teaFlavorFactory.getTotalTeaFlavorsMade()); }

53 Command: Cel  Hermetyzacja żądania jako obiektu  Umożliwienie parametryzacji klientów różnymi żądaniami  Wsparcie dla żądań odwracalnych

54 Command: Struktura

55 Command: Uczestnicy  Command  deklaruje interfejs dla wykonywania zadania ( execute() )  ConcreteCommand  definiuje powiązanie pomiędzy Receiver em i akcją  implementuje metodę execute()  Client  tworzy obiekt ConcreteCommand i wskazuje jego odbiorcę ( Receiver )  Invoker  wywołuje obiekt Command w celu wykonania żądania  Receiver  zna wykonawcę konkretnych żądań

56 Command: Konsekwencje  usunięcie powiązania nadawcy i odbiorcy ( Receiver )  obiekty Command mogą być składane w polecenia złożone  dodawanie nowych obiektów Command jest łatwe  Command można łatwo rozszerzyć o odwracanie ich działania

57 Command: Przykład

58 public class Bank { // Invoker, Client public void income(Account acc, long amount) { Operation oper = new Income(amount); acc.doOperation(oper); } public void transfer(Account from, Account to, long amount) { Operation oper = new Transfer(to, amount); from.doOperation(oper); } public class Account { // Reciever long balance = 0; Interest interest = new InterestA(); History history = new History(); public void doOperation(Operation oper) { oper.execute(this); history.log(oper); }

59 Command: Przykład abstract public class Operation { // Command public void execute(); } public class Income { // ConcreteCommand1 public Income(long amount) { // store parameters... } public void execute(Account acc) { acc.add(amount); } public class Transfer { // ConcreteCommand2 public Income(Account to, long amount) { // store parameters... } public void execute(Account from) { from.subtract(amount); to.add(amount); }

60 Visitor: Cel  Reprezentacja operacji, która ma być wykonana na elementach heterogenicznej struktury.  Umożliwienie zdefiniowania nowej operacji bez zmiany samych elementów, na których ona operuje

61 Visitor: Struktura

62 Visitor: Uczestnicy  Visitor  deklaruje sposób realizacji operacji dla każdego ConcreteElement, który ma być odwiedzony  Concrete Visitor  implementuje konkretną operację  Element  definiuje metodę accept(), która otrzymuje obiekt Visitor jako parametr  Object Structure  zwraca pojedyncze elementy struktury  może posiadać interfejs wysokiego poziomu który pozwala obiektom Visitor odwiedzać elementy

63 Visitor: Konsekwencje  łatwe dodawanie nowych operacji ( Visitor ów)  trudne dodawanie nowych elementów ( ConcreteElement s)  każdy ConcreteElement wymaga stworzenie nowej metody we wszystkich istniejących Visitor ach  obsługa obiektów niezależna od ich klas  inaczej niż Iterator, Visitor może odwiedzać obiektów różnych klas

64 Visitor: Konsekwencje (cd.)  akumulacja stanu  Visitor y mogą akumulować stan odwiedzanych elementów w sposób dla nich specyficzny  konieczność naruszenia hermetyzacji  z uwagi na odwrócenie sterowania pomiędzy elementem a Visitor em, konieczne jest udostępnienie im nazwajem metod accept() i visit*()

65 Visitor: Przykład public class Bank { List products = new ArrayList (); public List doReport(Report report) { List result = new ArrayList (); for (BankingProduct product : products) { result.add(product.accept(report)); } return result; }

66 Visitor: Przykład public abstract class BankingProduct { } public interface Element { public BankingProduct accept(Report report); } public class Account extends BankingProduct implements Element { public BankingProduct accept(Report report) { if (isPriviliged(report)) { return report.visit(this); } return null; } public class Credit extends BankingProduct implements Element { public BankingProduct accept(Report report) { if (isPriviliged(report)) { return report.visit(this); } return null; }

67 Visitor: Przykład public class Over1000Report implements Visitor { public BankingProduct visit(Account acc) { if (acc.balance > 1000) return this; return null; } public BankingProduct visit(Credit credit) { if (credit.draft > 1000 && credit.isActive()) return this; return null } public class PassAllReport implements Visitor { public BankingProduct visit(Account acc) { return this; } public BankingProduct visit(Credit credit) { return this; }

68 Q & A