Sabloane

Un sablon este o solutie la o problema intr-un context.

Context: situatia in care se aplica sablonul
Problema: scopuri si constrangeri
Solutie: reguli de proiectare

Tipuri de sabloane:
 Creationale (instantierea)
 Structurale (compunerea)
 Comportamentale (comunicarea)

CREATIONALE - se ocupa de crearea obiectelor

Abstract Factoy
Sablonul asigura o interfata pentru crearea unor familii de obiecte inrudite sau
dependente fara a le specifica clasa concreta.
Prin intermediul sablonului, nu se creaza direct clasele ( folosind new) si se apeleaza
o metoda care face acest lucru (eventual folosind parameti). Se folosesc clase
abstracte pentru respectarea principiului inversarii dependentelor.

1. Singleton
Sablonul Singleton asigura faptul ca o clasa are doar o singura instanta si furnizeaza
un punct de acces global catre aceasta.
- este o clasa care poate avea o singura instanta( ex.ferestrele sistemului de operare)
- foloseste stari globale, ceea ce nu este foarte indicat pentru ca face codul greu de
inteles ( starea obiectului putand fi schimbata oriunde)
- este dificil de testat din cauza starilor globale
- dependentele nu apar explicit, din cauza starilor globale. Solutia la aceastra
problema este injectarea unei dependente (trimiterea ca parametru in constructor sau
intr-o metoda setter sau normala)
2. Prototype
Sablonul Prototype precizeaza, folosind o instanta prototip, tipurile de obiecte ce vor
fi create si creaza noile obiecte copiind acest prototip.
- prototype = clonare
- o alternativa a instantieri clasei este realizarea unei clone a unui obiect
- clona are starea sursei la momentul crearii
- foloseste o interfata care are definita o metoda clone()
- ex. Template-urile din word. Sunt prototipuri de documente completate partial, care
urmeaza sa fie completate de utilizator
- problema principala este clonarea obiectului (superficiala sau profunda). O
alta problema este initializarea unor valori dupa clonare

3. Builder
Sablonul Builder separa constructia unui obiect complex de reprezentarea acestuia,
astfel incat acelasi proces de constructie sa poata crea reprezentari diferite
- folosit des in parsere
- din clasa parinte, generala, se deriveaza alti constructori care au aceleasi date,
dar sunt contruite/redefinite altfel. Datele sunt aranjate altfel => obiectul este
construit diferit.
- incapsuleaza logica de construire/ambalare a obiectului, astfel incat clientul
doar cere o configuratie

Concluzii:
 Sablonul Singleton garanteaza ca dintr-o clasa poate exista doar o singura
instanta.
 Sablonul Prototype are ca scop clonarea instantelor de obiecte bazate pe
obiecte prototip.
 Sablonul Builder abstractizeaza pasi de construire a unui obiect astfel incat
diferite implementari ale acestor pasi pot construi reprezentari diferite.

STRUCTURALE - se ocupa de compunerea obiectelor

1. Adapter
Sablonul Adapter converteste interfata unei clasa in alta interfata pe care clientul o
asteapta.
- este o clasa care converteste o interfata noua (necompatibila direct cu sistemul meu)
la un tip de interfata cu care sistemul meu stie sa lucreze
- poate fi folosit atat pe clase cat si pe obiecte
- scopul este sa converteasca interfata

2. Facade
Sablonul Facade asigura o interfata unificata la o multime de interfete dintr-un sistem.
Defineste o interfata de nivel mai inalt care face subsistemul mai usor de utilizat.
- in momentul in care avem multe interfete de folosit, putem defini una care sa
le contina pe toate, si noi sa lucram cu acea interfata.
- decupleaza clientul de subsistem si multele lui componente, insa subsistemul poate
fi accesat si direct (pentru ca nu il incapsuleaza)
- scopul este sa simplifice interfata
Acest sablond lucreaza impreuna cu Principiul cunoasterii minime.
Principiul cunoasteri minime
- este recomandat sa apelezi metode doar din: obiect/clasa, obiectele primite
ca parametru, obiectele instantiate de metoda
- nu este recomandat sa apelezi metoda ale obiectelor returnate de alte metode
3. Decorator
Sablonul Decorator ataseaza responsabilitati suplimentare unui obiect in mod dinamic.
Asigura o alternativa flexibila la derivare pentru extinderea functionalitatilor.
- se foloseste impreuna cu principiul deschis-inchis
- este folosit pentru a schimba comportamentul permitand adaugarea de functionalitati
noi

