N ÁVRHOVÉ VZORY

1

NÁVRHOVÉ VZORYIng. Jaroslav Jakubík

[email protected]\~jakubik

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


AGENDA (2/3)

• structural patterns– composite– facade

• behavioral patterns– chain of responsibility– state

• j2ee core patterns– data access object– transfer object


AGENDA (3/3)

– business delegate

• software reengineering process s podporou Rational Rose– data modeling reengineering– OO reengineering


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


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


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


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


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


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


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


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


AF - štruktúraAbstractFactory

ConcreteFactory1 ConcreteFactory2

Client

ProductA

ProductB

ProductA1 ProductA2

ProductB1 ProductB2

creates

creates

1

uses

uses

uses


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


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


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


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


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


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


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


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


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


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


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


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


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


C - štruktúra

AbstractComponent

operation( )

ConcreteComponent1

operation( )

ConcreteComponent2

operation( )

AbstractComposite

operation( )add(AbstractComponent)remove(AbstractComonent)getChild(int)

...

Client


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ť


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ť


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


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


F - štruktúra

Class1Class3

Class4 Class5

Class6 Class7

Facade

«uses» «refines»

Client

«uses»


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é


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


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 .


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


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


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


STATE

• výdajný automat

• v závislosti na zásobách, inkasovanej sumy, sumy v depozite sa automat nachádza v rôznych stavoch


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


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

...


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í)


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/


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


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


J2EE – DAO štruktúra

• DAO predstavuje adaptér medzi BO a dátovým zdrojom

BusinessObject DataAccessObject DataSourceencapsulate

TransferObject

uses

modifies

creates/uses


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


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


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


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ť


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


J2EE – TO štruktúra

•vytváranie TO je realizované On Demand

Client EnterpriseBean

BusinessSession BusinessEntity DataAccessObject

TransferObject

creates


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


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ť


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


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


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


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


J2EE – BD štruktúra

• BD môže pre lokalizáciu business služieb využívať LookupService

Client BusinessDelegate BusinessService

LookupService

uses

lookup / create


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


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


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

http://www.math.utsa.edu/sphere/salingar/Chris.text.html

http://www.mindspring.com/~mgrand/pattern_synopses.htm


Ďakujem za pozornosť

N ÁVRHOVÉ VZORY

Documents

Transcript of N ÁVRHOVÉ VZORY