curs cts design patterns v2

8/16/2019 Curs CTS Design Patterns v2

1/126

Design patterns

Conf. univ. dr. Cata

catalin.boja@ie


2/126

Calitate cod sursă

Principii urmărite în scrierea codului:• Ușor de citit/înțeles – clar

• Ușor de modificat – structurat

• Ușor de reutilizat

• Simplu (complexitate)

• Ușor de testat

• Implementează pattern-uri pentruproblem standard

Left: Simply Explained: Code

03.By Oliver Widder, Webcomacs.ase.ro [email protected]

http://geekandpoke.typepad.com/geekandpoke/2009/12/simply-explained.htmlhttp://geekandpoke.typepad.com/geekandpoke/2009/12/simply-explained.html


3/126

Calitate cod sursă

Forte care o influențează:• Timpul disponibil (termene de predare)

• Costuri

• Experiența programatorului

• Competențele programatorului

• Claritate specificații

• Complexitate soluție

• Rata schimbări in specificații, cerințe, echipa, etc

http://khrist

acs.ase.ro [email protected]

http://khristianmcfadyen.com/http://khristianmcfadyen.com/


4/126

Anti-Pattern: Big ball of mud

“A Big Ball of Mud is ahaphazardly structured,

sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-

code jungle.”

Brian Foote and Joseph Yoder, Big Ball of Mud,September 1997



5/126


De unde ? De ce ?• Throwaway code – solutii

temporare (Prototyping) ce trebuieinlocuite/rescrise

• Cut and Paste code -

• Adaptarea prin comentare/stergerea unor alte solutii

• Deadline-uri foarte scurte saunerealiste

• Lipsa de experienta

• Lipsa unor standard/proceduri



6/126


Cum eviti ?• Rescrierea codului (Refactoring)

pana la un nivel acceptabil dematuritate

• Utilizare Principii Clean Code

• Implementare Design Patterns



7/126

Design-pattern

•

Un pattern reprezintă o soluțiereutilizabila pentru o problemastandard , intr-un anumit context

• Facilitează reutilizareaarhitecturilor si a design-uluisoftware

• NU sunt structuri de date



8/126

Design-pattern

“ A pattern involves a generaldescription of a recurring solutionto a recurring problem withvarious goals and constraints. It

identify more than a solution, italso explains why the solution is

needed .“ (James Coplien)

“... describes a problem woccurs over and over agaenvironment, and then dthe core of the solution t

problem, in such a way tcan use this solution a m

times over, without everthe same way twice” (CrAlexander)



9/126

Avantajele unui Design-Pattern

•

Permit reutilizarea solutiilor standard la nivel de cod sursa/a• Permit documentarea codului sursa/arhitecturilor

• Permit intelegerea mai facila a codului sursa/a arhitecturii

• Reprezinta concepte universal cunoscute - definesc un vocacomun

• Sunt solutii testate si foarte bine documentate



10/126

Design-Pattern in Arhitecturi Software

Enterprise• OO ArchitectureSystem

• SubsystemApplication

• FrameworksMacro

• Design-PatternsMicro

• OOPObjects



11/126

Componentele unui Design-Pattern

• Nume:• Face parte din vocabularul unui programator/designer/arhitect software• Identifica in mod unic pattern-ul

• Problema:• Descrie scopul urmărit• Definește contextul• Stabilește când este aplicabil pattern-ul

•Soluție

• Diagrama UML, pseudo-cod ce descrie elementele

• Consecințe• Rezultate• Avantaje si dezavantaje

Nume

Solutie



12/126

Istoric Design-Pattern

•

1970 – primele modele legate de conceptual de Window si (Smalltalk, Xerox Parc, Palo Alto)