4. Bridge
Sablonul Bridge decupleaza o abstractiune de implementarea ei, astfel incat cel 2 sa
poata varia in mod independent
Ex. Vizualizarea listei de proprietati ale controlerelor( componente ale interfetei) este
implementata folosind sablonul Bridge; telecomanda universala pentru tv (care
functioneaza si la samsung, sony, ….)
- este util cand vrem sa dezvoltam platforme diferite
- clientul interactioneaza direct cu interfata. Interfata interactioneaza cu clasa
abstracta de implementare, avand o referinta catre acesta ( referinta fiind
initializata
cu o instanta a unei clase concrete). Prin intermediul interfetei, clientul poate accesa
doat metodele din clasa abstracta (clasele concrete fiind incapsulate).

5. Proxy
Sablonul Proxy asigura un surogat sau un inlocuitor al unui obiect pentru a controla
accesul la acesta.
Ex. Incarcarea unei imagini mari de pe net ( Proxy-ul afiseaza un mesaj pana cand
imaginea este incarcata si poate si afisata)
- poate face gestiune a resurselor, trata cereri sau chiat instanti obiecte
- intercepteaza un apel pe care il trimite catre obiectul tinta

6. Flyweight
Sablonul Flyweight foloseste partajarea pentru a gestiona eficient un numar mare de
obiecte de dimensiuni mici.
Ex. Lista de foldere ( care sunt la fel, doar ca difera starea: selectat sau neselectat);
simbolurile din editoarele de documente
-foloseste liste de tip cheie-valoare in care sunt pastrate obiectele deja create de
fabrica
- poate fi implementat folosind singleton si proxy

7. Composite
Sablonul Composite compune obiecte in structuri de tip arbore pentru a reprezenta
ierarhii de tip parte-intreg.
- composite are responsabilitatea de a gestiona ierarhia si executa operatii, ceea
ce incalca principiul responsabilitatii unice. Ca si compromis, nodurile si frunzele
se trateaza similar.
- foloseste sablonul iterator
- clientul trateaza uniform toate obiectele din structura ( chiar daca ele sunt
compuneri de obiecte sau obiecte individuale)

Concluzie:
 Sablonul Adapter converteste interfata unei clase in alta interfata pe care o
asteapta clientul.
 Sablonul Facade asigura o interfata unificata la o multime de interfete dintr-un
subsistem.
 Sablonul Decorator ataseaza responsabilitati suplimentare unui obiect in mod
dinamic.
 Sablonul Bridge decupleaza o abstractiune de implementarea ei, astfel cele doua
sa poata varia in mod independent.
 Sablonul Proxy asigura un inlocuitor sau surogat al unui obiect pentru a controla
accesul la acesta.
 Sablonul Flyweight foloseste partajarea pentru a gestiona un numar mare de
obiecte de dimensiuni reduse.
 Sablonul Composite compune obiecte in structuri de tip arbore pentru a
reprezenta ierarhii parte-intreg si permite clientui sa trateze uniform obiectele
individuale sau compuneri de obiecte.

COMPORTAMENTALE - se ocupa de comunicare

1. Iterator
Sablonul Iterator asigura o cale de accesare secventiala a elementelor unui obiect
agregat, fara a expune reprezentarea lui de baza.
Ex. Este folosit pentru a imbina un vector si o lista, pentru ca ambele sa functioneze
unitar.
- este folosit pentru traversarea structurilor agregate diferite (ArrayLista, Dictionary,
HashMap, Stack, List …)
- simplifica traversarea pentru client

2. Observer
Sablonul Observer defineste o dependenta 1 la N intre obiecte, astfel incat in cazul in
care un obiect isi schimba starea, vor fi instiintate si actualizate toate obiectele sale
dependente.
- Subiectul e singurul proprietar al datelor caracteristice sablonului
- Subiectul stie doar ca observatorii implementeaza o interfata (update)
- se pot adauga oricand observatori noi, tipuri de observatori noi
- subiectul si observatorii nu se afecteaza unul pe altul
- protocoale specifice: pull (extragere) si push (impingere)
- in cazul relatiilor compexe intre subiect si observator, se poate implementa un obiect
intermediar ChangeManager care sa gestioneze interactiunea
Ex. Evenimentele componentelor interfetei utilizator; evenimentele actionate de timp
(timer, trigger)

