Pub.ro



Universitatea POLITEHNICA din Bucureşti

Facultatea de Electronică, Telecomunicaţii şi Tehnologia Informaţiei

Design Patterns

Bran Andrei Costin

Pantazica Alexandru

Grupa 441A

Coordonator științific:

Conf. Dr. Ing. Ștefan Stăncescu

Anul universitar

2015-2016

Cuprins

1. Introducere (Bran Andrei)

2. Modele de design creationale (Bran Andrei)

1. Abstract Factory

2. Builder

3. Factory Method

4. Object Pool

5. Prototype

6. Singleton

3. Modele de design structurale (Bran Andrei)

1. Adapter

2. Bridge

3. Composite

4. Decorator

5. Facade

6. Flyweight

7. Private Class Data

8. Proxy

4. Modele de design comportamentale (Pantazica Alexandru)

1. Chain of responsibility

2. Command

3. Interpreter

4. Iterator

5. Mediator

6. Memento

7. Null Object

8. Observer

9. State

10. Strategy

11. Template method

12. Visitor

5. Bibliografie

1. Introducere

In ingineria software, un model de design este o solutie repetabila generala pentru o problema frecventa in proiectarea software-ului. Un model de design nu este un design finit care poate fi transpus direct in cod. Este un sablon pentru modul de a rezolva o problema care poate fi folosit in multe situatii diferite.

Modele de design pot accelera procesul de dezvoltare prin furnizarea unor paradigme de dezvoltare testate. Proiectarea efectiva a software-ului necesita considerarea unor probleme care nu devin vizibila pana tarziu in implementare. Reutilizarea modelelor de design ajuta la prevenirea problemelor subtile care mai tarziu pot deveni majore si imbunatatesc lizibilitatea codului pentru programatori si arhitecti familiari cu astfel de modele.

De multe ori, oamenii inteleg cum sa aplice anumite tehnici de proiectare. Aceste tehnici sunt dificil de aplicat la o gama mai larga de probleme. Modelele de design ofera solutii generale, documentate intr-un format care nu are nevoie de detalii legate de o problema particulara.

In plus, modelele permite dezvoltatorilor sa comunice folosind nume bine-cunoscute si intelese pentru interactiunile software. Modelele de design des folosite pot fi imbunatatite in timp, ceea ce le face mai robuste decat design-urile ad-hoc.

Modele de design au fost initial grupate in urmatoarele categorii:

- Modele creationale

- Modele structurale

- Modele comportamentale

2. Modele de design creationale

In ingineria software, modelele de design creationale sunt modele de design care se ocupa cu mecanismele de creare a obiectelor, incercand sa creeze obiecte intr-un mod adecvat fiecarei situatii. Forma de baza a crearii de obiecte ar putea duce la probleme de design sau in createrea complexitatii design-ului.

Aceste modele sunt compuse din doua idei dominante. Una dintre ele este despre incapsularea cunostintelor despre clasele concret folosite de sistem. Cealalta este ascuderea modului in care instante ale acestor clase sunt create si combinate.

Modelele creationale au scopul de a separa modul in care obiectele sunt create, compuse si reprezentate, crescand flexibilitatea sistemului. Aceste model devin importante in timp ce sistemul evolueaza pentru a creste dependenta de compozitia obiectului, in loc de clasa mostenita.

1. Abstract Factory

Scop:

- Furnizeaza o interfata pentru crearea familiilor de obiecte similare sau dependente, fara a preciza clasele lor concrete

- Creaza o ierarhie care incapsuleaza multe posibile platforme si constructia unei suite de produse

- Operator “new” este considerat daunator

Problema:

- O aplicatie care se doreste sa fie portabila trebuie sa encapsuleze dependentele de platforma. Aceste platforme pot include: sistem de ferestre, sistem de operare, baza de date, etc. De multe ori, acest lucru nu este proiectat in avans, iar o multime de declaratii #ifdef cu optiuni pentru toate platformele suportate in prezent incep sa apara in cod de foarte multe ori.