• 1978 – MVC pattern (Goldberg and Reenskaug, Smalltalk, Xe

• 1987 - Kent Beck and Ward Cunningham, “Using Pattern Lanfor Object-Oriented Programs”, OOPSLA-87 Workshop

• 1991 - Erich Gamma, an idea for a Ph.D. thesis about patter• 1993 - E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design P

Abstraction and Reuse of Object-Oriented Design. ECOOP 97707, Springer, 1993



13/126

Istoric Design-Pattern

Erich Gamma, Richard Helm,Ralph Johnson & John Vlissides(Addison-Wesley, 1995) - DesignPatterns

• The Gang of Four (GOF)

•

Cartea descrie 23 pattern-uri –probleme si soluții ce pot fiaplicate in numeroase scenarii

• Cea mai populara carte deComputer Software



14/126

Utilizare Design-Patterns

•

Observer in Java AWT si Swing pentru callback-uri• Iterator in C++ STL si Java Collections

• Façade in multe librarii Open-Source pentru a ascunde comrutinelor interne

• Bridge si Proxy in framework-uri pentru aplicatii distribuite

• Singleton in Hybernate si NHybernate



15/126

Tipuri de Design-Pattern

•

Creaționale• Inițializarea si configurarea claselor si obiectelor

• Structurale

• Compoziția claselor si obiectelor

• Decuplarea interfețelor si a claselor

•

Comportamentale• Distribuția responsabilității

• Interacțiunea intre clase si obiecte

Creaționale

Comportamen



16/126

Tipuri de Design-Pattern

Creaționale

• Factory Method

• Abstract Factory

• Builder

• Prototype• Singleton

Structurale

• Adapter

• Bridge

• Composite

• Decorator• Façade

• Flyweight

• Proxy

Comportame

• Interpreter

• Chain of Respons

• Command

• Iterator

• Mediator• Memento

• Observer

• State

• Strategy

• Visitor

• Template



17/126

Creational Design-Patterns

• Abstract Factory• Pattern pentru crearea de obiecte aflate intr-un anumit context

• Builder• Pattern pentru crearea in mod structurat (incremental) de obiecte comp

• Factory Method• Pattern ce defineste o metoda pentru crearea de obiecte din aceeasi fam

(interfata) in subclase

• Prototype• Pattern pentru clonarea unor noi instante (clone) ale unui prototip exist

• Singleton• Pattern pentru crearea unei singure instante (unica)



18/126

Structural Design-Patterns

• Adapter:

• Adaptează interfața unui server/serviciu la client• Bridge:

• Decuplează modelul abstract de implementare

• Composite:

• Agregarea a mai multor obiecte similare

• Decorator:

• Extinde intr-un mod transparent un obiect

• Facade:

• Simplifica interfața unui modul/subsistem

• Flyweight:

• Partajare memorie intre obiecte similare.

• Proxy:

• Interfață către alte obiecte/resurse



19/126

Behavioral Design-Patterns

• Chain of Responsibility:

• Gestioneaza tratarea unui eveniment de catre mai multi furnizori de solutii

• Command:

• Request or Action is first-class object, hence re-storable

• Iterator:

• Gestioneaza parcurgerea unei colectii de elemente

• Interpreter:

• Intepretor pentru un limbaj cu o gramatica simpla• Mediator:

• Coordoneaza interactiunea dintre mai multi asociati

• Memento:

• Salvazeaza si restaureaza starea unui obiect



20/126

Behavioral Design-Patterns

• Observer:

• Defineste un hadler pentru diferite evenimente

• State:

• Gestioneaza obiecte al caror comportament depinde de starea lor

• Strategy:

• Incapsuleaza diferiti algoritmi

• Template Method:

• Incapsuleaza un algoritm ai carui pasi depend de o clasa derivate• Visitor:

• Descrie metode ce pot fi aplicate pe o structura neomogena



21/126

Creational Design-Patte

Singleton, Abstract Factory, Factory Method, Factory, Builder, Prot


22/126


Modelul SINGLETON


23/126

• Se dorește crearea unei singure instanțe pentru o clasă prfie gestionată o resursă/un eveniment în mod centralizat;

• Soluția se bazează pe existența unei singure instanțe ce pocreata o singură dată dar care poate fi referită de mai mul

• Asigură un singur punct de acces, vizibil global, la unica ins

•Exemple: gestiune conexiune baze de date sau alte resursemecanism de logging unic; manager evenimente; managevizuale; manager configurare.

SINGLETON- Problema



24/126

SINGLETON - Diagrama

public class Singleton {

private static Singleton instance =null;

private Singleton() { }

public static synchronized SingletongetInstance() {

if (instance == null) {instance = new Singleton ();

}

return instance;

}

}



25/126

• Singleton()

• un constructor privat (apelabil doar din clasa)

• private static Singleton instance• un atribut static, privat, de tipul clasei ce reprezinta instanta unica

• Singleton getInstance()

•

o metoda publica ce da acces la instanta unica• instanta unica este creata la primul apel al metodei

SINGLETON - Componente



26/126

Avantaje:

• Gestiune centralizata a unei resurse printr-o instanta unica

• Controlul strict al instantierii unei clase – o singura data

• Nu permite duplicarea instantelor

• Usor de implementat

Dezavantaje:

• In multi-threading pot aparea probleme de sincroniare sau coopsingleton-ul este partajat

• Poate deveni un bottleneck care sa afecteze performanta aplicat

SINGLETON – Avantaje si Dezavantaje



27/126

SINGLETON – Scenarii

• Conexiune unica la baza de date

• Gestiune unica fisiere/fisier de configurare

• Gestiune unica preferinte Android (SharedPreferences)

• Gestiune unica conexiune retea

• Gestiune centralizata a accesului la anumite resurse



28/126


Modelul ABSTRACT FACT


29/126

• Se dorește implementarea unui mecanism prin care creare

obiectelor este transparenta pentru client• Solutia poate sa fie scalata prin adaugarea de noi tipuri co

obiecte fara a afecta codul scris

• Complexitatea crearii obiectelor este ascunsa clientului. Acum sa le creeze insa nu stie cum acestea sunt efectiv crea

• Crearea obiectelor este decuplata de solutie si generatoruinlocuit fara prea mare effort

• Obiectele sunt referite printr-o interfata comuna si nu direformeaza o familie de obiecte in jurul interfetei comune

ABSTRACT FACTORY- Problema



30/126

ABSTRACT FACTORY - Diagrama


http://en.wikipedia

http://en.wikipedia.org/wiki/Abstract_factory_patternhttp://en.wikipedia.org/wiki/Abstract_factory_patternhttp://en.wikipedia.org/wiki/Abstract_factory_pattern


31/126

• AbstractFactory

• interfata ce defineste metodele abstracte pentru crearea de instan

• AbstractProductA/AbstractProductB

• interfete ce definesc tipurile abstracte de obiecte ce pot fi create

• ConcreteFactory1/ConcreteFactory2

• clase concrete ce implementeaza interfata si metodele prin care sobiecte de tipul Product

• ProductA1, ProductA2, ProductB1…

• clase concrete ce defines diferitele tipuri de obiecte ce pot fi creat

ABSTRACT FACTORY - Componente



32/126

Avantaje:

• Decupleaza generatorul de instante de clientul care le utilizeaza• Controlul strict al instantierii – obiectele nu sunt create direct prin con

prin metodele de tip factory

• Diferitele tipuri de obiecte sunt gestionate unitar prin interfata comuntipuri pot fi adaugate fara modificari


Dezavantaje:

• In multi-threading pot aparea probleme de sincroniare sau cooperaresingleton-ul este partajat

• Poate deveni un bottleneck care sa afecteze performanta aplicatiei

ABSTRACT FACTORY – Avantaje si Dezava



33/126

ABSTRACT FACTORY – Scenarii

• Gestiune creare produse catalog magazine virtual

• Gestiune creare tipuri diferite de client

• Gestiune creare tipuri diferite de rapoarte

• Gestiune creare tipuri de numere de telefon

• Gestiune creare tipuri de conturi bancare

• Gestiune creare tipuri de pizza

• Gestiune creare meniuri intr-un restaurant



34/126


Modelul FACTORY METH

Virtual Constructor)