3. Command
Sablonul Command incapsuleaza o cerere ca obiect permitand trimiterea ca parametru
a unei functii incapsulate intr-un obiect, formarea de cozi de cereri si stocarea
istoricului (logging), asigura suport pentru anularea operatiilor.
- diminueaza cuplarea dintre client si obiectele receiver
- incapsularea codului de tratare a evenimentelor

4. Chain of Responsability
Sablonul Chain of Responsability evita cuplarea intre expeditorul si destinatarul unei
cereri acordand mai multor obiecte o sansa de a rezolva cererea. Sablonul inlantuie
obiectele destinatar si trece cererea de-a lungul lantului pana cand un obiect o rezolva.
Ex. Cererea de cumparare este trecuta pe la mai multe persoane din ierarhie pana cand
este aprobata
- este folosit cand o cerere poate fi rezolvata de mai multe obiecte, dar nu stim care
- reduce cuplarea ( expeditorul si destinatarul nu se cunosc, si nici lantul)
- creste flexibilitatea ( pot fi adaugate responsabilitati noi sau modificat lantul)
- dezavantajul e ca o cerere poate ramane nerezolvata

5. Mediator
Sablonul mediator defineste un obiect care incasuleaza modul in care interactioneaza
o multime de obiecte.
- promoveaza cuplarea slaba, interzicand obiectelor sa faca referinta explicite unul la
celalalt.
Ex. Camera de chat; Formularele (componentele se schimba unul pe altu in functie de
actiunile utilizatorului; ele nu stiu unul de altul, comunica prin intermediul Form-ului)
- este util atunci cand comunicarea intre obiecte este bine definita, dar complexa
- cand reutilizarea unui obiect este dificila deoarece comunica cu multe alte obiecte
- ofera decuplare si simplifica comunicarea, insa apare centralizarea controlului (“God
object”)
6. Memento
Sablonul Memento capteaza si exteriorizeaza starea interna a unui obiect fara a viola
incapsularea, astfel incat obiectul poate fi readus la respectiva stare.
Ex. Salvarea starii unui joc; Salvarea listei de cumparaturi (produselor din cos)
- util pentru ca pastreaza incapsularea si simplifica retinerea istoricului
- copierea poate fi costisitoare (volum mare de date)

7. Strategy
Sablonul Strategi defineste o familie de algoritmi, incapsuleaza fiecare algoritm si ii
face interschimbabili. Acest sablon permite algoritmilor sa varieze independent de
clientul care ii utilizeaza.
Ex. Sortari, tipuri de grafice, tipuri de personaje dintr-un joc
- util cand clase inrudite difera doar prin comportament
- este necesar o varianta diferita a unui algoritm
- alternativa la generarea de subclase

8. State
Sablonul State permite unui obiect sa-si modifice comportamentul cand starea sa
interna se schimba. Obiectul va parea ca isi schimba clasa.
- util cand avem multe if-uri (teste) pentru a verifica starea unui
obiect, comportamentul obiectului depinzand de starea acestuia
- tranzitiile de stari sunt explicite
- pentru cresterea flexibilitatii (eliminarea if-urilor) se creste numarul de clase

9. Interpreter
Sablonul Interpreter defineste o reprezentare a gramatici unui limbaj impreun cu un
interpretor care utilizeaza reprezentarea pentu a interpreta propozitiile din limbaj.
Ex. Cifre romane, rapoarte
- cand se doreste a se face un parser intre limbaje de programare
- parsarea comenzilor utilizatorului, comenzi simple date de utilizator sunt traduse
in comenzi mai complexe pe are le executa calculatorul
Concluzie:
 Sablonul Iterator asigura o cale de acces secvential a elementelor unui obiect
agregat, fara a expune reprezentarea lui de baza.
 Sablonul Observer permite ca un obiect sa notifice alte obiecte atunci cand se
produc modificari in starea sa initiala
 Sablonul Command este un obiect-functie care incapsuleaza apelul unei metode
din alt obiect
 Sablonul Chain of Responsability incearca rezolvarea unei cereri cu ajutorul
unui numar necunoscut de obiecte
 Sablonul Mediator incapsuleaza protocolul de comunicare al obiectelor
 Sablonul Memento reprezinta starea interna a unui obiect la un anumit moment
de timp
 Sablonul Strategy defineste o familie de algoritmi, incapsuleaza fiecare
algoritm si ii face interschimbabili
 Sablonul State permite unui obiect sa-si modifice comportamentul cand starea sa
interna se modifica
 Sablonul Interpreter defineste o reprezentare a gramatici unui limbaj impreuna
