N ÁVRHOVÉ VZORY

1. NÁVRHOVÉ VZORY Ing. Jaroslav Jakubík jakubik@fiit.stuba.sk www.fiit.stuba.sk\~jakubik

2. AGENDA(1/3) • história a vznik vzorov • osobnosti v oblasti vzorov • analytické, dátové, návrhové vzory • návrhové vzory a ich rozdelenie • creational patterns • abstract factory • builder • singleton Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

3. AGENDA(2/3) • structural patterns • composite • facade • behavioral patterns • chain of responsibility • state • j2ee core patterns • data access object • transfer object Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

4. AGENDA(3/3) • business delegate • software reengineering process s podporou Rational Rose • data modeling reengineering • OO reengineering Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

5. HISTÓRIA VZOROV Ch. Alexander A Pattern Language, Towns, Buildings,Construction. 1977 J. Coplien, D. Schmidt Pattern Languages of Program Design. 1995 E. Gamma, R. Helm, R. Johnson, J. Vlissides Design patterns. 1995 Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

6. OSOBNOSTI (1/2) • Ch. Alexander • narodený vo Viedni 1936 • na Cambridge University študoval Matematiku a Architektúru • PhD. získal v odbore architektúry na Harvard University • od 1963 bol profesorom architektúry na University of Californiaat Berkeley • riaditeľ Center for Environmental Structure • člen Swedish Royal Academy • od 1996 členom American Academy of Arts and Science • Prince of Wales’s Institute of Architecture Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

7. OSOBNOSTI (2/2) • E. Gamma • technický riaditeľ Object Technology International’s (OTI) Software Technology v Zurichu • jedným z architektov VisualAge MicroEdition IDE • hlavný návrhár JUnit a Eclipse Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

8. VZORY VO VŠETKÝCH FÁZACH • analytické vzory • dátové vzory • architektonické vzory • Layers, Pipes & Filters • návrhové vzory • Composite, Abstract Factory • implementačné vzory • C++ templates Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

9. NÁVRHOVÉ VZORY • všeobecné vzory • Creational patterns • Structural patterns • Behavioral patterns • doménovo špecifické vzory • inštancie všeobecných vzorov • riešia obmedzenú skupinu problémov • môžu byť podmnožinou všeobecných vzorov • vzory typické pre konkrétny jazyk • J2EE core patterns Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

10. CREATIONAL PATTERNS • zabstraktňujú proces tvorby inštancií • pomáhajú vytvárať systém nezávislí na spôsobu vytvárania, skladania a reprezentácie jeho objektov • triedne tvorivé vzory • dedičnosť pre zmenu triedy vytvorenej inštancie • objektové tvorivé vzory • delegujú tvorbu inštancií na iný objekt Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

11. ABSTRACT FACTORY • lisovanie tabuľového plechu v automobilkách • rovnaký stroj je používaný pre vytváranie rôznych častí automobilu • konfigurácia je realizovaná zmenou valcov a rezníc v lisovacom stroji Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

12. AF - kontext • účel • poskytuje rozhranie pre vytváranie rodín príbuzných tried bez nutnosti špecifikácie konkrétnych tried • necháva rozhodnutie o konkrétnych triedach až na run time • použitie • potrebujeme abstrahovať od detailov implementácie • potrebujeme viac rodín produktov Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

13. AF - štruktúra Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

14. AF - prístup • Simple Abstract Factory • AF definuje Factory metódy pre vytvorenie konkrétnych podtried • voľba konkrétnej podtriedy je definovaná volaním konkrétnej Factory metódy • Abstract Factory • AF definuje všeobecný protokol Factory metód • konkrétne podtriedy implementujú daný protokol Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

15. AF - charakteristiky • Abstract Factory je Object Maker • typicky vytvára viac ako jediný typ objektu • objekt je známy klientovi len cez rozhranie • izoluje konkrétne triedy • umožňuje ľahkú výmenu celých rodín registrovaných objektov • náročné pridávanie produktov a rodín Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

16. BUILDER • fast food reštaurácie ponúkajú children’s meal • zamestnanec podľa objednávky zabalí hlavné jedlo, vedľajšie jedlo, hračku a pridá nápoj Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

17. B - kontext • účel • oddeľuje konštrukciu komplexných objektov od ich vnútornej reprezentácie • rovnaký konštrukčný proces môžeme použiť na vytvorenie rôznych objektov • použitie • potrebujeme vytvoriť elementy komplexnej agregácie • v nezávislosti od rôznych vstupov, výsledný objekt vytvárame rovnakým spôsobom Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

18. B - štruktúra Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