35/126

FACTORY METHOD - Diagrama


http://www.oodes

http://www.oodesign.com/factory-method-pattern.htmlhttp://www.oodesign.com/factory-method-pattern.htmlhttp://www.oodesign.com/factory-method-pattern.html


36/126

• Product

• interfata ce defineste tipurile generice de obiecte ce pot fi create

• ConcreteProduct

• clasa concreta ce defineste tipul de obiecte ce poate fi creat

• Factory

• clasa abstracta ce defineste interfata unui generator de obiecte

• ConcreteFactory

• clasa concreta ce implementeaza generatorul de obiecte

FACTORY METHOD - Componente



37/126

Avantaje:

• Toate obiecte create au in comun interfata• Controlul strict al instantierii – obiectele nu sunt create direct prin con

prin metoda de tip factory

• Diferitele tipuri de obiecte sunt gestionate unitar prin interfata comuntipuri, din aceeasi familie, pot fi adaugate fara modificari


•

Pot fi generate obiecte noi care apartin aceleiasi familii (interfata com

Dezavantaje:

• Nu pot fi generate obiecte “noi”

• Constructorii sunt privati – clasele nu pot fi extinse

FACTORY METHOD – Avantaje si Dezavan



38/126


Modelul FACTORY


39/126

FACTORY - Diagrama


http://www.oodes

http://www.oodesign.com/factory-method-pattern.htmlhttp://www.oodesign.com/factory-method-pattern.htmlhttp://www.oodesign.com/factory-method-pattern.html


40/126

Exemplu de SINGLETON si FACTORY



41/126


Modelul BUILDER

Adaptive Builder)


42/126

• Soluția trebuie sa construiască obiecte complexe

printr-un mecanism care este independent deprocesul de realizare a obiectelor

• Clientul construiește obiectele complexespecificând doar tipul si valoarea sa, fără a cunoaștedetaliile interne ale obiectului (cum stochează sireprezintă valorile)

• Procesul de construire a obiectelor trebuie sa poatăfi utilizat pentru a defini obiecte diferite din aceeași