cu un interpretor care utilizeaza reprezentarea petru a interpreta propoziitiile
din limbaj
 Metoda Factory
 Scop
 Defineşte o interfaţă pentru crearea unui obiect, dar lasă
subclasele să decidă ce clasă să instanţieze.
 Metoda Factory permite unei clase să defere instanţierea
subclaselor
 Cunoscut şi ca
 Constructor Virtual
 Aplicabilitate
 O clasă nu poate anticipa clasa obiectelor pe care trebuie să le
creeze
 O clasă doreşte ca subclasele sale să specifice obiectele pe care
le creează
 Clasele delegă responsibilitatea uneia sau mai multor subclase
ajutătoare

 Product
 defineşte interfaţa obiectelor ce vor fi create de FM
 Produs Concret implementează interfaţa
 Creator
 declară FM, care returnează un produs de tip Product.
 poate defini o implementare implicită a FM
 poate apela FM pentru crearea unui produs
 ConcreteCreator
 suprascrie FM pentru a furniza o instanţă a ConcreteProduct
 Creator se bazează pe subclasele sale pentru definirea metodei factory
astfel încât să returneze instanţa potrivită a clasei ConcreteProduct
 Elimină legarea între clasele specifice aplicaţiei din cod
 codul de creare foloseşte doar interfaţa clasei Product
 Facilitează derivarea
 subclasele pot astfel modifica produsul creat
 Poate conecta ierarhii paralele de clase
 lasă clienţii să apeleze FM
 Slide-ul următor...

Metoda Prototype
 Scop
 Specificaţi tipul obiectelor care se creează folosind o instanţă
prototipică
 Creaţi obiecte noi copiind acest prototip
 Aplicabilitate
 când un sistem trebuie să fie independent de cum sunt create,
compuse şi reprezentate produsele sale şi
 când clasele de instanţiat sunt specificate la execuţie
 evitaţi construirea unei ierarhii de clase-factory paralelă cu
ierarhia claselor de produse
 Prototype
 declară o interfaţă pentru a se clona.
 ConcretePrototype
 implementează o operaţie pentru a se clona.
 Client
 creează un obiect nou cerând prototipului să se cloneze.
 Un client cere unui prototip să se cloneze.
 Clasa client trebuie să se iniţializeze în constructor
 cu prototipul concret adecvat.
 Adăugarea şi ştergerea produselor la execuţie
 Mai puţină derivare
 evită ierarhia paralelă pentru creatori
 Specificarea de obiecte noi prin varierea valorilor prototipurilor
 clientul se comportă diferit prin delegarea către prototip
 Specificarea de obiecte noi prin varierea structurii prototipurilor
 produse compuse
 Fiecare subclasă a Prototype trebuie să implementeze clone
 dificil când clasele există deja sau
 obiectele interne nu permit copierea sau au referinţe circulare

Metoda Abstract Factory

 Scop
 Oferă o interfaţă pentru crearea de familii de obiecte înrudite
sau dependente fără specificarea claselor lor concrete
 Aplicabilitate
 Sistemul trebuie să fie independent de cum sunt create, compuse
şi reprezentate produsele sale
 Sistemul trebuie configurat de una din mai multe familii de
produse
 Trebuie forţat ca o familie de obiecte produs să fie folosite
împreună
 Izolarea claselor concrete
 apar în ConcreteFactories nu în codul clientului
 Facilitează schimbul de familii de produse
 un ConcreteFactory apare într-un singur loc
 uşor de modificat
 Promovează consistenţa între produse
 toate produsele unei familii se modifică împreună, în acelaşi
timp
 Este dificilă susţinerea de tipuri noi de produse
 necesită o modificare în interfaţa AbstractFactory
 ... şi a tuturor subclaselor sale, în consecinţă

Metoda Singleton
 Scop
 Asigură ca o clasă să aibă doar o singură instanţă şi furnizează
un punct de acces global la ea
 Aplicabilitate
 dorim exact o instanţă a unei clase
 accesibilitate pentru clienţi dintr-un singur punct
 dorim ca instanţa să fie extensibilă
 poate permite deasemenea şi un set numărabil de instanţe
 optimizare faţă de vizibilitatea globală
 mai bine decât o clasă statică:
 nu se poate răzgândi
 metode niciodată virtuale
  Acces controlat la instanţa unică
 Permite rafinarea operaţiilor şi reprezentării
 Permite un număr variabil (dar precis) de instanţe
 Reducerea vizibilităţii globale

