Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 5
Ch. Alexander
A Pattern Language, Towns, Buildings, Construction.
1977
HISTÓRIA VZOROV
J. Coplien, D. SchmidtPattern Languages of Program Design. 1995
E. Gamma, R. Helm, R. Johnson, J. Vlissides Design patterns. 1995
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 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
California at 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 13
AF - štruktúraAbstractFactory
ConcreteFactory1 ConcreteFactory2
Client
ProductA
ProductB
ProductA1 ProductA2
ProductB1 ProductB2
creates
creates
1
uses
uses
uses
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 18
B - štruktúra
AbstractBuilder
getInstance( ):AbstractBuilderbuildPart1( )buildPart2( )...getProduct( ):ProductIF
uses
ConcreteBuilder
buildPart1( )buildPart2( )...getProduct( ):ProductIF
Director
Build(:Builder):ProductIF
Client
1
Productcreates
«interface»ProoductIF
uses
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 27
C - štruktúra
AbstractComponent
operation( )
ConcreteComponent1
operation( )
ConcreteComponent2
operation( )
AbstractComposite
operation( )add(AbstractComponent)remove(AbstractComonent)getChild(int)
...
Client
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 32
F - štruktúra
Class1Class3
Class4 Class5
Class6 Class7
Facade
«uses» «refines»
Client
«uses»
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 37
CHoR - štruktúra
CommandHandler
postCommand( )handleCommand( ):boolean
Send-command
CommandSender
1
1
1
1
predecessor
successor
ConcreteCommandHandler1
handleCommand( ):boolean
ConcreteCommandHandler2
handleCommand( ):boolean
sender
receiver
Send-command-to-next-handler-in-chain
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 41
S – štruktúra
Context
-currentState : State
...
ContextState
+event1 : int = 1 {frozen}+event2 : int = 2 {frozen}...#state1 : ConcreteState1#state2 : ConcreteState2...
+operation1( )+operation2( )...#enter( )+start( ) : State+processEvent(event:int) : State
uses
ConcreteState2
+operation1( )+operation2( )...processEvent(even t: int) : State
ConcreteState1
+operation1( )+operation2( )...processEvent(even t: int) : State
...
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 46
J2EE – DAO štruktúra
• DAO predstavuje adaptér medzi BO a dátovým zdrojom
BusinessObject DataAccessObject DataSourceencapsulate
TransferObject
uses
modifies
creates/uses
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 51
J2EE – TO riešenie
• alternatíva– odstránenie sieťového oneskorenia s
využitím priameho prístupu
• ak klient požiada EB o business dáta, EB vytvorí TO, naplní TO a pošle TO klientovi
• klient získava všetky hodnoty volaním jedinej metódy
• realizácia TO– get na každý atribút– public atribúty
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 52
J2EE – TO štruktúra
•vytváranie TO je realizované On Demand
Client EnterpriseBean
BusinessSession BusinessEntity DataAccessObject
TransferObject
creates
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 53
J2EE – TO prístupy (1/2)
• Updateable Transfer Object– TO umožňuje aj zmeniť stav– obsahuje sadu set a get metód– merge metóda pre zistenie, ktoré z atribútov
sa premietnu do dátových objektov
• Multiple Transfer Object– ak jeden BO vytvára niekoľko TO– BO ako Session Bean komunikuje s
viacerými BO a poskytuje ich služby– BO ako Entity Bean poskytuje TO z viacerých
zdrojov
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 54
J2EE – TO prístupy (2/2)
• Entity Inherits TO– BO implementovaný ako entity bean– 1:1 (entity bean : TO)– TO má prístup ku všetkým atribútom BO– eliminuje duplikáciu kódu v BO a TO
• TO Factory– rozširuje Entity Inherits TO o podporu
viacerých TO– ľahké udržiavanie, rozširovanie a znížená
chybovosť
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 55
J2EE – TO záver
• jednoduchšie BO (entity beans)
• väčšie množstvo prenesených dát na menší počet vzdialených volaní
• redukuje network trafic ???
• niektoré z implementácií redukujú opakovanie kódu
• ak povolíme aj zmenu TO je potrebné riešiť viacnásobný prístup, transakcie a vzájomné vylučovanie
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 56
J2EE – Business Delegate
• prezentačná vrstva potrebuje prístup k business službám
• rôzny klienti vyžadujú prístup k business službám
• business API sa môže meniť podľa vyvíjajúcich sa požiadaviek
• klienti môžu vyžadovať implementáciu cache
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 57
J2EE – BD alternatíva
• prezentačná vrstva interaguje priamo s business službami
• odhaľuje implementáciu business služieb
• zraniteľné komponenty v prípade zmeny business služieb
• zahltenie siete pre častú komunikáciu prezentačnej vrstvy s API business služieb
• žiaden client-side caching
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 58
J2EE – BD riešenie
• zredukujeme komunikáciu medzi vrstvami• skryjeme implementačné detaily business
vrstvy• BD predstavuje klientsku abstrakciu
business služieb• BD oddeľuje prezentačnú vrstvu od
implementačnej nestálosti business vrstvy
• BD zachytáva business exception a transformuje ich na gui exception
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 59
J2EE – BD štruktúra
• BD môže pre lokalizáciu business služieb využívať LookupService
Client BusinessDelegate BusinessService
LookupService
uses
lookup / create
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 60
J2EE – BD prístupy
• Delegate Proxy– BD vyjadruje rozhranie, ktoré klientovi
sprístupňuje podstatné metódy Business API
• Delegate Adapter– optimalizovaný pre B2B (business to
business)– pre služby založené na J2EE
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 61
J2EE – BD záver
• redukuje spojenie medzi prezentačnou vrstvou a business vrstvou
• zvyšuje odolnosť voči zmenám
• prekladá Business Service Exceptions
• umožňuje implementáciu cache čím zvyšuje výkon
• pridáva do aplikácie ďalšiu vrstvu medzi klienta a službu čím zvyšuje komplexnosť a znižuje flexibilitu aplikácie
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 62
ZDROJE
• Návrh programu pomoci vzoru
• Core J2EE Patterns: Best Practices and Design Strategies
• Non sofware examples of Sofware Design Patterns.
• http://www.math.utsa.edu/sphere/salingar/Chris.text.html• http://www.mindspring.com/~mgrand/pattern_synopses.htm
• UML diagramy vytvorené v MS VISIO 2003
Ing. Jaroslav Jakubík, FIIT STU Bratislava, [email protected] 63
Ďakujem za pozornosť
Top Related