SW_04 Návrhové vzory (Design Patterns) 1
Definice vzoru Každý vzor popisuje problém, který nastává opakovaně v našem prostředí, a potom popisuje podstatu řešení tohoto problému takovým způsobem, že můžete použít řešení milionkrát bez toho, že byste dělali stejnou věc dvakrát. Christopher Alexander 2
Světlo z obou stran každého pokoje Když mají lidé na výběr, vždy tíhnou k takovým pokojům, do kterých přichází přirozené světlo alespoň ze dvou stran. Při projektování domu, je nejlepší umístit každý pokoj tak, aby měl vnější prostor alespoň ze dvou stran, s dostatkem oken, které by zachycovaly přirozené světlo více než z jednoho směru. 3
Literatura Gamma E., Helm R.: Degign Patterns. Addison -Wesley 1995 (český překlad Návrh programů pomocí vzorů. Grada 2003) 4
Základní literatura Pecinovský R.: Návrhové vzory. Computer Press 2007 Bruce Eckel: Thinking in Patterns. www.bruceeckel.com Buchmann F.: Pattern-Oriented Software Architecture A System of Patterns. Willey 1998 Metsker S.J. Wake W.C.: Design Patterns in Java. Addison-Wesley. 2006 5
Existující knihy k Business Patterns 6
Úvod Vzory pro návrh, návrhové vzory (Design Patterns) souvislost s objektově orientovanou analýzou a návrhem. Klíčový poje znovupoužitelnost (reusability) Znovupoužitelnost v oblasti objektově orientovaných jazyků části software, které se použijí buď přímo, nebo po malém přizpůsobení využívá se dědičnosti. 7
Úvod Znovupoužitelnost je v oblasti objektově orientovaných jazyků použita na úrovni implementace zdrojového kódu. Vzory pro návrh vycházejí z práce zkušeného návrháře, ten nezačíná svoji práci od nuly, ale pokud se mu nějaký způsob řešení osvědčil snaha používat ho znovu a vylepšovat ho. Znovupoužitelnost v oblasti návrhových vzorů znamená znovupoužití znalostí získaných v průběhu návrhu. 8
Úvod Znovupoužitelnost je možné chápat v několika úrovních: dědičnost a business objekty (aplikační objekty) znovupoužitelnost na implementační úrovni návrhové vzory znovupoužitelnost v oblasti návrhu nabytých znalostí 9
Co je vzor Vzor určuje opakující se (opětovný) návrh problému, který vzniká ve specifických situacích a presentuje nějaké jejich řešení. Vzory reprezentují existující, dobře prověřené zkušenosti návrhu. Vzory identifikují a specifikují abstrakce, které jsou nad úrovní jednotlivých tříd a instancí nebo komponent. Vzory poskytují společný slovník a pochopení principů návrhu. 10
Co je vzor Vzory jsou prostředky pro dokumentaci softwarové architektury. Vzory pomáhají obsáhnout složitost software a umožňují srozumitelnost a pochopitelnost software. 11
Co je návrhový vzor Návrhový vzor je libovolná znalost, která vznikla při návrhu programového systému abstrakcí od specifických konkrétních podmínek. Nutno doplnit konkrétní fyzickou podobu takovéto znalosti. Forma zápisu vzoru pro návrh není pevně daná, je závislá na tom, čeho se zkušenost kterou chceme vyjádřit návrhovým vzorem týká. 12
Forma zápisu Model použitý při návrhu potřebuje slovní komentář, který přesněji specifikuje použité prvky a vazby v modelu a umožní pochopení problému. Nejdůležitějšími charakteristikami tohoto popisu kromě jiných bývají: kontext situace, která způsobuje vznik problému problém opakující se problém vznikající v daném kontextu řešení prověřené řešení problému (někdy alespoň částečné) 13
Kontext, problém a řešení kontext: vytvoření programového vybavení s uživatelským grafickým rozhraním problém: obyčejně je problém reprezentovaný množinou někdy protichůdně působících sil např.: uživatelské rozhraní by mělo být snadno modifikovatelné funkční jádro programového vybavení by nemělo být postiženo změnou uživatelského rozhraní 14
Kontext, problém a řešení všeobecně síly pomáhají objasnit problém řešení z různých úhlů pohledu a pomáhají tak mu porozumět ve všech detailech síly mohou působit doplňkově nebo protichůdně řešení: ukazuje, jak řešit opakující se problém nebo lépe, jak vyrovnat síly, s ním sdružené. 15
Řešení v softwarové architektuře řešení zahrnuje dva aspekty: 1. Každý vzor specifikuje jistou strukturu a prostorovou konfiguraci prvků. Řešení naznačeného problému je v rozdělené aplikace na vlastní zpracování, vstupy, výstupy (MVC). To představuje statickou strukturu řešeného problému. 2. Každý vzor specifikuje chování za běhu (run-time). Např. MVC controller dostane vstup od myši, klávesnice. Událost je transformována na požadavky služeb. 16
Řešení Tyto požadavky služeb jsou zaslány buď modelu nebo pohledům. Chování za běhu reprezentuje dynamickou stránku řešení problému. Jak účastníci spolupracují, jak je organizována práce mezi nimi? 17
Příklad Před popisem vzoru je třeba vzor identifikovat a abstrahovat od konkrétností. Při návrhu konkrétní aplikace se objevují některé analogie mezi chováním vytvářených objektů (mají shodné stavy a přechody), jejich vazbami na okolní objekty (vystupují v podobných rolích). 18
Cesty jak odhalit NV (DP) Postup, který zachycuje vztahy mezi skupinami rolí objektů. Např. benzínová pumpa objekty: zákazník role nakupujícího benzínová pumpa role prodejce auto role příjemce Abstrakcí od detailů dojdeme k návrhu obecného vzoru prodeje (orientujeme se na role). 19
Cesty jak odhalit NV (DP) Pro prodej, kýmkoli realizovaný, je typické výskyt tří rolí: prodejce kupující příjemce Zaznamenáním vzájemného vztahu a operací probíhajících mezi těmito třemi aktory, vzniká návrhový vzor. Obecný vzor prodeje je potom možné aplikovat na jakýkoli prodej. 20
Formalizace popisu řešení CRC card Class Responsibility Collaborators Class třída, její název Responsibilities funkčnost, zodpovědnost Collaborators spolupracující třídy, komponenty Jiná grafická notace než UML UML grafická notace 21
Seznam probíraných vzorů Singleton jedináček Singleton ve společné oblasti (pool) Vrstvy (Layers) 22
Problém: Jedináček - Singleton definovat třídy tak, aby uživatel nemohl svobodně ovlivňovat počet jejich instancí chceme např. aby se vytvořila pouze jedna instance dané třídy Kontext: v mnoha aplikacích potřebujeme, aby vznikla pouze jedna instance (objekt) sdílený celou aplikací 23
Řešení: Jedináček - Singleton definovat konstruktor jako soukromý private tím je zabezpečeno, že se ke konstruktoru dostaneme pouze prostřednictvím jiné metody, která bude veřejná použít při deklaraci takové třídy modifikátor final, který zabezpečí, že třída již nemůže mít potomky (nedovolí deklaraci dalších podtříd) 24
Jedináček - Singleton přímo v deklaraci třídy se vytvoří nová instance (objekt) s daným označením, které je přístupné např. prostřednictvím metody getreference(). metoda pro získání odkazu na jediný objekt, jedináček se deklaruje jako statická, což umožňuje vytvářet instance s využitím názvu třídy 25
Grafické znázornění 26
public final class Ucet { private int cislo; private int stav; private static Ucet ucetsingleton; // tridni, staticka promenna private Ucet() { // vsechny konstruktory jsou private this(0, 0); Poznámky Účet singleton private Ucet(int cislo, int stav) { this.cislo = cislo; this.stav = stav; // tovarni (factory) metoda pro ziskani instance uctu public static Ucet getinstance(){ if(ucetsingleton == null) ucetsingleton = new Ucet(1, 0); return ucetsingleton; public void vlozeni (int castka) { stav = stav + castka; public int vyber (int castka) { stav = stav - castka; return stav; 27
public String tostring() { return String.format("Cislo uctu: %d stav uctu: %d",getcislo(), getstav()); Poznámky Účet singleton 28
public class Osoba { private String jmeno; private int roknarozeni; //pripojeni pres tridni promennou private static Ucet ucet = Ucet.getInstance(); // deklarace konstruktoru public Osoba() { this("neuvedeno", 0); public Osoba(String jmeno, int roknarozeni) { this.jmeno= jmeno; this.roknarozeni = roknarozeni; public String tostring() { String tx= String.format("\nJmeno: %s rok narozeni: %4d\nUcet: %s", getjmeno(), getroknarozeni(), ucet.tostring()); return tx; Poznámky Osoba využívá účet 1. varianta třídní proměnná ucet odkazuje na singleton jedináčka účtu public Ucet getucet(){ return ucet; public void vlozeni(int castka){ ucet.vlozeni(castka); public void vyber(int castka) { ucet.vyber(castka); 29
public class OsobaX { private String jmeno; private int roknarozeni; //private static Ucet ucet = Ucet.getInstance(); // deklarace konstruktoru public OsobaX() { this("neuvedeno", 0); public OsobaX(String jmeno, int roknarozeni) { this.jmeno= jmeno; this.roknarozeni = roknarozeni; public String tostring() { Ucet ucet = Ucet.getInstance(); String tx= String.format("\nJmeno: %s rok narozeni: %4d\nUcet: %s", getjmeno(), getroknarozeni(), ucet.tostring()); return tx; public Ucet getucet(){ Ucet ucet = Ucet.getInstance(); return ucet; public void vlozeni(int castka){ Ucet ucet = Ucet.getInstance(); ucet.vlozeni(castka); public void tiskucet(){ Ucet ucet = Ucet.getInstance(); System.out.println("Ucet: "+ucet.tostring()); Poznámky Osoba využívá účet 2. varianta v každé metodě se musí deklarovat třídní proměnná ucet odkazující na singleton jedináčka účtu 30
public class OsobaTest { public static void main(string[] args) { Osoba o1, o2, o3; OsobaX o11, o12; o1 = new Osoba("Adam", 1988); o2 = new Osoba("Alice", 1922); o3 = new Osoba("Iveta", 1977); o11 = new OsobaX("Silvestr", 1982); o12 = new OsobaX("Renata", 1975); Poznámky OsobaTest o1.vlozeni(300); o2.vyber(200); o12.vyber(50); o11.tisk(); o3.vlozeni(750); o12.vyber(400); o1.tisk(); if(o12.getucet() == o1.getucet()) System.out.println("Ucty jsou stejne"); else System.out.println("Ucty se lisi"); 31
Singleton deklarace třídy singletonu final deklarace všech konstruktorů private deklarace třídní proměnné odkazující se na singleton deklarace metody getinstance(), getreference(), getconnection() singleton ve společné oblasti pool např. pro připojení databáze pouze stanovený počet instancí 32
public interface Connection { Object get(); void set(object x); Poznámky public class ConnectionImplementation implements Connection { public Object get() { return null; public void set(object s) { ConnectionPool.checkConnection(this); public class EmptyPoolException extends Exception { public EmptyPoolException(String s){ super(s);
public class ConnectionPool { //A singleton private static PoolManager pool = new PoolManager(); //private static PoolManager pool; /* public static PoolManager getinstance(){ if(pool == null) pool = new PoolManager(); return pool; // not used declaration - getconnection is the access method */ Poznámky public static void addconnections(int number) { for(int i = 0; i < number; i++) pool.add(new ConnectionImplementation(), i+1); public static Connection getconnection() throws EmptyPoolException { return (Connection)pool.get(); public static void releaseconnection(connection c) { pool.release(c); public static void print() { pool.print();
public static void checkconnection(connection c){ pool.checkconnection(c); Poznámky
public class PoolManager { private class PoolItem { //inner class boolean inuse = false; int ident; Object item; PoolItem(Object item, int i) { this.item = item; ident = i; public String tostring() { return String.format("ident: %d inuse: %s", ident, inuse? "true" : "false"); // end inner class Poznámky private ArrayList <PoolItem> items = new ArrayList <PoolItem> (); public void add(object item, int id) { items.add(new PoolItem(item, id));
public Object get() throws EmptyPoolException { for(int i = 0; i < items.size(); i++) { PoolItem pitem = items.get(i); if(pitem.inuse == false) { pitem.inuse = true; return pitem.item; throw new EmptyPoolException(" No Free Connection "); // return null; // Delayed failure Poznámky
public void release(object item) { for(int i = 0; i < items.size(); i++) { PoolItem pitem = (PoolItem)items.get(i); if(item == pitem.item) { pitem.inuse = false; item = null; return; throw new RuntimeException(item + " not found"); Poznámky public void checkconnection(object item){ for(int i = 0; i < items.size(); i++) { PoolItem pitem = (PoolItem)items.get(i); if(item == pitem.item && pitem.inuse == false) throw new RuntimeException(item + " out of function - released "); public void print() { for(int i = 0; i < items.size(); i++) { System.out.println(items.get(i).toString());
public class ConnectionPoolDemo { public static void main(string[] args) { ConnectionPool.addConnections(3); Poznámky ConnectionPool.print(); Connection c = null; try { c = ConnectionPool.getConnection(); c.set(new Object()); c.get(); catch (EmptyPoolException e) { //throw new RuntimeException(e); System.err.printf("EmptyPoolException %s\n", e); ConnectionPool.print(); Connection c1 = null; try { c1 = ConnectionPool.getConnection(); c1.set(new Object()); c1.get(); catch (EmptyPoolException e) { //throw new RuntimeException(e); System.err.printf("EmptyPoolException %s\n", e);
ConnectionPool.print(); Poznámky Connection c2 = null; try { c2 = ConnectionPool.getConnection(); c2.set(new Object()); c2.get(); catch (EmptyPoolException e) { //throw new RuntimeException(e); System.err.printf("EmptyPoolException %s\n", e); //ConnectionPool.releaseConnection(c); ConnectionPool.print(); Connection c3 = null; Connection c3 = null; try { c3 = ConnectionPool.getConnection(); c3.set(new Object()); c3.get(); catch (EmptyPoolException e) { //throw new RuntimeException(e); System.err.printf("EmptyPoolException %s\n", e);
ConnectionPool.print(); ConnectionPool.releaseConnection(c2); c2.set(new Object()); c2.get(); ConnectionPool.print(); c = null; try { c = ConnectionPool.getConnection(); c.set(new Object()); c.get(); catch (EmptyPoolException e) { //throw new RuntimeException(e); System.err.printf("EmptyPoolException %s\n", e); Poznámky ConnectionPool.releaseConnection(c); ConnectionPool.print();
Vzor architektury vrstvy (Layers) Vzor Vrstvy (Layers) pomáhá strukturovat aplikace, které mohou být dekomponovány na skupiny podúloh, ve kterých každá skupina podúloh je v dané úrovni abstrakce. Nejznámějším příkladem architektury vrstev jsou síťové protokoly. Protokol se skládá z množiny pravidel a konvencí, které popisují, jak počítačové programy komunikují přes hranice počítačů. Je definován formát, obsah a význam zpráv. 42
Vzor architektury vrstvy (Layers) Protokol specifikuje dohody v množství abstraktních úrovní, začínající od přenosu bitů až po nejvyšší úroveň aplikační logiky. 43
Jednoduché schema Přístup po vrstvách je považován za lepší než implementace protokolu jako monolitického bloku, protože implementace koncepčně odlišných problémů odděleně přináší několik výhod např. podpora pro týmovou práci, podpora inkrementálního programování. FTP FTP protokol FTP TCP protokol TCP TCP IP protokol IP Ethernet Ethernet protokol Fyzické propojení IP Ethernet 44
Kontext Rozsáhlý systém vyžadující dekompozici. Problém Představme si, že navrhujeme systém, jehož dominantní charakteristikou je kombinace nízko a vysoko úrovňových problémů, kde vysoce úrovňové operace závisí na nízko úrovňových. Typickým vzorem komunikačního toku požadavků je, že se pohybují z vysoko úrovňových k nízko úrovňovým. Odpovědi na tyto dotazy mají směr opačný. 45
Problém V takovém případě potřebujeme dát do rovnováhy následující síly: pozdější změny kódu by neměly ovlivňovat celý systém. Měly by být svázány s jednou vrstvou. stabilní interface části systému by měly být zaměnitelné. Komponenty by měly mít možnost nahradit alternativní implementace bez účinku na zbytek systému. neexistuje žádná standardní granularita složité komponenty vyžadují další dekompozici 46
Řešení Z nejvyšší úrovně je řešení velmi jednoduché. Strukturujte váš systém do vhodného počtu vrstev a umístěte je na vrchol každé předcházející. Začněte nejnižší vrstvou abstrakce. Postupujte směrem nahoru od J-1 vrstvy k vrstvě J, až dosáhnete vrcholu. Většina služeb, které vrstva J poskytuje jsou složené služby poskytované vrstvou J-1. 47
Řešení Struktura Hlavní zásadou struktury tohoto vzoru je, že služby Vrstvy_J jsou pouze použity Vrstvou J+1. Neexistuje žádná další závislost mezi vrstvami. Tato struktura může být srovnatelná se zásobníkem. Každá konkrétní vrstva chrání nižší vrstvy od přímého přístupu některé z vyšších vrstev. Klient Vrstva N nejvyšší úroveň abstrakce Vrstva N-1 Vrstva N-1 nejnižší úroveň abstrakce 48
Scénáře použití 1. Klient zadává dotaz nejvyšší vrstvě N. Protože tato vrstva nemůže požadavek kompletně splnit, obrací se na vrstvu N-1. Ta pošle další dotaz vrstvě N-2 a tak to pokračuje až k vrstvě 1. Tam jsou vykonány služby na nízké úrovni. Je-li třeba, odpovědi na různé dotazy jsou předány do vrstvy 2, z vrstvy 2, pak do vrstvy 3, až se konečně dostanou k vrstvě N. Je to tzv. top-down komunikace. 49
Scénáře použití 2. Tento scénář ilustruje bottom-up komunikaci. Např. když driver zařízení detekuje vstup, začíná se od vrstvy 1. Pak se pokračuje vrstvou 2, až se dosáhne nejvyšší vrstvy N. 50
Scénáře použití 3. Tento scénář popisuje situaci, kdy požadavky prochází pouze podmnožinou vrstev. Např. požadavek na nejvyšší úrovni postoupí k úrovni N-1, pokud tato úroveň uspokojí jeho požadavek, dál se již nepokračuje. Příkladem může být cache. 4. Tento scénář je podobný předchozímu jen s tím rozdílem, že se začíná od nejnižší vrstvy a pokračuje se pouze nejvyšší nutné vrstvě. 51
Scénáře použití 5. Zahrnuje dva zásobníky komunikujících vrstev. Tento scénář je známý z komunikačních protokolů, kde jsou zásobníky známé jako zásobníky protokolů. 52
Implementace 1. Definovat abstraktní kritérium pro seskupení úloh do vrstev. 2. Stanovit počet abstraktních úrovní podle vašeho abstrakčního kritéria. Každá abstrakční úroveň koresponduje s jednou vrstvou vzoru. 3. Pojmenovat vrstvy a přiřadit úlohy ke každé z nich. 4. Specifikovat služby jednotlivých vrstev. 5. Zjemnit vrstvení. 6. Specifikovat rozhraní pro každou vrstvu. 7. Navrhnout strategii ošetření chyb. 53
Varianty Relaxed Layered System je méně restriktivní co se týká vztahů mezi vrstvami. V této variantě může každá vrstva využívat služeb libovolné nižší vrstvy. Může také existovat varianta, kdy jednotlivé vrstvy mohou zviditelnit některé služby pro libovolnou z vyšších vrstev a naopak některé služby poskytovat pouze pro nejbližší vyšší vrstvu. Layered Through Inheritance je varianta, která se nachází v některých objektově orientovaných systémech. V této variantě jsou nižší vrstvy implementovány jako základní třídy. 54
Známé aplikace Virtuální stroje. Příkladem může být Java Virtual Machine (JVM) definující formát binárního kódu. Protože je JVM je závislý na softwarové platformě, existují různé JVM pro různé operační systémy a procesory. APIs- Application Programming Interface rozhraní aplikačních programů. API je obyčejně kolekce funkčních specifikací (volání systémových funkcí). Informační systém IS. Rovněž informační systémy bývají vytvářeny pomocí architektury založené na vrstvách. 55
Výhody Znovupoužitelnost vrstev, dá se využít v případě dobře definované abstrakce a dobře definovaného a dokumentovaného rozhraní. Podpora standardizace. Jasně definované a všeobecně akceptované úrovně abstrakce umožňují rozvoj standardizovaných úloh a rozhraní. Závislosti jsou lokální. Standardizované rozhraní mezi vrstvami obyčejně omezuje změnu kódu pouze na danou vrstvu. Zaměnitelnost. Daná implementovaná vrstva může být zaměněna sémanticky ekvivalentní implementací bez velkého úsilí. 56
Slabá místa Kaskádní změny chování může nastat při změně chování dané vrstvy. Nízká efektivnost. Architektura založená na vrstvách je obyčejně méně efektivní než monolitická. Problémy se stanovením správné granularity vrstev. 57