familie• Obiectele sunt gestionate prin interfața comuna

• Instanța de tip Builder construiește obiectul însătipul acestuia este definit de subclase

BUILDER - Problema



43/126

BUILDER- Diagrama


http://en.wikipedia

http://en.wikipedia.org/wiki/Builder_patternhttp://en.wikipedia.org/wiki/Builder_patternhttp://en.wikipedia.org/wiki/Builder_pattern


44/126

• Builder

• interfața abstracta ce definește metodele prin care sunt construiteobiectului complex

• ConcreteBuilder

• clasa concreta ce construiește părțile si pe baza lor obiectul final

• Product

• clasa abstracta ce definește obiectul complex ce este construit

• Director

• clasa concreta ce construiește obiectul complex utilizând interfațaBuilder

BUILDER - Componente



45/126

Avantaje:

• Obiectele complexe pot fi create independent de părțile carcompun (un obiect poate sa le conțină pe toate sau doar o p

• Sistemul permite reprezentarea diferita a obiectelor create interfață comună

•

Algoritmul de creare a obiectului este flexibil deoarece clience părți sa fie create

Dezavantaje:

• Atenție la crearea de obiecte – pot fi omise atribute

BUILDER - Avantaje si Dezavantaje



46/126


Modelul PROTOTYPE


47/126

• Solutia genereaza obiecte costisitoare (timp creare si mem

ocupata) cu durata de viata lunga

• Pentru eficienta, Solutia reutilizeaza obiectul prin clonarea(se creaza o instant noua a obiectului)

• Implementat printr-o metoda clone()

PROTOTYPE - Problema



48/126

PROTOTYPE - Diagrama


http://en.wikipedia

http://en.wikipedia.org/wiki/Builder_patternhttp://en.wikipedia.org/wiki/Builder_patternhttp://en.wikipedia.org/wiki/Builder_pattern


49/126

Adapter, Facade, Decorator, Composite, Flyweight, Proxy

Structural Design-Patter


50/126


Modelul ADAPTER

Wrapper)

ADAPTER P bl


51/126

• Utilizarea împreună a unor clase ce nu au

o interfață comuna• Clasele nu se modifica însă se

construiește o interfață ce permiteutilizarea lor in alt context

• Clasele sunt adaptate la un nou context

•

Apelurile către interfața clasei suntmascate de interfața adaptorului

• Transformarea datelor dintr-un format înaltul

ADAPTER - Problema


ADAPTER S i


52/126

Claseexitente

Frameworkclient

ADAPTER - Scenariu

Clase existente AdaptorFramework

client

Codul nu se schimbă Codul nu se schimbă


ADAPTER Di


53/126

ADAPTER - Diagrama


ADAPTER C t


54/126

• ClasaExistenta

• clasa existenta ce trebuie adaptata la o noua interfață;

• ClasaContextNou

• definește interfața specifică noului domeniu;

• Adaptor

• adaptează interfața clasei existente la cea a clasei din noul context

• contine (composition) o referinta catre clasa/obiectul ce trebuie a

• Client

• Reprezintă framework-ul care apelează interfața specifică noului d

ADAPTER - Componente


ADAPTER A antaje si De a antaje


55/126

Avantaje:

• Clasele existente (la client si la furnizor) nu sunt modificate putea fi folosite într-un alt context

• Se adaugă doar un layer intermediar

• Pot fi definite cu ușurință adaptoare pentru orice context

Dezavantaje:

Adaptorul de clase se bazează pe derivare multipla, lucru careposibil in Java. Alternativa este prin interfețe si compunere

ADAPTER – Avantaje si Dezavantaje


ADAPTER Scenariu


56/126

ADAPTER – Scenariu

ACME Inc. dorește să cumpere un nou framework p

serviciile din back-end. Interfața pentru aceste servgestionează datele prin intermediul obiectelor de tiar noul framework procesează datele prin intermeobiectelor de tip MICRO. Programatorii companiei sa găsească o soluție de a integra cele doua framew

fără a le modifica.



57/126


Modelul FAÇADE

Wrapper)

FAÇADE Problema


58/126

• Soluția conține o mulțime de clase iar execuția

unei funcții presupune apeluri multiple demetode aflate in aceste clase

• Clasele nu se modifica însă se construiește unlayer intermediar ce permite apelul/gestiuneafacila a metodelor din mai multe interfețe

• Utilă in situația in care framework-ul creste in

complexitate si nu este posibila rescrierea luipentru simplificare

• Apelurile către multiplele interfețe suntmascate de aceasta interfață comună

FAÇADE - Problema


FAÇADE Scenariu


59/126

FAÇADE - Scenariu