Metoda Iterator
Furnizează o modalitate de accesare secvenţială a elementelor unui agregat,
fără a expune reprezentarea care stă la baza acestora
 Obiectele listă îşi creează poropriul iterator prin metoda CreateIterator;
 CreateIterator este o metodă Factory, care conectează cele două ierarhii
(slide-ul precedent.)
 Folosiţi şablonul Iterator:
 Pentru a accesa conţinutul unui obiect agregat fără să îi expuneţi
reprezentarea internă
 Pentru a susţine traversări multiple ale obiectelor agregat
 Pentru a furniza o interfaţă uniformă de traversare a diferitelor
structuri agregat (i.e. pentru a susţine iteraţii polimorfice)
  Un ConcreteIterator ţine evidenţa obiectului curent din agregat, şi
poate calcula următorul obiect din traversare

Tratarea cererilor: şablonul COMMAND

 Scop
 Încapsulează cereri ca obiecte, şi permite:
 parametrizarea clienţilor cu diferite cereri
 înlănţuirea sau log-area cererilor
 suport pentru operaţii anulabile (UNDO)
 Aplicabilitate
 Parametrizarea obiectelor
 Specificarea, înlănţuirea, şi executarea cererilor la diferite
momente
 Suport undo
 Modelarea tranzacţiilor
 structurarea sistemelor construite pe operaţii primitive, în
jurul operaţiilor de nivel înalt
 interfaţa comună  invocarea identică a tuturor
tranzacţiilor

 Decuplează Invoker de Receiver

 Comenzile sunt obiecte ale unor clase
 pot fi manevrate şi extinse
 Comenzi compuse (Composite Commands)
 a se vedea şi şablonul Composite
 Uşor de adăugat comenzi noi
 Invoker nu se modifică
 cod stabil- Principiul Deschis-Închis
 Potenţial pentru un exces de clase de tip command

MEMENTO
-COMPORTAMENTAL-
 Captează şi externalizează starea internă a unui obiect astfel încât
obiectul poate fi restaurat în această stare mai târziu, fără a sparge
încapsularea
 Folosiţi când:
 (o parte din) starea unui obiect trebuie salvată pentru a readuce
mai târziu obiectul în această stare
 O interfaţă directă pentru obţinerea stării ar expune detalii de
implementare şi ar sparge încapsularea obiectului

 Protejează graniţele încapsulării

 Simplifică Originatorul
 Acesta nu e nevoit să reţină stări anterioare la care ar fi necesar
să revină
 Uneori folosirea este costisitoare
 Dacă este multă informaţie de copiat sau atunci când clienţii
creează des memento-uri
 Costuri ascunse în manevrarea memento-urilor
 Un caretaker nu ştie exact cât să aloce pentru stocarea unui
memento (pentru că el nu are acces la informaţiile din interior)
 Şablonul Observer
 Scop
 Defineşte o dependenţă de tipul unul-la-mai-mulţi între obiecte
astfel încât atunci când un obiect îşi schimbă starea, toate
dependenţele sale sunt anunţate şi actualizate automat
 Motivaţie
 Partiţionarea sistemului în colecţii de clase cooperante are ca
efect secundar necesitatea menţinerii consistenţei între obiectele
relaţionate
 Slide-ul următor: putem refolosi prezentarea grafică şi datele
independent unele de altele în alte aplicaţii

 Cuplaj minimal şi abstract între subiect şi observatori

 Suport pentru comunicare de tip difuzare (“broadcast”)
 Notificarea trimisă de subiect nu trebuie să-şi specifice
primitorul, singura responsabilitate a subiectului este să-şi
notifice observatorii, indiferent de numărul lor. Observerul
decide dacă tratează sau ignoră notificarea.
 Modificări neaşteptate
 Întrucât observerii nu ştiu unul de existenţa celuilalt, pot apare
modificări incorecte, în cascadă

Şablonul Mediator
 Scop
 Defineşte un obiect ce încapsulează cum interacţionează o
mulţime de obiecte
  Promovează cuplajul redus prin faptul că obiectele nu mai fac
referinţă direct unele la altele, permiţând varierea independentă a
interacţiunii lor
 Folosiţi Mediator când:
 O mulţime de obiecte comunică într-un mod bine definit dar
complex;
 Interdependenţele sunt nestructurate şi dificil de înţeles;
 Refolosirea unui obiect este dificilă deoarece comunică cu prea
multe alte obiecte
 Un comportament distribuit între mai multe clase ar trebui să fie