19. B - charakteristiky • umožňuje klientovi meniť internú reprezentáciu produktu • odstraňuje závislosti medzi konštrukciou a na výsledku participujúcimi časťami • podporuje modularitu izolovaním kódu konštrukcie a reprezentácie • dáva vývojárovi plnú kontrolu nad konštrukčným procesom Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

20. SINGLETON • úrad prezidenta Slovenskej republiky • prezident je v danom volebnom období iba jeden • v nezávislosti od konkrétnej osoby označenie Prezident Slovenskej republiky je globálny prístupový bod identifikujúci aktuálnu osobu tohto úradu Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

21. S - kontext • účel • kontroluje počet vytvorených inštancií • sprístupňuje vytvorenú inštanciu na požiadanie • použitie • systém vyžaduje vytvorenie jedinej inštancie konkrétnej triedy • systém vyžaduje globálny prístupový bod k tejto inštancií • logovanie, prihlasovanie, komunikácia Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

22. S - štruktúra • privátny konštruktor, ktorý môže byť volaný len z vnútra konkrétnej triedy • statická metóda vracajúca inštanciu konkrétnej triedy • statická metóda pri prvom pristúpení vytvorí použitím privátneho konštruktora inštanciu triedy • pri ďalších prístupoch statická metód vráti vytvorenú inštanciu Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

23. S – charakteristiky • riadený prístup k jedinej inštancií • na rozdiel od globálnych premenných umožňuje pridať do statickej metódy doplňujúcu logiku • modifikovaný Singleton umožňuje variabilný počet inštancií • môže byť použitý ako nadstavba nad pooling manažment Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

24. STRUCTURAL PATTERNS • skladanie objektov a vytváranie rozsiahlejších štruktúr • triedne štrukturálne vzory • využívajú dedičnosť • výsledkom je trieda, ktorá kombinuje vlastnosti rodičovských tried • objektové štrukturálne vzory • spôsob skladby objektov z dôvodu podpory nových funkcií • zmena skladby v run time Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

25. COMPOSITE • štandardný aritmetický výraz je zložený z operand1 operátor operand2 • na pozícií operand1 alebo operand2 môže byť ďalší aritmetický výraz • týmto spôsobom vytvárame stromovú štruktúru Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

26. C - kontext • účel • skladá objekty do stromových štruktúr k vyjadreniu hierarchií typu časť – celok • umožňuje pracovať s celkom rovnakým spôsobom ako s časťou • použitie • vyjadrenie objektových hierarchií časť – celok • klient môže ignorovať rozdiel medzi celkom a časťou Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

27. C - štruktúra Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

28. C - prístup • Safe Composite • metódy pre pridávanie / odstraňovanie sú iba v AbstractComposite • chyby sú identifikované už v čase kompilácie • Transparent Composite • metódy pre pridávanie / odstraňovanie sú definované v AbstractComponent • problém čo s Component-ami, ktoré nemajú tieto možnosti podporovať Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

29. C - charakteristiky • definuje triedne hierarchie obsahujúce primitívne a zložene objekty • zjednodušuje klienta • zjednodušuje pridávanie nových druhov komponentov • môže návrh príliš zovšeobecniť Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

30. FACADE • objednávanie cez hotline a katalóg • zákazník zavolá na hotline • slečna preberajúca objednávky vypĺňí potrebné dokumenty a týmto zákazníkovi sprístupní zložitý vnútorný systém firmy Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

31. F – kontext • účel • poskytuje unifikované rozhranie (sadu rozhraní) v subsystéme • definuje rozhranie na vyššej úrovni pre uľahčenie práce so subsystémom • použitie • chceme poskytnúť jednoduché rozhranie k zložitému subsystému • chceme subsystémy usporiadať do vrstiev • chceme skryť zložité vzťahy a závislosti Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

32. F - štruktúra Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

33. F - charakteristiky • znižuje počet objektov, s ktorými musí klient spolupracovať pri riešení komplexnejšej úlohy • slabé spojenie medzi klientom a subsystémom (pri zmene jadra subsystému sa nemusí nutne zmeniť fasáda) • explicitne nezabraňuje použitiu tried a objektov za fasádou pokiaľ je to nutné Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

34. BEHAVIOURAL PATTERNS • zaoberajú sa algoritmami a rozdelením povinností medzi objekty • opisujú tiež vzory komunikácie medzi objektmi • triedne vzory chovania • dedičnosť k rozdeleniu chovania do tried • objektové vzory chovania • využívajú objektovú skladbu Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

35. CHAIN OF RESPONSIBILITY • mechanický stroj pre rozpoznávanie minci na základe ich rozmerov • mince prepadávajú dierami až pokiaľ nie sú spracované • mincu spracuje prvá diera menšia ako minca • O o . Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

