SABLOANE DE PROIECTARE (Design Patterns)

abloane creaionale
Abstract Factory (Kit) http://labs.cs.upt.ro/doc/DP/dpRoot.html
Reprezint o interfa pentru crearea obiectelor din aceeai familie sau interdependente, fr a
specifica clasa din care fac parte.
Se considera un generator de interfete grafice utilizator (GUI) care ofera suport pentru standarde
multiple privind modul de prezentare a elementelor interfetei.
Sablonul Abstract Factory se utilizeaza cand:
-un sistem trebuie sa fie independent de modul in care produsele sale sunt create;
-un sistem trebuie sa fie configurat la un moment dat cu una din mai multe familii de produse;
-se doreste crearea unei biblioteci de produse pentru care sunt relevante doar interfetele, nu si
implementarile (de exemplu, in cazul generatorului de interfete , nu ne intereseaza cum sunt desenate pe
ecran diversele elemente de control, ci doar care sunt efectele actionarii lor de catre utilizator si aceste
efecte sunt asemenatoare, indiferent de standardul de prezentare).

Fig. 1 Structura general a ablonului Abstract Factory

AbstractFactory - declara o interfata pentru operatii de creare a produselor abstracte;

ConcreteFactory - implementeaza operatiile de creare a produselor concrete;

AbstractProduct - declara o interfata pentru o categorie de produse;

ConcreteProduct
o

defineste un produs care va fi creat de un obiect ConcreteFactory corespunzator;

implementeaza interfata AbstractProduct;

1

 Client - utilizeaza doar interfetele AbstractFactory si AbstractProduct.

Constructorul (Builder)

http://labs.cs.upt.ro/labs/SPM/html/SPM10.html

Construeste obecte complexe separind construirea de reprezentare.

Def: Este sablonul care descrie crearea unor obiecte in regim pas cu pas, in conditiile in care procesul de
creare este independent de structura interna a obiectelor.
Builder specifica o interfata abstracta pentru crearea partilor obiectelor produs.

Fig. 2 Structura general a ablonului Builder

Builder: este interfata pentru crearea partilor unui obiect (produsul).

ConcreteBuilder:
o

construieste si asambleaza partile unui produs, implementand interfata Builder;

defineste si pastreaza un istoric al reprezentarilor pe care le creaza;

ofera o interfata pentru obtinerea produsului finit.

Director: construieste un obiect folosind interfata Builder.

Product:
o

reprezinta obiectul complex care se construieste. Concrete Builder construieste

reprezentarea interna a produsului si defineste procesul prin care produsul este asamblat;

poate include clase care definesc partile componente ale produsului si interfete pentru
asamblarea partilor intr-un produs final.

Factory Method
Creaza obecte fara a specifica clasa exacta pentru creare.
Acest sablon defineste o interfata pentru crearea unui obiect, dar lasa subclasele sa decida ce
clasa trebuie instantiata. Practic, presupune ca o clasa paseaza subclaselor sale sarcina instantierii.
Practic Factory Method ii lipseste pe proiectanti de necesitatea plasarii codului care depinde de
clasele aplicatiei.Codul are legatura cu interfata clasei Product de aceia el poate sa conlucreze cu orice
clasa definita de utilizator.
Utilizam acest sablon cind :

o clasa nu poate anticipa clasa obiectelor pe care trebuie sa le creeze;

o clasa doreste ca subclasele sale sa specifice ce obiecte trebuie sa creeze;

Sablonul Factory Method pune in legatura un obiect independent de aplicatie cu unul dependent de
aplicatie care va fi delegat sa creeze alte obiecte dependente de aplicatie. Structura de obiecte propusa
este cea din figura:

Fig. 3 Structura general a ablonului Factory Method

Operatia FactoryMethod din CreatorConcret va contine o instructiune de forma:
return new ProdusConcret;
iar in clasa Creator, celelalte functii, de exemplu AltaOperatie, vor putea apela FactoryMethod sub
forma:
Produs *p = FactoryMethod;
Rolurile claselor componente din structura de mai sus sunt:

Produs: defineste interfata obiectelor pe care la va crea metoda de generare;

3

ProdusConcret: implementeaza interfata Produs;

Creator:

declara metoda de generare, care are referinta la Produs ca tip returnat. Aceasta metoda
poate sa aiba si o implementare prin care sa se returneze un obiect al unei
clase ProdusConcret implicite;

poate apela metoda de generare pentru a crea obiecte de tip Produs.