readaptabil fără derivare

 Limitează derivarea
 Modificarea comportamentului necesită doar derivarea
Mediatorului, clasele Colleague pot fi refolosite ca atare
 Decuplează colegii
 Putem varia şi refolosi clasele Colleague şi Mediator
independent
 Simplifică protocoalele obiectelor
 Înlocuieşte interacţiunile mai-mulţi-la-mai-mulţi cu interacţiuni
unul-la-mai-mulţi (mai uşor de înţeles, extins, menţinut)
 Abstractizează cooperarea obiectelor
 Ajută la clarificarea interacţiunilor independent de
comportamentul individual
 Centralizează controlul
 Mediatorul se poate transforma într-un monolit dificil de
întreţinut

Şablonul Strategy
 Scop
  Defineşte o familie de algoritmi, încapsulează fiecare algoritm, îi
face interschimbabili
 Permite algoritmului să varieze independent de clienţii ce îl
folosesc
 Aplicabilitate
 Sunt necesare variante diferite ale unui algoritm
 Un algoritm foloseşte date despre care clienţii nu trebuie să ştie
 evită expunerea structurilor de date complexe, specifice
algoritmului
 Multe clase relaţionate diferă doar prin comportament
 configurează o clasă cu un comportament particular

Consecinţe Pozitive
 Familii de algoritmi înrudiţi
 de obicei oferă implementări diferite ale aceluiaşi comportament
 alegerea se face ţinând cont de un compromis timp-spaţiu
 Alternativă la derivare
 Exemplul cu layout managers (soluţia Strategy, slide 9)
 Încă se derivează strategiile...
 Elimină instrucţiunile condiţionale
 multe instrucţiuni condiţionale "invitaţie" să aplicăm Strategy!

Consecinţe Negative
 Exces de comunicare între Strategy şi Context
 o parte din ConcreteStrategies nu necesită informaţiile trimise de
Context
 Clienţii trebuie să fie conştienţi de diferitele strategii
  clienţii trebuie să înţeleagă diferitele strategii
SortedList studentRecords = new SortedList(new ShellSort());
 Număr sporit de obiecte
 fiecare Context foloseşte obiectele sale concrete de strategie
 se poate reduce prin păstrarea strategiilor fără stare (împărţirea
lor între mai multe obiecte)

Şablonul State
 Scop
 permite unui obiect să îşi modifice comportamentul când i se
modifică starea internă
 obiectul va părea că îşi schimbă clasa
 Aplicabilitate
 comportamentul obiectului depinde de starea sa
 trebuie să îşi modifice comportamentul la execuţie în funcţie de
stare
 operaţii cu instrucţiuni condiţionale multiple, depinzând de
starea obiectului
 starea reprezentată de una sau mai multe constante
enumerate
 mai multe operaţii cu aceeaşi structură condiţională

 Localizează comportamentul specific stărilor şi partiţionează

comportamentul pentru stări diferite
 pune tot comportamentul asociat unei stări într-un obiect-stare
 uşor de adăugat stări şi tranziţii noi
 contextul devine Deschis-Închis
  Comportament împrăştiat între mai multe subclase ale State
 numărul de clase creşte, mai puţin compact decât o
singură clasă
 util dacă sunt multe stări...
 Face explicită tranziţia între stări
 mai mult decât o simplă modificare a unei valori interne
 stările primesc statutul unui obiect de sine stătător!
 Protejează Contextul de stări interne inconsistente

Şablonul Proxy
 Scop
 Furnizează un surogat (substitut) pentru alt obiect pentru a
controla accesul la el
 Aplicabilitate
 Oricând este nevoie de o referinţă către un obiect mai flexibilă
sau mai sofisticată decât un simplu pointer
 Proxy la distanţă
 Proxy virtual
 Proxy de Protecţie
 Proxy -accesorii (pointeri inteligenţi)
 Previn ştergerea accidentală a obiectelor (numără
referinţele)
 proxy (n. pl prox-ies) Agent pentru o persoană care se comportă ca
substitut pentru aceasta, autoritatea de a acţiona în locul altcuiva
 Proxy-urile introduc un nivel de indirectare (ocolire)
 folosit diferit în funcţie de tipul de proxy:
 Ascunderea spaţiului adresă (p. la distanţă)
 Crearea la cerere (p. virtual)
 Permite activităţi auxiliare adiţionale (protecţie, pointeri
inteligenţi)
 Copiază-în-timp-ce-scrii [J.Coplien92 - The "Handle Class" Idiom]
 copierea obiectelor mari şi complicate e costisitoare
 folosiţi proxy pentru copiere numai când obiectul nou este