36. CHoR - kontext • účel • vyhýba sa spojeniu odosielateľa a príjemca • zreťazí objekty medzi odosielateľom a príjemcom, ktorý spracuje vyslanú žiadosť • použitie • žiadosť môže spracovať viac ako jediný objekt • neurčujeme explicitne príjemcu • skupina objektov, ktoré spracúvajú žiadosť je určená dynamicky Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

37. CHoR - štruktúra Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

38. CHoR - charakteristiky • oslobodzuje objekt od znalosti spracovateľa žiadosti • typická implementácia v Smalltalk (pošleme akúkoľvek správu objektu, ak ju nevie spracovať ošetríme poslanie ďalej) • nezaručený príjemca žiadosti o spracovanie Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

39. STATE • výdajný automat • v závislosti na zásobách, inkasovanej sumy, sumy v depozite sa automat nachádza v rôznych stavoch Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

40. S – kontext • účel • zmeniť chovanie objektu, keď sa zmení jeho vnútorný stav • objekt zdanlivo mení svoju triedu • použitie • chovanie objektu závisí na jeho stave • operácie obsahujú veľké z viac častí zložené if then else konštrukcie, ktoré závisia od stavu objektu • stav objeku je reprezentovaný jednou alebo viacerými konštantami vymenovaného typu Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

41. S – štruktúra Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

42. S - charakteristiky • oddeľuje chovanie pre rôzne stavy • znižuje náklady na udržovateľnosť kódu • lepšia štrukturalizácia kódu v porovnaní so switch resp. if then else konštrukciami • vyjadruje explicitne prechod medzi stavmi • zjednodušuje pridanie ďalšieho stavu (na rozdiel od modifikácie viacerých if then else a switch konštrukcií) Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

43. J2EE Core Patterns • typicky používané v spojení s JAVA-ou • vyvíjané, zverejňované a propagovane firmou SUN • 15 vzorov • Core J2EE Patterns: Best Practices and Design Strategies • http://java.sun.com/blueprints/corej2eepatterns/ Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

44. J2EE – Data Access Object • prístup k údajom úložiska • rôzne typy, rôzny výrobcovia, rôzne API • prístup k úložiskám typu RDBMS, OODBMS, XML, LDAP • alternatívne prístupy • bean - managed persistence – využíva API konkrétneho úložiska, priamy prístup • bean – managed persistence doplnená o kontainery pre realizáciu transakcií • JDBC API a štandardné SQL Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

45. J2EE – DAO riešenie • riešenie v J2EE = DAO • zovšeobecňuje a enkapsuluje všetky prístupy k zdroju dát • manažuje pripojenie k zdroju dát, získanie, uloženie a zmenu dát • zakrýva implementačné detaily zdroju dát pred klientom • voľná zmena zdroju dát • interface DAO nezávislý od zdroju dát Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

46. J2EE – DAO štruktúra • DAO predstavuje adaptér medzi BO a dátovým zdrojom Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

47. J2EE – DAO prístupy • Automatic DAO code generation • 1:1:1 (Tabuľka : DAO : BO) • nástroje tretej strany (hibernate, ...) • grafické znázornenie mapovania, caching, query caching • Factory for DAO • s využitím Abstract Factory a Factory method • časté zmeny dátového zdroja • každý DAO je schopný pripojiť sa k zdroju a realizovať konkrétne operácie s dátami Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

48. J2EE – DAO záver • BO môže využívať zdroj dát bez nutnosti jeho poznania • implementačné detaily ukryté v DAO • výmena dátových zdrojov • redukuje komplexnosť kódu v BO • centralizácia práce s dátami do jedinej vrstvy • pridáva ďalšiu vrstvu do architektúry Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

49. J2EE – Transfer Object • klientska aplikácia potrebuje vymieňať údaje s enteprise bean (EB) • volanie metódy EB musí prechádzať cez všetky vrstvy siete aj keď sa jedná o jeden stroj, jednu JVM • časté používanie takýchto metód môže znamenať značné spomalenie systému pre potrebný network overhead Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk

50. J2EE – TO dôvody • každé volanie metódy je potenciálne volanie vzdialenej metódy so sieťovým oneskorením • väčšia frekvencia čítania údajov ako zmeny údajov • klienti vyžadujú aj jednoduché údaje viac krát • časté čítanie údajov zvyšuje komunikáciu klient – server a zaťažuje sieť Ing. Jaroslav Jakubík, FIIT STU Bratislava, jakubik@fiit.stuba.sk