CreatorConcret: redefineste metoda de generare pentru a crea obiecte de tip ProdusConcret.

Prototype
Creaza obiecte clonind un obect deja existent.(se combina cu builder)
Cind folosim:
-Cind instantele clasei se definesc in timpul executiei.
-Cind se doreste evitarea erarhiilor de clase sau fabricei care corespund erahiilor de produse.
-Cind instantele unei clase pot avea una sau citeva combinatii(stari).

Fig. 4 Structura general a ablonului Prototype

Clasa Prototype- declara o clasa pentru clonare.
ConcretePrototype-implementeaza operatii de clonare.
Client-Creaza obecte noi prin clonarea prototipului.

Singleton http://labs.cs.upt.ro/labs/SPM/html/SPM10.html#singleton
Restrictioneaza crearea unui obiect pentru o clasa doar la o instanta.
Creaza premizele ca o anumita clasa sa fie instantiata doar o singura data, permitandu-se un acces global
la instanta respectiva.
Cind se foloseste:
trebuie ca pentru o anumita clasa sa existe doar o singura instanta si aceasta trebuie sa fie accesibila
clientilor dintr-un punct de acces cunoscut;
instanta unica a unei clase trebuie sa poata fi extinsa prin derivare, iar clientii sa poata utiliza
instanta extinsa fara a-si modifica propriul cod..

Fig. 5 Structura general a ablonului

Singleton

class Singleton {
public:
static Singleton*
Instance();
//alte metode accesibile
clientilor
protected:
Singleton();
private:
static Singleton* _instance;
};
Singleton* Singleton::_instance =
0;
Singleton* Singleton::Instance(){
if(_instance==0)
_instance=new Singleton;
return _instance;
}

Object pool
Ofera o crestere de performanta semnificativa si este in deosebi eficienta in cazurile cind costurile de
initializare a unui obiect sunt mari, frecventa de instantiere a clasei e innalta, iar nr de instante folosita
in orice moment de timp este mic.
Bazinul de obecte (este un Singleton) este folosit pentru managementului hasului de obecte.
Un client cu accesul la bazinul de obecte poate evita crearea obectelor noi doar prin crearea insantelor
deja create din bazin.

Fig. 6 Structura general a ablonului Object Pool

Reuseble-sunt instantele claselor care vor fi folosite un timp limitat de client iar apoi reintoarse in bazin.
Client- instante a claselor care utilizeaza Reuseble.
ReuseblePool- fac menegementul obectelor Reuseble pe care le folosesc obectele client.

Sabloane structurale
Adapterul
http://labs.cs.upt.ro/labs/SPM/html/SPM11.html#adapter
Adapter de clasa permite claselor cu interfete incompatibile sa lucreze impreuna creind interfata
proprie pentru a satisfice necesitatea clasei.
Acest sablon realizeaza conversia interfetei unei clase intr-o alta interfata, asteptata de client.
Sablonul Adapter se aplica in situatiile in care:
se doreste utilizarea unei clase deja existente, a carei interfata nu se potriveste cu necesitatile
aplicatiei;
se doreste crearea unei clase reutilizabile care coopereaza cu clase ale caror interfete nu sunt
compatibile intre ele;
Clientii apeleaza operatii ale unei instante a clasei Adapter. Aceasta, la randul ei, apeleaza operatii ale
clasei Adaptee, pentru a satisface cererile.

Target: defineste interfata specifica domeniului, solicitata de client;

Client: colaboreaza cu obiecte care se conformeaza interfetei Target;

Adaptee: defineste o interfata existenta care necesita adaptare;

Adapter: adapteaza interfata Adaptee la interfata Target.

unde operatia BuildTree este:
BuildTree(node n){
delegate -> GetChildren(this,n);
for each child {
AddGraphicNode(delegate -> CreateGraphicNode(this,child))
BuildTree(child)
}
}

Bridge (Puntea)
Definitie
Este un sablon care realizeaza decuplarea unei abstractiuni de implementarea ei, astfel incat cele 2 pot
varia independent.
Context
Cand o anumita abstractiune poate avea mai multe variante de implementare, de obicei se utilizeaza
mostenirea: o clasa abstracta defineste interfata abstractiunii, iar subclasele concrete o implementeaza in
diverse moduri.
Aceasta abordare nu este intotdeauna suficient de flexibila. Prin mostenire o implementare este legata
permanent de abstractiune si acest lucru face foarte dificila modificarea independenta a abstractiunii si a
implementarii.
Exemplu : Abstractizarea este Windows interfata grafica, ce efectuiaza mostenirea la 2 subclase
XWindow si PMWindow ,insa apare oproblema cu definirea subclase cum ar fi: IconWindow,
TransientWindow. Sablonul Bridge isi propune sa solutioneze aceste probleme plasand abstractiunea
Window si implementarea ei in ierarhii separate. Astfel, vom avea o ierarhie formata din clasa Window,
cu subclasele IconWindow si TransientWindow, respectiv o ierarhie separata, formata din clase care
depind de platforma: WindowImpl cu subclasele XWindowImpl si PMWindowImpl:

Operatiile care apar in clasele din prima ierarhie sunt operatii specifice diverselor tipuri de ferestre, in
timp ce operatiile care apar in a 2-a ierarhie depind de platforma grafica. De Exemplu:
void IconWindow::DrawBorder(Point nv, int w, int h){
DrawRect(nv,w,h);
DrawText();
}
void TransientWindow::DrawCloseBox(Point nv, int w, int h){
DrawRect(nv,w,h);
}
void XWindowImpl::DevDrawText(){
XDrawString(); //operatie oferita de platforma X
}
void XWindowImpl::DevDrawLine(Point s, Point d){
XDrawLine(s,d);
}

Composite(Compunerea)
Compunerea presupune crearea a 0 sau mai multe obiecte similarea astfel incite le sa fie manipulate ca
un obiect intreg.

Component (Graphic) defineste interfata;

-ofera realizarea unor operatii predefinite
Leuf (Rectangle, Line, Text, ..) - frunza:
- reprezinta noduri frunza si nu are urmasi.
Composite (Picture) - :
-defineste comportamentul componentelor care au urmasi;
Client - :
9

- Component.
Clientul foloseste interfata clasei Component pentru a interactiona cu obectele.Daca cel care primeste
cererea este Leaf atunci el o si prelucreaza.Daca destinatarul este Composite , de obicei el retransmite
cererea la ceilalti din canal.
class Equipment {
public:
virtual -Equipment ( ) ;
const char* NameO { return _name; }
virtual Watt Power ();
virtual Currency NetPrice();
virtual Currency DiscountPrice ( ) ;
virtual void Add ( Equipment *);
virtual void Remove (Equipment*) ;
virtual Iterator<Equipment*>* Createlterator ();
protected:
Equipment (const char*);
private:
const char* _name;
}

Decoratorul (Decorator)
Adauga sau supraincarca dynamic comportamentul unei metode existente intr-un obiect.
Decoratorul foloseste mostenirea pentru a prelua tipul obiectului decorat si
compunerea pentru ai schimba comportamentul
Se pot utiliza unul sau mai multi decorator pentru un obiect .
Decoratorii pot fi create cu sabloanele fabrica si constructor.

10

Context
De multe ori, intr-o aplicatie, se doreste adaugarea de functiuni suplimentare unor obiecte individuale,
nu unei intregi clase. Spre exemplu, un generator de interfete utilizator trebuie sa permita proiectantului
adaugarea de elemente cum ar fi barele de defilare sau chenarele oricarei componente a interfetei. O
posibilitate de a adauga functiuni o reprezinta mostenirea. Decoratorul respecta interfata componentei pe
care o "decoreaza", astfel incat prezenta lui este transparenta pentru clientii componentei.
Sa presupunem, de exemplu, ca avem un obiect al unei clase TextView, care afiseaza un text intr-o
fereastra. TextView nu va avea bare de defilare in mod implicit, deoarece nu are nevoie de ele
intotdeauna. Atunci cand este necesar, se poate utiliza un obiect ScrollDecorator pentru a aduga bare de
defilare.

Motivatii

Sablonul Decorator se aplica in urmatoarele situatii:

-pentru a adauga functiuni in mod dinamic si transparent unor obiecte individuale;
-pentru a putea elimina anumite functionalitati;

11

class VisualComponent {
public:
VisualComponent();
virtual void Draw();
virtual void Resize();
// ...
};
Component defineste interfata pentru obecte,posibil diniamic.
ConcreteComponent (TextView) se defines obectele care au obligatii suplimentare.
Decorator - : pastreaza adresele la obectele Component .
ConcreteDecorator (BorderDecorator, ScrollDecorator) indatoriri suplimentare pentru decorator.

