Návrhové vzory. n OO jazyky - široká paleta technických prostředků. n Návrhový vzor. n rozhraní!! n volnější vazby, parametrizace

Podobné dokumenty
Literatura. E. Gamma, R. Helm, R. Johnson, J. Vlissides The Gang of Four (GoF) Design Patterns Elements of Reusable Object-Oriented Software 1995

Návrhové vzory. Jakub Klemsa, Jan Legerský. 30. října Objektově orientované programování.

Semin aˇr Java N avrhov e vzory Radek Ko ˇc ı Fakulta informaˇcn ıch technologi ı VUT Duben 2009 Radek Koˇc ı Semin aˇr Java N avrhov e vzory 1/ 25

Semin aˇr Java N avrhov e vzory Radek Ko ˇc ı Fakulta informaˇcn ıch technologi ı VUT Duben 2008 Radek Koˇc ı Semin aˇr Java N avrhov e vzory 1/ 24

Návrhové vzory OMO, LS 2014/2015

Kód, který se nebude často měnit

specifikuje vytvářené objekty pomocí prototypické instance nový objekt vytváří kopírováním prototypu

ČÁST 1. Zahřívací kolo. Co je a k čemu je návrhový vzor 33

Úvod - problém. Při přidání nového modelu je nutné upravit. Kód, který se nebu de často měnit. n Mějme obchod s auty:

Abstract Factory úvod

Design Patterns. Tomáš Herceg Microsoft MVP (ASP.NET)

Bridge. Známý jako. Účel. Použitelnost. Handle/Body

Vývoj informačních systémů. Architektura, návrh Vzory: Doménová logika

Obsah Znovupou ˇzitelnost N avrhov e vzory Z asady programov an ı Radek Koˇc ı Semin aˇr Java N avrhov e vzory, Z asady... 2/ 46

Základy objektové orientace I. Únor 2010

OMO. 4 - Creational design patterns A. Singleton Simple Factory Factory Method Abstract Factory Prototype Builder IoC

Vazba (volná, těsná) - míra znalosti jedné třídy*komponenty o druhé.

Vyřešené teoretické otázky do OOP ( )

PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITY PALACKÉHO KATEDRA INFORMATIKY BAKALÁŘSKÁ PRÁCE. Návrhové vzory Dan Doležel

IB111 Programování a algoritmizace. Objektově orientované programování (OOP)

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

Zpracoval:

PB161 Programování v jazyce C++ Přednáška 7

PB161 Programování v jazyce C++ Přednáška 7

Návrhový vzor Factory v JAVA API

, Brno Připravil: David Procházka Návrhové vzory

State. Známý jako. Účel. Použitelnost. Stav, Object for States. umožňuje objektu měnit svoje chování v závislosti na stavu objekt mění svou třídu

Návrhové vzory Design Patterns

Problém, jehož různé instance je třeba často řešit Tyto instance lze vyjádřit větami v jednoduchém jazyce

Generické programování

Obsah přednášky 9. Skrývání informací. Skrývání informací. Zapouzdření. Skrývání informací. Základy programování (IZAPR, IZKPR) Přednáška 9

Dědění, polymorfismus