FAÇADE Diagrama


60/126

FAÇADE - Diagrama


FAÇADE Componente


61/126

• Clasa1, Clasa2, …, Package1, Package2, …

• clase existente ce pun la dispoziție diferite interfețe;

• Facade

• Definește o interfața simplificata pentru contextul existent;

• Client

• Reprezintă framework-ul care apelează interfața specifica noului d

FAÇADE - Componente


FAÇADE - Avantaje si Dezavantaje


62/126

Avantaje:

•

Framework-ul nu se rescrie• Se adaugă doar un layer intermediar ce ascunde complexitatea frame

din spate

• Pot fi definite cu ușurință metode care sa simplifice orice situație

• Implementează principiul Least Knowledge – reducerea interacțiuniloobiect la nivel de “prieteni apropriați”

Dezavantaje:

• Creste numărul de clase wrapper

• Creste complexitatea codului prin ascunderea unor metode

• Impact negativ asupra performantei aplicației

FAÇADE - Avantaje si Dezavantaje


FAÇADE - Scenariu


63/126

FAÇADE Scenariu

ACME Inc. dezvoltă o soluție software pentru managemen

locuințe inteligente. Includerea în framework a tuturorcomponentelor controlabile dintr-o astfel de locuință (fere

încălzire, alarma, etc) a generat un număr mare de clase.Departamentul care dezvolta interfața Web a soluției oferăminim de funcții ce pot fi controlate de la distanta. Deșifuncționalitatea este simpla, numărul mare de clase ce se

instanțiază si a metodelor apelate îngreunează dezvoltareatestarea. In acest sens, o interfață mai simpla ar ajuta acesdepartament.



64/126


Modelul DECORATOR

Wrapper)

DECORATOR - Problema


65/126

• Extinderea (decorarea) statica sau la run-time a

funcționalității unor obiecte, independent dealte instanțe ale aceleiași clase

• Obiectul poate sa fie extins prin aplicarea maimultor decoratori

• Clasa existenta nu trebuie sa fie modificata

• Utilizarea unei abordări tradiționale, prinderivarea clasei, duce la ierarhii complexe cesunt greu de gestionat. Derivarea adaugăcomportament nou doar la compilare

DECORATOR Problema


DECORATOR - Diagrama


66/126

DECORATOR Diagrama


DECORATOR - Componente


67/126

• AbstractProduct•

clasa abstracta ce definește interfața obiectelor ce pot fi decorate cu no• ConcreteProduct

• definește obiecte ce pot fi decorate;

• Decorator• gestionează o referința de tip AbstractProduct către obiectul decorat;

• metodele moștenite din AbstractProduct apelează implementările speci

obiectului referit;• Poate defini o interfață comună claselor decorator;

• ConcreteDecorator• Adaugă funcții noi obiectului referit;

DECORATOR Componente


DECORATOR - Avantaje


68/126

• Extinderea funcționalității a unui obiect particular se face di

run-time• Decorarea este transparenta pentru utilizator deoarece clas

moștenește interfața specifica obiectului

• Decorarea se face pe mai multe niveluri, însă transparent peutilizator

• Nu impune limite privind un număr maxim de decorări

DECORATOR Avantaje


DECORATOR - Dezavantaje


69/126

• Un decorator este un wrapper pentru obiectul inițial. El nu e

identic cu obiectul încapsulat• Utilizarea excesiva generează o mulțime de obiecte care ara

dar care se comporta diferit –> dificil de înțeles si verificat c

• Situația trebuie analizata cu atenție deoarece in unele situațul Strategy este mai indicat

DECORATOR Dezavantaje



70/126


Modelul COMPOSITE

COMPOSITE - Problema


71/126

• Soluția conține o mulțime de clase aflate in relație ierarhică

tratate unitar• Se construiesc structuri arborescente în care nodurile interm

cele frunză sunt tratate unitar


COMPOSITE - Scenariu


72/126

Meniuri

Meniubăuturi

Non-alcoolice

Alcoolice

Meniuaperitive

Meniusupe

Supă de roșii

Supă


COMPOSITE - Diagrama


73/126

g


COMPOSITE - Componente


74/126

• Componenta

•

conține descrierea abstractă a tuturor componentelor din ierarhie• Descrie interfața obiectelor aflate in compoziție

• NodFrunza

• Reprezintă nodurile frunza din compoziție

• Implementează toate metodele

• Composite

• Reprezintă o componentă compusa – are noduri fiu

• Implementează metode prin care sunt gestionate nodurile fiu

p


COMPOSITE - Avantaje


75/126

• Framework-ul nu se rescrie

• Permite gestiunea facila a unor ierarhii de clase ce conțin atprimitive cat si obiecte compuse