Facade
Sablonul Faade sau Facade este la fel utilizat in programarea obiect orientate. O faade este un obiect
ce furnizeaza o interfata simplificata la un cod mare, cum ar fi o librarie de clase.
El poate face codul cu mult mai usor de citit deoarece, contine metode utile pentru sarcini simple.
Furnizeaza o interfata unica pentru un set mai larg de interfete intr-un subsistem. Faade defineste o
interfata de nivel inalt ce usureaza cu mult utilizarea subsistemului. Se utilizeaza foarte frecvent.
Sablonul Facade descrie modul in care subsisteme complete pot fi reprezentate ca obiecte.
Motivatie:
subsisteme - reducerea complexittii
Minimizarea comnunicatiei dintre subsisteme
Aplicabilitate:
Se doreste utilizarea unei interfete simplificate la un sistem complicat
Exist multe dependente ntre clienti si implemetrile concrete ale conceptelor
Se doreste stratificarea sistemului

Facade
Determina care clase ale subsistemului sunt responsabile pentru o cerere.
Atribuie cererile clientului obiectului subsistemului apropiat.

Subsystem classes
Implementeaza functionalitatile subsistemului.
Responsabil de lucrul atribuit obiectului Faade
Nu contine nicio informative despre fasada si nu are nici o referinta la ea.

Flyweight
Musca-foloseste partajarea pentru a gestiona efficient un numar mare de obiecte de dimensiuni mici
,mai reduce costul crearii si manipularii de obiecte similar
Se utilizeaza:
-Aplicatia utilizeaza un numar mare de obecte;

Proxy
Sablonul Proxy asigura un surogat sau un inlocuitor pentru alt obiect pentru a controla accesul la acesta.
Delegarea la distanta-controleaza accesul catre un obiect nelocal
Delegarea virtuala- controleaza accesul la o resursa costisitor de creat.
Delegarea de protectie-controleaza accesul la o resursa pe baza unor drepturi de acces.
Referinta inteligenta: copierea la scriere (copy on write) blocarea unui obiect ,numararea referintelor
,caching.
Proxy afiseaza un mesaj pina cind imaginea este incarcata si poate fi afisata.

Proxy:

o contine o referinta (realSubjectRef) care permite accesul la obiectul real.

Aceasta referinta ar putea fi de tip Subject daca Subject si RealSubject au
aceeasi interfata;
o ofera o interfata identica cu Subject, astfel incat un obiect Proxy poate substitui
obiectul RealSubject din punct de vedere al clientului;
o controleaza accesul la obiectul real si poate fi responsabil de crearea si
stergerea acestuia;
o alte responsabilitati ale obiectului Proxy depind de tipul lui:
un proxy de tip ambasador redirecteaza o cerere de la client spre obiectul
real, aflat la distanta;
un proxy virtual poate ingloba informatii suplimentare despre obiectul
real, care vor putea fi utilizate chiar in absenta obiectului respectiv;
proxy-ul de protectie verifica daca clientul are drepturile de acces
necesare pentru a putea solicita un anumit serviciu.
Subject: defineste o interfata comuna pentru RealSubject si Proxy, astfel incat un
obiect Proxy sa poata fi folosit oriunde se asteapta un obiect RealSubject;
RealSubject: defineste obiectul real pe care il reprezinta Proxy.

Chain of responsibility
Evita cuplarea intre expeditorul si destinatarul unei cereri acordind mai multor obecte o sansa de a
rezolva cererea.Sablonul inlantueste obiectele destinatar si trece cererea dea lungul lantului pina cind un
obect o rezolva.
Utilizam cind :
-Cererea poate fi rezolvata de mai multe obecte;
-Doriti sa generate o cere catre unul din mai multe obecte fara a preciza in mod explicit destinatarul.

Command
Incapsuleaza o cerere ca obect ,permitind astfel sa parametrizam clientii cu diferite cererei, sa formeze o
coada sau un registru de cereri sis a asigure support pentru operatiile ce pot fi anulate.

class Command {
public:
virtual ~Command ();
virtual void Execute () = 0;
protected:
Command ( ) ;
};

Interpretor
Pentru un limbaj dat , acest sablon defineste o reprezentare a gramaticii limbajului impreuna cu un
interpretor care utilizeaza reprezentarea pentru a interpreta proprietatile din limbaj.
Ex. Cautarea sirurilor care corespund unui model.

Iteratorul
Iterator acceseaza elementele unui obiect secvential fara a arata reprezentarea acestuia.
Sablonul Iterator se aplica pentru:

a accesa elementele unui agregat, fara a se cunoste reprezentarea interna a acestuia;