Observer. Klasifikace. Alias. Smysl. Potřeba sledování změn objektu a notifikace. Obdoba systému událostí (C#, Java) vlastními prostředky

Programování v C++ 2, 4. cvičení

OBJEKTOVÉ PROGRAMOVÁNÍ V C++ V PŘÍKLADECH 8 Proudová knihovna 8.1 Hierarchie proudů Standardně zavedené proudy

Objektové programování

typová konverze typová inference

Obsah přednášky 7. Základy programování (IZAPR) Přednáška 7. Parametry metod. Parametry, argumenty. Parametry metod.

Třídy. Instance. Pokud tento program spustíme, vypíše následující. car1 má barvu Red. car2 má barvu Red. car1 má barvu Blue.

Dědičnost (inheritance)

Semin aˇr Java X Radek Koˇc ı Fakulta informaˇcn ıch technologi ı VUT Duben 2011 Radek Koˇc ı Semin aˇr Java N avrhov e vzory, Z asady...

Teoretické minimum z PJV

Programování II. Třídy a objekty (objektová orientovanost) 2018/19

Výčtový typ strana 67

Definice třídy. úplná definice. public veřejná třída abstract nesmí být vytvářeny instance final nelze vytvářet potomky

6 Objektově-orientovaný vývoj programového vybavení

1. Dědičnost a polymorfismus

Architektura softwarových systémů

IoC/DI. Tomáš Herceg Microsoft MVP (ASP.NET)

Michal Krátký. Úvod do programovacích jazyků (Java), 2006/2007

UML. Unified Modeling Language. Součásti UML

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

NetBeans platforma. Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

Programování II. Modularita 2017/18

NPRG031 Programování II 1 / :25:46

NMIN201 Objektově orientované programování 1 / :36:09

Motivační příklad reálný svět. výroba (assembly line)

Dynamicky vázané metody. Pozdní vazba, virtuální metody

Programování II. Polymorfismus

Programování v C++ 2, 7. cvičení

Úvod Třídy Rozhraní Pole Konec. Programování v C# Hodnotové datové typy, řídící struktury. Petr Vaněček 1 / 39

Obsah přednášky. 12. Dokumentace zdrojového kódu Tvorba elektronické dokumentace UML. Co je diagram tříd. Ing. Ondřej Guth

Jazyk C++ I. Polymorfismus

PB161 Základy OOP. Tomáš Brukner

Seznamy a iterátory. Kolekce obecně. Rozhraní kolekce. Procházení kolekcí

IRAE 07/08 Přednáška č. 1

Chain of responsibility

Návrhové vzory. Každý návrhový vzor má následující strukturu: Většina publikací návrhové vzory člení do následujících kategorií:

Využití OOP v praxi -- Knihovna PHP -- Interval.cz

Class loader. každá třída (java.lang.class) obsahuje referenci na svůj class loader. Implementace class loaderu

Michal Krátký. Úvod do programovacích jazyků (Java), 2006/2007

24. listopadu 2013, Brno Připravil: David Procházka

Definice třídy. úplná definice. public veřejná třída abstract nesmí být vytvářeny instance final nelze vytvářet potomky

Principy objektového návrhu. Přednáška 8, LS 2013/2014

Úvod do programovacích jazyků (Java)

Objekty, třídy, vazby 2006 UOMO 30

TÉMATICKÝ OKRUH Softwarové inženýrství

Facade. Známý jako. Účel. Motivace. Facade, Fasáda

7. přednáška - třídy, objekty třídy objekty atributy tříd metody tříd

7.5 Diagram tříd pokročilé techniky

Hiearchical MVC (Model-view-controller) vs. PAC (Presentation-abstraction-control)

Struktura programu v době běhu

Abstraktní třída a rozhraní

Programování v C++ 1, 5. cvičení

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Programování v C++ 1, 6. cvičení

7 Jazyk UML (Unified Modeling Language)

Michal Krátký. Úvod do programovacích jazyků (Java), 2006/2007

Obsah. Úvod 11 Základy programování 11 Objektový přístup 11 Procvičování 11 Zvláštní odstavce 12 Zpětná vazba od čtenářů 12 Errata 13

Programování II. Návrh programu II

4. ZÁKLADNÍ POJMY Z OBJEKTOVĚ ORIENTOVANÉHO PROGRAMOVÁNÍ

Obsah. October 2, Polymorfizmus. Typologie testování. Problém polymorfizmu. Vady/Anomálie. Vazební sekvence ČVUT FEL, K13132

Abstraktní datové typy: zásobník

Parametrizované třídy Generics generické třídy. JDK zavádí mimo jiné tzv. parametrizované třídy - generics

Při studiu tohoto bloku se předpokládá, že student je zvládá základy programování v jazyce Java s využitím vývojového prostředí NetBeans.

Třída. Atributy. Operace

Arlow, J., Neustat, I.: UML2 a unifikovaný proces vývoje aplikací. Computer Press, Praha 2007.

Michal Krátký. Úvod do programovacích jazyků (Java), 2006/2007

7.5 Diagram tříd pokročilé techniky

Programování v C++ 3, 3. cvičení

Transkript:

Návrhové vzory

Návrhové vzory n OO jazyky - široká paleta technických prostředků q dědičnost, polymorfismus, šablony, reference, přetěžování,... q problém - jak toto všechno efektivně používat q cíl - udržovatelný a rozšiřovatelný 'velký' software n rozhraní!! n volnější vazby, parametrizace n dědičnost implementace vs. dědičnost rozhraní n dědičnost vs delegace n Návrhový vzor q pojmenované a popsané řešení typického problému q principiálně existují již dlouho n architektura: Christopher Alexander - pojem 'Pattern' n literatura: tragický hrdina, romantická (tele)novela,...

Návrhové vzory v software n Software q asi žádný jiný obor si nelibuje ve vynalézání kola stále znovu q strukturovaný přístup n spojové seznamy, stromy, rekurze,... q OOP - systém reusabilních návrhových vzorů (NV) n Co má NV pro typickou situaci popisovat q jak a kdy mají být objekty vytvářeny q jaké vztahy a struktury mají obsahovat třídy q jaké chování mají mít třídy, jak mají spolupracovat objekty

Definice a použití Návrhový vzor je popis komunikujících objektů a tříd uzpůsobených k řešení obecného problému v konkrétním kontextu n Relativní komplexnost a obecnost q pro rozsáhlejší systémy n předpoklad dlouhé životnosti, údržby a rozšiřování q při návrhu nových systémů q při rozsáhlých úpravách n Inženýrský přístup q přehled o existenci a typickém použití q při návrhu hledat uplatnění n 'Revouční' myšlenka GoF q vytvoření utříděného katalogu 23 vzorů ve 3 kategoriích q v současnosti množství dalších vzorů n často pro specializované použití

Základní prvky n Název q co nejvíce vystihující podstatu, usnadnění komunikace - společný slovník n Problém q obecná situace kterou má NV řešit, podmínky použití n Řešení q soubor pravidel a vztahů popisujících jak dosáhnout řešení problému q nejen statická struktura, ale i dynamika chování n Souvislosti a důsledky q detailní vysvětlení použití, implementace a principu fungování q způsob práce s NV v praxi n Příklady q definice konkrétního problému, vstupní podmínky, popis implementace a výsledek n Související vzory q použití jednoho NV nepředstavuje typicky ucelené řešení - řetězec NV q okolnosti pro rozhodování mezi různými NV

Kategorie základních NV Creational Tvořivé vzory Structural Strukturální vzory Behavioral Vzory chování Třída Factory Method Adapter Interpreter Template Method Objekt Abstract Factory Builder Prototype Singleton Bridge Composite Decorator Facade Proxy Flyweight Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor vytváření objektů uspořádání tříd a objektů chování a interakce objektů a tříd

Kategorie základních NV Creational Tvořivé vzory Structural Strukturální vzory Behavioral Vzory chování Třída Factory Method Adapter Interpreter Template Method Objekt Abstract Factory Builder Prototype Singleton Bridge Composite Decorator Facade Proxy Flyweight Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor vytváření objektů uspořádání tříd a objektů chování a interakce objektů a tříd

Vztahy mezi NV

Značení Object Modeling Technique class diagrams object diagrams interaction diagrams

Tvořivé NV n Creational Patterns n Abstrakce procesu vytváření objektů q umožňují ovlivnit způsob vytváření objektů a jejich počet q často nestačí použít new, např. pokud typ objektu závisí na parametrech n Užitečné při převažující objektové kompozici (místo dědičnosti) q místo napevno naprogramovaného chování množina obecnějších metod q větší flexibilita co se vytváří, kdo to vytváří, jak a kdy se to vytváří n Typické prostředky q zapouzdření znalosti o použití konkrétní třídy q zakrytí vzniku a skládání objektů n Tvořivé vzory q Singleton - zaručí pouze jednu instance třídy q Factory Method - vytváří instance vybrané třídy - virtuální funkce místo new q Abstract Factory - vytváří objekty pro vybranou skupinu tříd - tovární třída q Builder - odděluje způsob vytvoření objektu od reprezentace, postupné vytváření q Prototype - umožňuje zkopírovat (klonovat) inicializovanou instanci

Bludiště n Jednotný příklad pro tvořivé NV - vytvoření bludiště q množina místností, místnost zná své sousedy - zeď, jiná místnost nebo dveře komponenty

Bludiště - prvotní implementace import static System.*; enum Direction {North, South, East, West}; interface MapSite { void enter(); }; class Room implements MapSite { MapSite sides[4]; int roomnumber; }; Room(int roomno) { roomnumber = roomno; } MapSite getside(direction d) {..}; void setside(direction d, MapSite m){..}; void enter() {..}; Enter - soused je: místnost nebo otevřené dveře projít J zeď nebo zavřené dveře stát L class Wall implements MapSite { public: Wall() {}; void enter() {}; }; class Door implements MapSite { Room room1; Room room2; boolean isopen; }; Door(Room r1, Room r2) {}; void enter() {}; Room othersidefrom(room r) {}; class Maze { Maze() {out.print( creating )} void addroom(room r) {}; Room roomno(int) {}; };

Bludiště - prvotní implementace import static System.*; enum Direction {North, South, East, West}; interface MapSite { void enter(); }; class Room implements MapSite { MapSite sides[4]; int roomnumber; }; Room(int roomno) { roomnumber = roomno; } final MapSite getside(direction d) {..}; final void setside(..){..}; void enter() {..}; Enter - soused je: místnost nebo otevřené dveře projít J zeď nebo zavřené dveře stát L class Wall implements MapSite { public: Wall() {}; void enter() {}; }; class Door implements MapSite { Room room1; Room room2; boolean isopen; }; Door(Room r1, Room r2) {}; void enter() {}; final Room othersidefrom(..) {}; class Maze { Maze() {out.print( creating )} final void addroom(room r) {}; final Room roomno(int) {}; };

Bludiště n Jednotný příklad pro tvořivé NV - vytvoření bludiště q množina místností, místnost zná své sousedy - zeď, jiná místnost nebo dveře komponenty

Bludiště - vytvoření import static package.direction.*; class MazeGame { Maze createmaze () { Maze maze = new Maze(); Room r1 = new Room(1); Room r2 = new Room(2); Door thedoor = new Door(r1, r2); vytvoření bludiště se 2 místnostmi místnosti a dveře mezi nimi hranice místností maze.addroom(r1); maze.addroom(r2); } r1.setside(north, new Wall()); r1.setside(east, thedoor); r1.setside(south, new Wall()); r1.setside(west, new Wall()); r2.setside(north, new Wall()); r2.setside(east, new Wall()); r2.setside(south, new Wall()); r2.setside(west, thedoor); return maze; n poměrně komplikované n neflexibilní!! q změna tvaru - změna metody q změna chování - nutnost přepsání q DoorNeedingSpell, SpecialRoom n hard coded M

Možná vylepšení pomocí tvořivých NV Zvýšení flexibility - odstranění explicitních referencí na konkrétní třídy n Singleton q zaručí jedinečnost instance bludiště a přístup k ní bez potřeby globálních dat n Factory Method q CreateMaze při vytváření komponent volá virtuální funkci místo konstruktoru q potomek MazeGame může změnou virtuální funkce vytvářet instance jiných tříd n Abstract Factory q CreateMaze dostane parametr objekt pro vytváření komponent q možnost změny instanciovaných tříd předáním jiného parametru n Builder q CreateMaze dostane parametr objekt s operacemi pro přidávání komponent q pomocí dědičnost lze lzměnit jednotlivé vytvářené části nebo způsob vytváření n Prototype q CreateMaze dostane parametry prototypy objektů které se umí klonovat q možnost změny předáním jiných (poděděných) parametrů

Konkrétní tvořivé NV n Na samostatných slajdech q Singleton q Factory Method q Abstract Factory q Builder q Prototype

Tvořivé NV - shrnutí n Singleton q jednoduché použití pokud není nutné řešit destrukci objektů q různé varianty pro vzájemně provázané objekty n Factory Method q flexibilita za relativně malou cenu - obvyklá základní metoda, virtual constructor q nevýhoda: nutnost dědičnosti i pro změnu třídy produktu n Product/ConcreteProduct, Creator/ConcreteCreartor - šablony / generics q odložená inicializace n Abstract Factory, Builder, Prototype q flexibilnější, složitější - použití až při zjištění potřeby větší flexibility q kompozice objektů n továrního objektu zodpovědný za znalost třídy produktů a jejich výrobu q Abstract Factory n tovární objekt vytváří objekty více souvisejících tříd q Builder n tovární objekt vytváří složený objekt postupně pomocí odpovídajícího protokolu q Prototype n nové objekty se vytvářejí kopírováním prototypových objektů n prototypy se umějí samy klonovat

Tvořivé NV - srovnání n Maze aaa createmaze() { Maze maze = makemaze(); Room r1 = makeroom(1); Room r2 = makeroom(2); Door thedoor = makedoor(r1, r2); Maze createmaze( MazeFactory factory) { Maze maze = factory.makemaze(); Room r1 = factory.makeroom(1); Room r2 = factory.makeroom(2); Door door = factory.makedoor(r1,r2); Maze createmaze( MazeBuilder builder) { builder.buildmaze(); Factory Method builder.buildroom(1); builder.buildroom(2); builder.builddoor(1, 2); Abstract Factory return builder.getmaze(); MazeProtoFactory simplemazefactory = new MazeProtoFactory ( new Maze(), new Wall(), new Room(), new Door() Builder ); Maze maze = game.createmaze( simplemazefactory); Prototype MazeProtoFactory { Wall makewall () { return protowall.clone(); } Door makedoor (Room r1, Room r2) { Door door = protodoor.clone(); door.initialize(r1, r2); return door; }

Strukturální NV n Structural Patterns q jak jsou třídy a objekty složeny do větších struktur n Strukturální NV tříd q dědičnost pro skládání rozhraní nebo implementací q Adapter - přizpůsobení rozhraní třídy jiným rozhraním n Strukturální NV objektů q skládání objektů pro dosažení nové funkcionality q runtime skládání - větší flexibilita q Bridge - lepší separace rozhraní a implementace q Facade - reprezentace celého systému jedním objektem, jednotné rozhraní q Proxy - zástupce jiného objektu q Decorator - dynamické přidávání funkčnosti k objektům q Composite - hierarchie tříd tvořená dvěma druhy objektů - primitivní a složené q Flyweight - efektivní struktura pro velké množství sdílených objektů

Konkrétní strukturální NV Na samostatných slajdech q Adapter n přizpůsobení rozhraní třídy na rozhraní jiné třídy, spolupráce tříd s různým rozhraním q Bridge n odděluje abstrakci od implementace n předchází nárůstu počtu tříd při přidávání implementací q Facade n definuje jedno společné rozhraní pro subsystém q Proxy n zástupce/náhradník objektu, kontrola přístupu k objektu q Decorator n rozšiřuje objekt o nové vlastnosti n dynamický (dědění=statické), transparentní (rozšiřovaný objekt nic neví) q Composite n jak postavit hierarchii tříd složenou ze dvou druhů objektů: primitivní a složené n složené objekty se rekurzivně skládají z primitivních a dalších složených objektů q Flyweight n podpora většího počtu jednoduchých objektů

Adapter vs. Bridge

Adapter vs. Bridge n Společné vlastnosti q flexibilita - stupeň indirekce vůči jiným objektům, zasílání zpráv přes jiné rozhraní n Základní rozdíl - účel q Adapter n vyřešení nekompatibilit mezi dvěma existujícími rozhraními n jak zajistit aby dvě nezávislé třídy mohly spolupracovat bez reimplementace q Bridge n poskytuje relativně stabilní rozhraní pro potenciálně velký počet implementací n zachovává rozhraní i při dalším vývoji a změně implementačních tříd n Důsledek: časté použití při různých fázích vývojového cyklu q Adapter n při nepředvídané (pozdější) potřebě spolupráce dvou nekompatibilních tříd n použití PO návrhu q Bridge n při poznání, že abstrakce může mít více implementací, které se můžou dále vyvíjet n použití PŘI návrhu q... což neznamená, že Adapter je méně hodnotný než Bridge, jen řeší jiný problém

Composite vs. Decorator vs. Proxy

Composite vs. Decorator vs. Proxy n Composite a Decorator - podobná struktura q rekurzivní struktura - Decorator jako speciální případ Compositu? q ne - různé účely q Decorator n zabraňuje explozi odvozených tříd při přidávání kombinací funkčnosti q Composite n struktura - objekty různého druhu (vč. složených) se zpracovávají jednotně n zaměřen na reprezentaci objektů, ne na zdobení n Proxy a Decorator - podobná struktura q Proxy n stupeň indirekce pro přístup k objektu - jednotné rozhraní q implementace obsahují reference na jiný objekt, kterému zasílají zprávy n není určen k dynamickému přidávání a odstraňování vlastností n není určen k reprezentaci rekurzivní struktury q Decorator n component poskytuje pouze část funkčnosti n celková funkčnost objektu nemusí být určena v době kompilace n základní rys Decoratoru - neomezenost pomocí rekurzivní struktury

NV chování n Behavioral design patterns q rozdělení funkčnosti a zodpovědnosti mezi objekty q komunikace mezi objekty q složitější struktura provádění kódu q umožňuje zaměřit se při návrhu na propojení tříd, ne na běhové technické detaily q dynamické vztahy - RT vlastnosti q vzájemná provázanost n Behavioral class patterns q použití dědičnosti pro rozložení chování mezi třídy q Template method n abstraktní definice algoritmu po jednotlivých krocích n každý krok je buď primitivní nebo abstraktní operace definovaná v odvozených třídách q Interpreter n reprezentace gramatiky jako hierarchie tříd n implementace interpretru jako operace na objektech

NV chování n Behavioral object patterns q spolupráce mezi skupinami objektů pro dosažení funkčnosti n Objektová kompozice místo dědičnosti q Mediator n odstraňuje nutnost referencí na všechny spolupracující objekty q Chain of Responsibility n zasílání zpráv neznámým objektům přes zřetězené objekty q Observer n definování závislosti objektu k více objektům, šíření události k závislým objektům n Zapouzdření chování objektu a řízení přístupu q Strategy n zapouzdření funkčnosti algoritmu do objektu, možnost jejich záměny q Command n zapouzdření požadavku na funkci, oddělení požadavku a vykonání funkce q State n zapouzdření stavu, možnost změny chování objektu při změně stavu q Visitor n zapouzdření chování, které by jinak bylo rozloženo mezi více tříd q Iterator n abstrakce procházení agragovaných objektů

Vztahy mezi odesílateli a příjemci zpráv Comand Separace příjemce (a parametrů) od okamžiku volání Observer neznámý počet příjemců Mediator centralizace komunikace přes prostředníka Chain of Responsibility neznámá struktura příjemců i v okamžiku volání

Závěr n Shrnutí q 'Žádné velké moudro' n... jak pro koho q Slovník! q Implementace bez vymýšlení kola n... a 'bez chyb' q Kompozice NV q Generické implementace q Mnoho dalších rozšiřujících vzorů n často cíleně zaměřených