• Codul devine mai simplu deoarece obiectele din ierarhie sununitar

• Adăugarea de noi componente care respecta interfața comu

ridica probleme suplimentare

j


COMPOSITE - Scenariu


76/126

ACME Inc. dezvoltă o soluție software pentru managemen

resurselor umane dintr-o companie. Soluția trebuie să ofemecanism unitar care să centralizeze angajații companiei șțină cont de:

• relațiile ierarhice

• apartenența angajaților la un departament

•

rolurile diferite ale angajaților• setul comun de funcții pe care un angajat le poate îndep



77/126

Modele structurale

Modelul FLYWEIGHT

FLYWEIGHT - Problema


78/126

• Soluția generează o mulțime de obiecte cu ostructura interna complexa si care ocupa unvolum mare de memorie

• Obiectele au atribute comune însă o parte dinstarea lor variază; memoria ocupata de elepoate fi minimizata prin partajarea stării fixeintre ele

• Starea obiectelor poate fi gestionat prinstructuri externe iar numărul de obiecte efectivcreate poate fi minimizat

• Utilizarea unui obiect înseamnă reîncărcareastării lui variabile într-un obiect existent


Attack

FLYWEIGHT - Scenariu


79/126


FLYWEIGHT - Diagrama


80/126


FLYWEIGHT - Componente


81/126

• Flyweight• Interfață ce permite obiectelor să primească valori ce fac parte din stare

facă diferite procesări pe baza acesteia;• Flyweight Factory

• Un pattern de tip factory ce construiește si gestionează obiecte de tip fly• Menține o colecție de obiecte diferite astfel încât ele sa fie create o sing

• Concrete Flyweight• Clasa implementează interfața de tip Flyweight si permite stocarea stări

(ce nu poate fi partajat) a obiectelor• Valori ce reprezintă o stare temporara partajata între obiecte sunt primit

procesate prin intermediul metodelor din interfață

• Client• Gestionează obiectele de tip flyweight si starea lor temporara


FLYWEIGHT - Avantaje si Dezavantaje


82/126

Avantaje:

• Se reduce memoria ocupata de obiecte prin partajarea lor intre a stării lor intre obiecte de același tip

• Pentru a gestiona corect partajarea obiectelor de tip Flyweight înși fire de execuție, acestea trebuie sa immutable

Dezavantaje:

• Trebuie analizate clasele si contextul pentru a se determina ce restare variabilă ce poate fi internalizată

• Efectele sunt vizibile pentru soluții in care numărul de obiecte es

• Nivelul de memorie redusa depinde de numărul de categorii de otip Flyweight


FLYWEIGHT – Scenariu problemă


83/126

ACME Inc. dezvolta un editor de texte ca soluție altern

soluțiile cunoscute. In faza de testare s-a observat ca pmăsura ce crește dimensiunea textului, crește și memocupată de această aplicația. Ritmul de creștere este uanormal, destul de rapid , iar in final generează întârzmomentul tastării unui caracter si cel al afișării. Teste

aceasta zona au arătat ca exista o legătura între număcaractere tastate si numărul de obiecte.


FLYWEIGHT - Șabloane asemănătoare


84/126

• Adapter – modifica interfața obiectului

• Decorator – adaugă dinamic funcții noi la comportamentul o

• Façade – asigura o interfață simplificata



85/126


Modelul PROXY

PROXY - Problema


86/126

• Interconectarea de API-uri diferite aflate pe aceeași mașină

rețea• Definirea unei interfețe între framework-uri diferite


PROXY - Diagrama


87/126


PROXY - COMPONENTE


88/126

• Subject

•

Definește interfața obiectului real la care se face conectarea• Interfața este implementata si de proxy astfel încât să se poată con

obiecte

• Proxy

• Gestionează referința către obiectul real

• Implementează interfața obiectului real

• Controlează accesul la obiectul real

• RealSubject

• Obiectul real către care proxy-ul are legătura


PROXY - Tipuri de PROXY


89/126

• Virtual Proxies: gestionează crearea si inițializarea unor obiecostisitoare; acestea pot fi create doar atunci când e nevoiepartajează o singura instanță intre mai mulți client;

• Remote Proxies: asigura o instanță virtuala locala pentru unaflat la distanta – Java RMI.

• Protection Proxies: controlează accesul la metodele unui ob

anumite obiecte.• Smart References: gestionează referințele către un obiect


Șabloane asemănătoare


90/126

• Adapter – modifică interfața obiectului

• Decorator – adaugă dinamic funcții noi la comportamobiectului

• Strategy (Behavioral) – modifică comportamentul o

• Façade – asigura o interfață simplificată