modificat
 Subiectul trebuie numărat pe baza referinţei
 proxy incrementează contorul în timpul copierii
 Când apar modificări, copiază şi decrementează contorul
 if (counter == 0) delete Subject

Şablonul Bridge
 Scop
 Decuplează o abstracţiune de implementarea sa
 Permite implementării să varieze independent de abstracţiunea
sa
 Abstracţiunea defineşte şi implementează interfaţa
 Toate operaţiile din abstracţiune apelează metode din
obiectul de implementare
 În şablonul Bridge ...
 ... o abstracţiune poate folosi implementări diferite
 ... o implementare poate fi folosită în diferite abstracţiuni
 Evită legarea permanentă între o abstracţiune şi implementarea sa
 Abstracţiunile şi implementările lor trebuie să fie independentl
extensibile prin derivare
 Ascunde implementarea unei abstracţiuni complet de clienţi
 Codul lor nu trebuie să fie recompilat când se modifică
implementarea
 Partajează o implementare între mai multe obiecte
  Şi acest lucru trebuie ascuns de client


Decuplează interfaţa şi implementarea

 implem. configurabil şi modificabil la execuţie
 reduce dependenţele de la momentul compilării
 implement. modificărilor nu necesită recompilarea
Abstracţiunii
 Extensibilitate îmbunătăţită
 extinde prin derivarea independentă a Abstracţiunilor şi
Implementărilor
 Ascunderea detaliilor de implementare de clienţi
 ascunde clienţilor detaliile de implementare
 ex. partajarea obiectelor implementor împreună cu
numărarea referinţelor
 ... este “clasa de manevră" un Bridge sau un Proxy? ;)

Şablonul Composite
 Scop
 Tratează obiectele individuale şi compunerile acestor obiecte
uniform
 Compune obiectele în structuri arborescente pentru a reprezenta
agregări recursive
 Aplicabilitate
 reprezentarea ierarhiilor de obiecte de tip parte-întreg
  abilitatea de a ignora diferenţa dintre compuneri de obiecte şi
obiecte individuale

 Defineşte ierarhii uniforme de clase

 compunere recursivă de obiecte
 Face clienţii simpli
 nu trebuie să ştie dacă este o frunză sau un compus
 simplifică codul deoarece evită tratarea diferită a fiecărei clase
 Mai uşor de extins
 uşor de adăugat noi clase Composite sau Leave
 aplicaţie fericită a Principiului Deschis-Închis
 Design prea general
 sunt necesare verificări de tip pentru a restricţiona tipurile
admise într-o anumită structură compusă

Şablonul Flyweight
 Foloseşte partajarea pentru a suţine implementarea eficientă a unui
număr mare de obiecte cu granulaţie fină (structură complexă)- de
exemplu caractere individuale sau iconiţe pe ecran
 Un flyweight este un obiect partajat care poate fi folosit simultan în
contexte diferite
 Numărul de instanţe se reduce semnificativ, prin recunoaşterea faptului
că de fapt clasele sunt la fel cu excepţia câtorva parametri
 Concept cheie: distincţia între stare intrinsecă (păstrată în flyweight,
independentă de context) şi stare extrinsecă (depinde şi variază în
funcţie de context, deci nu poate fi partajată)
 Folosiţi când toate condiţiile de mai jos sunt îndeplinite simultan:
 O aplicaţie foloseşte un număr mare de obiecte
 Costurile de stocare sunt ridicate din cauza numărului mare de
obiecte
 Cea mai mare parte din starea unui obiect poate fi făcută
extrinsecă
 Multe grupuri de obiecte se pot înlocui de un număr relativ mic
de obiecte partajate, odată ce am îlăturat starea extrinsecă
 Aplicaţia nu depinde de identitatea obiectelor. Întrucât obiectele
flyweight pot fi partajate, testele de identitate vor întoarce true
pentru obiecte conceptual distincte

 Flyweight-urile adaugă costuri la momentul execuţiei (transferul,

găsirea şi/sau calcularea stării extrinseci), dar aceste costuri sunt
compensate de spaţiul eliberat prin fiolosirea şablonului
 Cantitatea de spaţiu economisit depinde de mai mulţi factori:
  Reducerea numărului total de instanţe prin partajare
 Cantitatea de stare intrinsecă pentru fiecare obiect
 Dacă starea extrinsecă e calculată sau stocată
 Cel mai mult spaţiu se economiseşte dacă obiectele folosesc cantităţi