a permite traversari multiple simultane ale aceluiasi agregat;
a crea o interfata uniforma in vederea traversarii diferitelor structuri de agregate (cu alte cuvinte, pentru
a crea suportul iterarii polimorfice).
In figura de mai jos este data structura de clase care constituie sablonul Iterator:

Iterator - defineste interfata pentru accesarea si traversarea elementelor agregatului;

IteratorConcret
implementeaza interfata Iterator;
tine evidenta pozitiei curente la traversarea agregatului;
Agregat - defineste interfata pentru crearea unui obiect Iterator;
AgregatConcret - implementeaza interfata de creare a iteratorului, sub forma:
return new ConcreteIterator(this);
Consecinte
Exista 3 consecinte importante:
1. Sablonul Iterator ofera posibilitatea de a modifica tipul de traversare a unui agregat. Exista agregate
care pot fi traversate in mai multe feluri. De exemplu, intr-un compilator, analiza semantica si generarea
de cod se fac in timpul traversarii arborelui sintactic. Acesta poate fi parcurs in inordine sau in
preordine. Pentru a schimba tipul parcurgerii doar se inlocuieste iteratorul.
2. Iteratorul simplifica interfata Agregat, care nu mai trebuie sa contina operatii specifice parcurgerii
(parcurgerilor).
3. Deoarece fiecare instanta a unui iterator pastreaza pozitia elementului curent pe durata parcurgerii
unui agregat, este posibil ca acelasi agregat sa fie parcurs in paralel prin intermediul a mai multi
ietartori.

Mediator
Permite cuplarea slaba intre clase prin faptul ca este singura clasa ce contine cunostinte detaliate despre
metodele lor.
Definete un obiect care ncapsuleaz modul n care un set de obiecte interacioneaz.

De obicei, un program este compus dintr-un numr mare de clase. Deci, logica i calculul este
distribuit ntre aceste clase. Cu toate acestea, dup cum mai multe clase sunt dezvoltate ntr-un program,
n special n timpul ntreinerii i / sau refactorizare, problema de comunicare ntre aceste clase pot
deveni mai complexe. Acest lucru face ca programul mai greu de citit i s menin. Mai mult, poate
deveni dificil de a schimba programul, deoarece orice schimbare poate afecta cod n mai multe alte
clase.

Memento
Memento - este un model de software de proiectare, care ofer posibilitatea de a restabili un
obiect la starea sa anterioar (undo prin derulare napoi).

Modelul memento este implementat cu trei obiecte: original, un ngrijitor i o amintire. Emitentul
este un obiect care are o stare intern.ngrijitorul va face ceva la origine, dar vrea s fie n msur s
anula schimbarea.ngrijitor solicit n primul rnd de origine pentru un obiect amintire. Apoi face tot ce
operaie (sau secven de operaii) a fost de gnd s fac. Pentru a face revenirea la starea de dinaintea
operaiunilor, se returneaz obiectul amintire a emitentului. Obiectul memento n sine este un obiect
opac (una care ngrijitorul nu poate, sau nu ar trebui, schimbare). La utilizarea acestui model, trebuie
avut grij n cazul n care Emitentul poate modifica alte obiecte sau resurse - modelul amintire
funcioneaz pe un singur obiect.

Observer

State

 ablonul State descrie modul de implementare al unui obiect ce-i poate schimba comportamentul la
schimbarea strii lui interne.

Strategy

Strategy permite unei family de algoritmi sa fie selectat dynamic in timpul rularii.
Sablonul Strategy se va aplica atunci cand:
- mai multe clase inrudite difera doar prin comportament;
-

sunt necesare mai multe variante ale unui algoritm, care difera intre ele, de exemplu, prin
compromisul spatiu-timp adoptat;

un algoritm utilizeaza date pe care clientul algoritmului nu trebuie sa le cunoasca;

intr-o clasa sunt definite mai multe actiuni care apar ca structuri conditionale multiple. In loc de
aceasta, se recomanda plasarea ramurilor conditionale inrudite in cate o clasa strategy separata.

Solutie
In figura de mai jos este data structura de clase care constituie sablonul Strategy:

Strategy: declara o interfata comuna pentru toti algoritmii acceptati. Context va utiliza aceasta
interfata pentru a apela un anumit algoritm;

ConcreteStrategy: implementeaza un algoritm concret, utilizand interfata Strategy;

Context: contine o referinta la Strategy, care va indica un obiect ConcreteStrategy;

clasa Context poate defini o interfata prin care sa laseStrategy sa-i acceseze datele;