• Composite – agregă mai multe obiecte asemănătoaro gestiune unitară



91/126

Strategy, Observer, Chain of Responsability, Template, State, Com

Iterator , Memento

Behavioral Design-Patte


92/126

Modele comportamentale

Modelul STRATEGY

STRATEGY - Problema


93/126

• Alegerea la run-time a algoritmului/funcțieicare sa fie utilizata pentru procesarea unor

date;• Algoritmul se poate alege pe baza unor

condiții descrise la execuție in funcție decontextul datelor de intrare

• Clasa existenta nu trebuie sa fie modificata

• Utilizarea unei abordări tradiționale, prinincluderea in clasa a tuturor metodelorposibile, duce la ierarhii complexe ce sunt greude gestionat. Derivarea adaugă comportamentnou doar la compilare

STRATEGY - Diagrama


94/126

STRATEGY - Componente


95/126

• IStrategy

• clasa abstracta ce definește interfața obiectelor ce pot oferi noifuncții/algoritmi de prelucrare;

• StrategyA

• definește obiecte ce furnizează soluții pentru prelucrarea datelor;

• Obiect

• gestionează o referința de tip IStrategy către obiectul care va oferfuncția/algoritmul;

• Gestionează datele/contextual ce necesită prelucrare;

STRATEGY - Avantaje


96/126

• Alegerea metodei de prelucrare a datelor se face dinamic, la

•

Este permisa definirea de noi algoritmi independent de modclasei ce gestioneaza datele

• Nu impune limite privind un numar maxim de functii/algoritfi folositi


97/126


Modelul OBSERVER

OBSERVER


98/126


http://umlcomics.blogspot.ro/2010/03/world-of-twist

OBSERVER - Problema

http://umlcomics.blogspot.ro/2010/03/world-of-twisted-design-patterns.htmlhttp://umlcomics.blogspot.ro/2010/03/world-of-twisted-design-patterns.htmlhttp://umlcomics.blogspot.ro/2010/03/world-of-twisted-design-patterns.html


99/126

• Exista componente care trebuie sa fie notificate la producereveniment

• Gestiunea evenimentelor la nivel de interfață

• Componentele se abonează/înregistrează la acel evenimentmodificare de stare/acțiune

• La producerea unui eveniment pot fi notificate mai multe

componente


100/126

OBSERVER - Diagrama


101/126

OBSERVER - Componente


102/126

• Observabil

• clasa abstracta ce definește interfața obiectelor gestionează evenicare sunt observabile;

• ObservabilConcret

• definește obiecte ce permit abonarea unor observatori;

• Observator

• Interfață ce definește modalitatea in care sunt notificați observato

• Permite gestiunea mai multor observatori

• ConcreteDecorator

• Implementează funcții concrete care sunt executate in urma notifi

OBSERVER - Metode de comunicare


103/126

2 modele de notificare a observatorului la modificarea stării:

•

Push – obiectul trimite toate detaliile observatorului• Pull – obiectul doar notifică observatorul și acesta cere date

are nevoie de ele


104/126


Modelul CHAIN OF

RESPONSABILITY

CHAIN OF RESPONSABILITY - Problema


105/126

• Tratarea unui eveniment sau a unui obiectse face diferit in funcție de starea acestuia

• Gestiunea tuturor cazurilor ar implica ostructură complexă care să verifice toatecazurile particulare

• Există legături de dependență între cazurilede utilizare: execuția unui caz poate implicaignorarea celorlalte sau tratareaurmătorului caz


http://www.leah

CHAIN OF RESPONSABILITY - Diagrama

http://www.leahy.com.au/http://www.leahy.com.au/


106/126

CHAIN OF RESPONSABILITY - Componen


107/126

• Handler

• clasa abstracta ce definește interfața obiectelor ce gestionează cer

procesare a evenimentului;

• HandlerA

• definește obiecte concrete ce formează secvența de tratare a notif

• Client

• Generează evenimentul sau notifica primul obiect din secvența de


108/126


Modelul STATE

STATE - Problema


109/126

• Aplicația tratează un anumit eveniment diferit înfuncție de starea unui obiect

• Numărul de stări posibile poate să crească șitratarea unitară a acestora poate să influențezecomplexitatea soluției

• Modul de tratare a acțiunii este asociat uneianumite stări și este încapsulat într-un obiect destare


STATE - Diagrama


110/126

http://en.wikipedia.org/wiki/State_pattern

STATE - Componente

http://en.wikipedia.org/wiki/State_patternhttp://en.wikipedia.org/wiki/State_pattern


111/126

• Handler

• clasa abstracta ce definește interfața obiectelor ce gestionează cer

procesare a evenimentului;