Diagrama UML:

[pic]

Sursa:

Exemplu:[pic]

Sursa:

2. Builder

Scop:

- Separarea constructiei unui obiect complex de reprezentarea acestuia, astfel incat acelasi proces de constructie poate crea reprezentari diferite

- Analiza unei reprezentari complexe, crearea uneia sau a mai multor sarcini

Problema:

- O aplicatie trebuie sa creeze elementele unui agregat complex. Caietul de sarcini al agregatului exista intr-un depozit secundar, iar una dintre numeroasele reprezentari trebuie sa fie construita in depozitul primar.

Diagrama UML:

[pic]

Sursa:

Exemplu: [pic]

Sursa:

3. Factory Method

Scop:

- Definirea unei interfete pentru crearea unui obiect, in timp ce subclase;e pot decide ce clasa sa instantieze. Acest model permite unei clase sa amane instantierea subclaselor.

- Se defineste un constructor “virtual”

- Operatorul “new” este considerat daunator

Problema:

- Un framework trebuie sa standardizeze modelul arhitectural pentru o serie de aplicatii, dar sa permita aplicatiilor sa defineaza propriul domeniu de obiecte si sa asigure instantiarea lor.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

4. Object Pool

Scop:

- Poate oferi un impuls semnificativ al performantei. Acest model este cel mai eficient in situatiile in care costul de initializare al unei instante este ridicat, rata de instantiere a unei clase este mare, iar numarul de instantieri utilizate la un moment dat este scazut

Problema:

- Modelul Object Pools este utilizat pentru a gestiona cache-ul obiectelor. Un client cu acces la un object pool poate evita crearea unor noi obiecte printr-o simpla cerere catre object pool pentru un obiect care a fost deja instantiat. In general, un pool va fi mereu in crestere, de exemplu, va crea obiecte noi in cazul in care este gol, sau poate exista un pool care limiteaza numarul de obiecte create. Este de dorit pastrarea tuturor obiectele refolosibile care nu sunt in prezent utilizate in acelasi pool pentru a putea fi gestionate de o politica coerenta. Pentru a realiza acest lucru, clasa care semnifica pool-ul reutilizabil este o clasa “singleton”.

Diagrama UML: [pic]

Sursa:

Exemplu:

[pic]

Sursa:

5. Prototype

Scop:

- Precizeaza tipurile de obiecte care vor fi create cu ajutorul unei instante prototip si creeaza obiecte prin copierea acestui prototip

- Foloseste o instanta a unei clase pentru toate instantele viitoare

- Operatorul “new” este considerat daunator

Problema:

- Aplicatia face imposibila modificarea unei clase obiect creata in urma unei noi expresii

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

6. Singleton

Scop:

- Asigura faptul ca o clasa are o singura instanta si ofera un punct global de acces la ea

- Incapsulare a initializarii “just-in-time” si a initializarii la prima utilizare

Problema:

- Aplicatia are nevoie de o singura instanta a unui obiect. In plus, sunt necesare initializarea lenta si accesul global.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

3. Modele de design structurale

In ingineria software, modele de design strucuturale sunt modele de design care faciliteaza proiectarea prin identificarea unui mod simplu de realizare a relatiilor dintre entitati.

1. Adapter

Scop:

- Interfata unei clase este convertita intr-o alta interfata pe care clientul o asteapta. Adaptorul permite claselor sa lucreze impreuna, care nu ar putea altfel datorita interfetelor incompatibile.

- Impacheteaza o clasa existenta intr-o noua interfata

- Reprezinta punte de legatura intre o componenta veche si un sistem nou

Problema:

- O componenta veche ofera o functionalitate convingatoare care se doreste refolosita, insa nu este compatibila cu filozofia si arhitectura sistemului care este elaborat.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

2. Bridge

Scop:

- Separarea abstractizarii de implementare, astfel incat cele doua pot fi modificate independent

- Publicarea interfetei intr-o ierarhie de mostenire si ascunderea implementarii in propria ierarhie de mostenire

- Transforma incapsularea in izolare

Problema:

- “Rigidizarea arterelor software” a avut loc prin subclasarea unei clase de baza abstracte pentru a oferi implementari alternative. Acest fapt blocheaza legatura dintre interfete si implementari. Abstractizarea si implementarea nu pot fi independent extinse sau compuse.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

3. Composite

Scop:

- Compune obiectele in structuri de arbori pentru a reprezenta ierarhii. Modelul de design composite permite clientilor sa trateze obiectele individuale si compozitiile de obiecte uniform

- Compozitie recursiva

- Directorii contin intrari, care la randul lor pot fi directori

Problema:

- Aplicatia trebuie sa manipuleze colectia ierarhica a obiectelor primitive si compozite. Prelucrarea unui obiect primitiv este tratata intr-un fel, iar prelucrarea unui obiect compozit este tratata difert. Nu este de dorit sa exista o interogare a tipului pentru fiecare obiect inainte de acesta sa fie procesat.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

4. Decorator

Scop:

- Atribuie responsabilitati suplimentare la un obiect dinamic. Decoratorii ofera o alternativa flexibula la subclasare pentru extinderea functionalitatii

- Clientul poate specifica infrumusetarea unui obiect de baza prin impachetarea recursiva a acestuia

- “Impacheteaza un cadou, il pune intr-o cutie si impacheteaza cutia”

Problema:

- Se doreste adaugarea unui nou comportament sau un nou status pentru obiecte individuale la run-time. Mostenirea nu este fezabila deoarece este statica si este valabila pentru o intreaga clasa.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

5. Facade

Scop:

- Ofera o interfata unificata pentru un set de interfete intr-un subsistem. Modelul de design Facade defineste o interfata de nivel superior care face subsistemul mai usor de utilizat

- Impacheteaza un subsistem complex cu o interfata simpla

Problema:

- Un segment al comunitatii client are nevoie de o interfata simplificata pentru functionalitatea globala a unui subsitem complex

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

6. Flyweight

Scop:

- Utilizarea partajarii pentru a suporta un numar mare de obiecte eficient

- Folosirea strategiei “Motif GUI” de inlocuire a widget-urilor “grele” cu gadget-uri “usoare”

Problema:

- Proiectarea “low-level” a obiectelor ofera flexibilitate optima, dar poate fi inacceptabil de costisitoare in termeni de performanta si utilizare a memoriei

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

7. Private Class Data

Scop:

- Controlarea accesului la scrierea atributelor clasei

- Separarea datelor de metodele care le folosesc

- Incapsuleaza initializarea datelor unei clase

- Asigurarea unui noi tip “final” – “final after construction”

Problema:

- O clasa poate expune atributele sale (variabile de clasa) la manipulare atunci cand manupularea nu mai este dorita, de exemplu, dupa constructie. Folosind modelul de proiectare a datelor de clase private previne manipulari nedorite

- O clasa poate avea atribute mutabile o singura data care nu pot fi declarate “final”. Folosind acest model de design permite setarea o singura data a acelor atribute

- Motivatia pentru acest model de design vine de la obiectivul de proiectare pentru a proteja statusul claselor prin minimizarea vizibilitatii atributelor sale

Diagrama UML + exemplu:

[pic]

8. Proxy

Scop:

- Furnizarea unui substituent pentru un alt obiect pentru a controla accesul la acesta

- Folosirea unui nivel suplimentar de indirectare pentru a suporta acces distribuit, controlat sau inteligent.

- Adauga un invelis si o delegatie pentru a proteja componenta reala de complexitate nejustificata

Problema:

- Este nevoie de suport pentru obiecte care consuma multe resurse si nu se vrea instantierea unor astfel de obiecte, cu exceptia cazului si pana cand acestea sunt de fapt solicitate de client

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