Strategy si Context interactioneaza pentru a implementa un algoritm ales. Un obiect Context poate
transmite spre Strategy toate datele necesare algoritmului, cand acesta este apelat; sau,
obiectul Context se poate transmite pe sine insusi ca argument al operatiilor din Strategy.
Obiectul Context dirijeaza cererile clientilor sai spre obiectul Strategy de care este legat. De regula,
clientii creaza si paseaza spre Context obiecte de tip ConcreteStrategy, dupa care clientii vor
interactiona doar cu Context.
Consecinte
Ierarhiile de clase Strategy definesc familii de algoritmi sau comportamente care pot fi reutilizate in
diverse contexte. Mostenirea poate fi aplicata aici pentru a "factoriza" functionalitatile comune ale
algoritmilor.
Sablonul Strategy ofera o alternativa structurilor de control conditionale pentru selectia unui anumit
comportament. Cand mai multi algoritmi sunt inglobati intr-o singura clasa, este greu sa se evite
structurile conditionale. Adesea, prezenta in cod a numeroase asemenea structuri constituie un indiciu ca
ar trebui aplicat sablonul Strategy.
Clasele Strategy se pot utiliza si in cazul producerii de implementari diferite ale aceluiasi
comportament, clientul putand sa opteze pentru una dintre ele, in functie de performantele dorite.
Un dezavantaj al sablonului Strategy il consituie faptul ca, pentru a putea alege o anumita implementare
sau un anumit algoritm, clientii trebuie sa stie care sunt ofertele si prin ce difera ele, una fata de alta.
Acest lucru poate insemna in cele din urma ca un client sa trebuiasca sa cunoasca anumite detalii de

implementare. De aceea, sablonul se va aplica doar in situatia in care diferentele relevante intre
obiectele ConcreteStrategy se refera la comportamentul vizibil din perspectiva clientului.

Template Method
Template Method - defineste un schilet al unui algoritm ca o clasa abstracta sa defineasca
comportamentul concret.
Sablonul Template Method se utilizeaza in urmatoarele situatii:
- pentru a implementa partile invariante ale unui algoritm o singura data, lasand subclaselor
sarcina de a implementa partile care variaza;
-

cand partile comune ale unor subclase trebuie "scoase in factor comun" si localizate intr-o
singura clasa, pentru a evita duplicarea de cod; acesta este un exemplu de "reproiectare in
vederea generalizarii": mai intai se identifica diferentele din codul existent si apoi se constituie
operatii noi cu diferentele respective, iar in final, codul se inlocuieste cu o metoda sablon care
apeleaza una dintre operatiile noi;

pentru a controla extinderea subclaselor, si anume: se poate defini o metoda sablon care apeleaza
asa-numite operatii-hook("carlige") in puncte specifice, permitand astfel ca extensiile sa se
realizeze doar in acele puncte.

In figura de mai jos este data structura de clase care constituie sablonul Template Method:

AbstractClass
o

defineste operatiile primitive abstracte pe care subclasele urmeaza sa le implementeze;

implementeaza o metoda sablon care defineste scheletul unui algoritm. Aceasta metoda
apeleaza operatiile primitive si, eventual, alte operatii definite in AbstractClass sau in
alte clase:

ConcreteClass - implementeaza operatiile primitive pentru a realiza pasii specifici ai

algoritmului definit de TemplateMethod.
Consecinte

Metodele sablon reprezinta o tehnica fundamentala de reutilizare a codului. Ele au o importanta

deosebita in cadrul bibliotecilor de clase, deoarece constituie un mijloc de factorizare a aspectelor
comune ale comportamentului claselor respective.

Metodele sablon reprezinta o structura de control inversat, numita adesea "principiul Hollywood",
adica: "Nu ne chema tu, ca te chemam noi". Aceasta inseamna ca o clasa parinte apeleaza operatiile
unei subclase si nu invers.

Vizitor
ablonul Vizitor descrie operaia care trebuie s fie efectuat cu toate obiectele dintr-o structur.
ablonul dat ne permite s definim o operaiune nou fr ca s modificm clasele obiectelor date.
Motivare
Deseori exist un sistem deja creat ce funcioneaz foarte bine, doar c a venit timpul s
efectum o anumit operaie asupra obiectelor din sistem. Dar deoarece nu dorim ca s modificm
clasele cu adugarea de noi metode, noi crem un vizitor care va vizita toate obiectele din sistemul dat
i va executa operaia necesar fr a modifica mcar un simbol n codul claselor. Poate fi privit ca un
instrument al hackerilor asupra structurii de obiecte.