• HandlerA

• definește obiecte concrete ce formează secvența de tratare a notif

• Client

• Generează evenimentul sau notifica primul obiect din secvența de


112/126


Modelul COMMAND

COMMAND - Problema

• Aplicația definește acțiuni parametrizabile ce pot fi


113/126

• Aplicația definește acțiuni parametrizabile ce pot fiexecutate mai târziu fără a solicita clientuluicunoașterea detaliile interne necesare execuției.

• Pentru a nu bloca clientul, se dorește ca aceste acțiunisă fie definite și trimise spre execuție fără a mai figestionate de client

• Se decuplează execuția întârziată (ulterioara) a uneiacțiuni de proprietar. Din punctul acestuia de vedere,acțiunea a fost deja trimisa spre execuție.

• Concept echivalent cu macro-urile. Obiectul de tipcommand încapsulează toate informațiile necesareexecuției acțiunii mai târziu de către responsabil

• Clientul este decuplat de cel ce executa acțiunea


COMMAND - Diagrama


114/126

http://www.oodesign.com/command-pattern.html

http://www.oodesign.com/command-pattern.htmlhttp://www.oodesign.com/command-pattern.htmlhttp://www.oodesign.com/command-pattern.html


115/126

COMMAND - Scenariu

ACME I d lt l ți ft t t t


116/126

ACME Inc. dezvolta o soluție software pentru un restaurant, achelnerul să poată prelua comenzile direct pe telefonul mobil

Comenzile sunt preluate de la client și ele sunt create pe loc, automat alocat bucătarul specializat pe acel fel de mâncare,ingredientele folosite si alte cerințe speciale ale clientului. Acedetalii sunt puse de aplicație, fără a fi necesara intervenția chcare doar selectează felul de mâncare solicitat. Comenzile sun

bucătarilor la finalizarea comenzii pentru masa respectiva, urfie executate in funcție de gradul de încărcare al fiecărui bucă



117/126


Modelul TEMPLATE METH

• Implementarea unui algoritm presupune o

TEMPLATE METHOD - Problema


118/126

• Implementarea unui algoritm presupune osecvență predefinita si fixa de pași

• Metoda ce definește schema algoritmului –metoda template

• Pot fi extinse/modificate metodele careimplementează fiecare pas însă schemaalgoritmului nu este modificabilă

• Implementează principiul Hollywood: "Don't call

us, we'll call you.“• Metodele concrete de definesc pașii algoritmului

sunt apelate de metoda template

TEMPLATE METHOD - Diagrama


119/126

http://www.oodesign.com/template-method-pattern.html

TEMPLATE - Componente

• Trip

http://www.oodesign.com/template-method-pattern.htmlhttp://www.oodesign.com/template-method-pattern.html


120/126

• Trip

• Clasa abstracta ce definește interfața unui obiect de tip Trip si mod

care sunt executate metodele• Conține o metod template ce implementează șablonul de execuție

si care nu se supradefinește

• PackageA

• Definește interfața obiectului într-o situație concretă

• PackageB• Definește interfața obiectului într-o situație concretă



121/126


Modelul MEMENTO

MEMENTO - Problema

• Aplicația trebuie sa permită salvarea stării unui


122/126

Aplicația trebuie sa permită salvarea stării unuiobiect

• Imaginile stării obiectului pentru diferitemomente sunt gestionate separat

• Obiectul își poate restaura starea pe baza uneiimagini anterioare


MEMENTO - Diagrama


123/126

http://www.oodesign.com/memento-pattern.html

• Memento

MEMENTO - Componente

http://www.oodesign.com/memento-pattern.htmlhttp://www.oodesign.com/memento-pattern.htmlhttp://www.oodesign.com/memento-pattern.html


124/126

Memento

• Gestionează starea interna a obiectului Originator pentru un anum

Este creat de Originator si este gestionat de Caretaker

• Originator

• Obiectul a cărui stare este urmărita; Poate genera un Memento cumomentul respective. Poate sa își reface starea pe baza unui Mem

• Caretaker

• Gestionează obiectele de tip Memento fără a avea acces pe conținacestora;


125/126

Recapitulare

• Comportamentale:


126/126

Comportamentale:

• Strategy – schimba la run-time funcția executată

• Observer – execută o acțiune când are loc un eveniment sau un obschimba starea

• Chain of Responsibility – gestionează o secvență de acțiuni ce pot eveniment sau un obiect

• Command – gestionează realizarea întârziată a unei acțiuni

• Memento – gestionează stările anterioare ale unui obiect

• State – stabilește tipul acțiunii în funcție de starea obiectului

• Template – gestionează un șablon fix de acțiuni


curs cts design patterns v2

Documents