4. Modele de design comportamentale

In ingineria software, modelele de design comportamentale sunt folosite in comunicarea dintre entitati si face ca aceasta comunicare sa fie mai usoara si mai flexibila.

1. Chain of responsibility

Scop:

• Evita cuplarea intre expeditorul cererii si destinatar prin acordarea unei sanse mai multor obiecte de a se ocupa de cerere. Inlantuie obiectele destinatare si trece cererea de-a lungul lantului pana cand un obiect o rezolva.

• Cereri “Lansare-si-lasa” ('launch-and-leave') cu o singura conducta de procesare care contine multe handler-uri posibile.

• O lista obiect-orientata cu traversare recursiva.

Problema:

• Exista un numar variabil de obiecte de tip “handler” sau “element de prelucrare”, sau “nod” si un flux de cereri care trebuie sa fie manipulate. Este necesara procesarea eficienta a cererilor fara a fi nevoie de calibrarea relatiilor intre handlers si a priorietatilor, sau a maparilor request-to-handler.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

2. Command

Scop:

• Incapsularea unei cereri ca obiect, permitandu-se astfel parametrizarea clientilor cu cereri diferite, formarea unei cozi de cereri sau stocarea istoricului acestora si asigurarea suportului pentru anularea operatiilor.

• Promovarea “invocarii unei metode pe un obiect” la statusul de obiect full.

• Un callback obiect-orientat.

Problema:

• Necesitatea de a emite cereri de obiecte, fara sa se stie despre faptul ca operatia este ceruta sau despre receptorul cererii.

Diagrama UML:

[pic]Sursa:

Exemplu:

[pic]

Sursa:

3. Interpreter

Scop:

• Avand in vedere un limbaj, sa se defineasca o reprezentare pentru gramatica ei, impreuna cu un interpretor care utilizeaza acea reprezentare pentrua interpreta propozitiile din limbaj.

• Maparea unui domeniu la un limbaj, a unui limbaj la o gramatica si a unei gramatici la un design ierarhic obiect-orientat.

Problema:

• O clasa de probleme apare in mod repetat intr-un domeniu bine definit si bine inteles. In cazul in care domeniul ar fi fost caracterizat de un “limbaj”, atunci problemele pot fi rezolvate cu usurinta cu ajutorul unui interpretor.

Diagrama UML:

[pic]

Sursa:

Exemplu:[pic]

Sursa:

4. Iterator

Scop:

• Ofera o modalitate de a accesa secvential elementele unui obiect agregat, fara a expune reprezentarea sa de baza.

• Bibliotecile standard de captare C++ si Java care permit decuplarea claselor de colectare si algoritmilor.

• Promovarea la “full object status” traversarea unei colectii.

• Traversare polimorfa.

Problema:

• Necesitatea de a “abstractiza” traversarea diferitelor structuri de date astfel incat algoritmii (care sunt capabili de a interfata cu fiecare intr-un mod transparent) sa fie definiti.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

5. Mediator

Scop:

• Definirea unui obiect care incapsuleaza modul in care un set de obiecte interactioneaza. Mediator promoveaza cuplarea slaba, interzicand obiectelor sa faca referinte explicite unul catre celalalt si permite modificarea independenta a interactiunilor.

• Proiectarea unui intermediar pentru a decupla mai multi parteneri (peers).

• Promovarea relatiilor “many-to-many” la “full object status” intre partenerii care interactioneaza.

Problema:

• Vrem sa proiectam componente reutilizabile, dar dependenta intre piesele potential reutilizabile demonstreaza fenomenul “spaghetti code”.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]Sursa:

6. Memento

Scop:

• Capturarea si exteriorizarea starii interne a unui obiect fara a viola incapsularea, astfel incat obiectul sa poata fi readus ulterior la respectiva stare.

• Un “magic cookie” care incapsuleaza o capabilitate “check point”.