susbstanţiale de stare intrinsecă şi extrinsecă, şi dacă starea extrinsecă
se poate calcula- în loc să fie stocată

Şablonul Adapter
 Converteşte interfaţa unei clase într-o altă interfaţă aşteptată de client
 Permite unor clase cu interfeţe diferite să lucreze împreună (prin
“traducerea” interfeţelor)
 Un editor de desenare lucrează cu obiecte grafice ce implementează
clasa abstractă Shape
 Dacă LineShape sau PolygonShape sunt uşor de implementat
(capacităţi limitate de desenare şi editare), o clasă TextShape ce poate
afişa şi edita text este mai dificilă (actualizare ecran, buffering…)
 Dacă dorim să utilizăm o clasă predefinită TextView care tratează
textul corect, definim clasa TextShape care adaptează interfaţa
TextView la cea alui Shape
 TextShape- adapter
 Editorul de text poate refolosi astfel clasa incompatibilă TextView

Şabloane relaţionate
 Bridge
 Au structuri similare, dar Bridge are un scop diferit: să separeu o
implementare de interfaţa sa, astfel încât cele două să poată fi
variate mai uşor, independent un ade alta.În schimb, adaptorul
are scopul de a modifica interfaţa unui obiect existent
 Decorator
 Îmbogăţeşte un obiect fără să-i schimbe interfaţa- deci e mai
transparent pentru aplicaţie, decât un adaptor; în consecinţă,
decoratorul suportă compoziţie recursivă, ceea ce nu e posibil cu
adaptorii puri
 Proxy
 Defineşte un reprezentant (surogat) pentru un obiect, fără să-i
schimbe interfaţa

Şablonul Lanţ de Responsabilităţi

(Chain of Responsibility)
 Scop
 Decuplează transmiţătorul cererii de primitor
 oferind mai multor obiecte şansa de a trata cererea
 Pune primitorii într-un lanţ şi transmite cererea de-a lungul
lanţului
 până ce un obiect o tratează
 Motivaţie
 help senzitiv la context
 o cerere de help este tratată de unul din mai multe obiecte
din IU (interfaţa utilizator)
 De către care obiect anume?
 depinde de context
 Obiectul care iniţiază cererea nu cunoaşte obiectul care va oferi
eventual ajutor
 Aplicabilitate
 mai mult decât un obiect poate trata o cerere
 şi nu cunoaştem apriori cine o va trata
 mulţimea de obiecte ce pot trata cererea trebuie să fie
specificabilă dinamic
 trimitem o cerere la mai multe obiecte fără să specificăm
primitorul
 Cuplaj redus
 clientul (trimiţătorul) nu trebuie să ştie cine îi va trata cererea
 trimiţătorul şi primitorul nu se cunosc unul pe celălalt
 în loc ca trimiţătorul să cunoască toţi potenţialii primitori, se
păstrează doar o referinţă la următorul handler din lanţ.
 simplifică interconexiunile dintre obiecte
 Flexibilitate în asignarea responsabilităţilor către obiecte
 responsabilităţile se pot adăuga sau schimba
 lanţul se poate modifica la execuţie
 Cererile pot rămâne netratate
 ...dacă lanţul nu a fost configurat corect

Şablonul Decorator
 Scop
 Adaugă responsabilităţi unui obiect particular, mai degrabă
decât clasei sale
 Ataşează dinamic responsabilităţi adiţionale unui obiect.
 O alternativă flexibilă la derivare
 Cunoscut şi ca
 Wrapper
 Aplicabilitate
 Adaugă responsabilităţi obiectelor transparent şi dinamic
 i.e. fără să afecteze alte obiecte
 Extinderea prin derivare nu e practică
 poate duce la prea multe subclase

 Mai flexibil decât moştenirea statică

 permite amestecarea şi potrivirea responsabilităţilor
 permite aplicarea unei proprietăţi de două ori
 Evită clasele încărcate de prea multe cracteristici specifice în partea de
sus a ierarhiei
 abordarea "plăteşte-pe-măsură-ce-consumi"
 uşor de definit noi tipuri de decoraţiuni
 O mulţime de obiecte mici
 uşor de adaptat, dar dificil de învăţat şi depanat
 Un decorator şi componenta sa nu sunt identice
 verificarea identităţii obiectelor poate genera probleme
 Ex. if ( aComponent instanceof TextView ) bla