• Promoveaza redarea sau rollback la full object status.

Problema:

• Nevoia de a restaura un obiect inapoi la starea precedenta (operatii undo sau rollback).

•

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

7. Null Object

Scop:

• Incapsularea absentei unei obiect prin oferirea unei alternative substitutibila care ofera un comportament 'do nothing' ca default.

Se foloseste Null Object atunci cand:

➢ un obiect necesita o colaborare. Sablonul Null Object nu introduce aceasta colaborare, ci se foloseste de o colaborare deja existenta;

➢ unele instante de colaborare trebuie sa nu faca nimic;

➢ dorim sa abstractizam manipularea null-ului departe de client.

Problema:

• Dat fiind faptul ca referinta unui obiect ar putea fi optional nula si faptul ca rezultatul unei verificari null este de a nu face nimic sau de a folosi o valuare implicita, cum poate ca absenta unui obiect (sau prezenta unei referinte nule) sa fie tratata intr-un mod transparent?

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

8. Observer

Scop:

• Definirea unei dependente “1-la-N” ('one-to-many') intre obiecte, astfel incat atunci cand un obiect isi schimba starea, toate obiectele dependente vor fi notificate si actualizate in mod automat.

• Incapsularea componentelor de baza (sau comune) intr-o abstractie Subject, iar componentele variabile (sau optionale) intr-o ierarhie Observer.

• Componenta “View” din “Model-View-Controller”.

Problema:

• Un design mare monolitic nu se scaleaza bine in timp ce apar noi cerinte grafice si de monitorizare.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

9. State

Scop:

• Permiterea unui obiect sa-si altereze comportamentul atunci cand starea interna se schimba.

• O masina de stare obiect-orientata.

Problema:

• Comportamentul unui obiect monolitic este in functie de starea sa si isi va schimba comportamentul in timpul rularii in functie de acea stare.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

10. Strategy

Scop:

• Definirea unei familii de algoritmi, encapsularea fiecarei familii si setarea lor ca fiind interschimbabile. Strategy permite ca algoritmul sa varieze intr-un mod independent de clientii pe care il folosesc

• Capturarea abstractiei intr-o interfata si ingroparea detaliilor de implementarea in clase derivate.

Problema:

• Una din strategiile dominante al design-ului obiect-orientat este principiul “open-closed”.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

11. Template method

Scop:

• Definirea scheletului unui algoritm dintr-o operatie, transferand unii pasi catre subclase. Template Method permite subclaselor sa redefineasca anumiti pasi dintr-un algoritm fara a schimba structura acestuia.

• Clasa de baza declara 'placeholders' al algoritmului, iar clasele derivate implementeaza acele 'placeholders'.

Problema:

• Doua componente diferite au similaritati importante, dar nu demonsteaza reutilizarea unei interfete comune sau a unei implementari. Daca o schimbare la ambele componente devine necesara, efortul duplicat trebuie sa fie extins.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

12. Visitor

Scop:

• O operatie care va fi efectuata pe elementele unei structuri de obiecte, permitand definirea unei operatii noi fara a schimba clasele elementelor pe care opereaza.

• Clasica tehnica folosita pentru a recupera informatii scrise pierdute.

• Face ceea ce trebuie bazandu-se pe tipul a doua obiecte.

• Expediere dubla.

Problema:

• Multe operatii distincte trebuie sa fie efectuate pe obiecte nod intr-o structura eterogena agregata. Dorim sa evitam “poluarea” claselor nod cu aceste operatii. Si nu dorim sa interogam tipul fiecarui nod si sa introducem pointerul catre tipul corect inainte de a efectua operatiunea dorita.

Diagrama UML:

[pic]

Sursa:

Exemplu:

[pic]

Sursa:

5. Bibliografie

1. “Design Patterns_ Elements of Reusable Object-Oriented Software” by Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides

2. “Design Patterns Explained Simply” by Alexander Shvets

3.

4.

5.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download