abloane pentru proiectare (Design Patterns)

1. Introducere

Proiectarea orientat pe obiecte a software-ului presupune identificarea de obiecte,

abstractizarea lor n clase de granularitate potrivit, definirea interfeelor i ierarhiilor
de motenire, stabilirea relaiilor ntre aceste clase.
Soluia trebuie s rezolve problema i s fie n acelai timp suficient de flexibil
pentru a rezista la noi cerine i probleme ce pot apare n timp.

Proiectanii cu experien refolosesc soluiile bune de cte ori au ocazia. Exist

grupri de clase sau obiecte care se repet n cele mai diferite sisteme. Acestea rezolv
probleme specifice, folosirea lor fac proiectele mai flexibile, mai elegante,
reutilizabile. Un proiectant care stpnete un set de asemenea abloane le poate
aplica imediat la noile proiecte fr a mai fi nevoit s le redescopere.

abloanele ce se pot refolosi pot fi general valabile sau specifice unui domeniu, de
exemplu pentru probleme de concuren, sisteme distribuite, programare n timp real,
etc.

2. Clasificare

abloanele utilizate n sistemele OO pot fi clasificate ntr-o ierarhie dup cum

urmeaz:
Idiomuri
Mecanisme
Cadre (frameworks).

Un idiom este legat de un anumit limbaj de programare i reprezint o convenie

general acceptat de utilizare a limbajului respectiv.
Exemple tipice de idiomuri pot fi gsite n cadrul limbajelor C/C++. Returnarea unei
valori ntregi care s semnifice succesul sau eecul unei funcii este un idiom din C
(adoptat i de C++, pe lang generarea excepiilor). Importana acestui idiom const
n faptul c el reprezint un anumit stil acceptat de comunitatea utilizatorilor de C i
orice programator care citete o secven C recunoate imediat aceast convenie.
nclcarea acestui idiom are drept consecin producerea de cod greu de neles, chiar
dac este corect. Practic fiecare limbaj de programare i are propriile sale idiomuri.
La fel i o echip de programatori i poate stabili un set de obiceiuri, n funcie de
experiena i cultura pe care le posed.

Se poate spune c un idiom este o form de reutilizare pe scar mic.

Un mecanism este o structur n cadrul cruia obiectele colaboreaz n vederea

obinerii unui anumit comportament ce satisface o anumit cerin a problemei.
Mecanismele reprezint decizii de proiectare privind modul n care coopereaz
coleciile de obiecte. Ele se mai numesc i sabloane de proiectare (design patterns).
Majoritatea sistemelor OO includ mecanisme referitoare la:
persistena obiectelor
controlul stocrii
controlul proceselor
transmisia/recepia mesajelor
distribuirea i migrarea obiectelor
conectarea n reele (networking)
tranzacii
evenimente
modul de prezentare ("look & feel") al aplicaiei.

Un cadru reprezint o colecie de clase care ofer un set de servicii pentru un

domeniu particular. Cadrul export un numr de clase i mecanisme pe care
utilizatorii le pot adapta.

Cadrele sunt forme de reutilizare pe scar larg.

Cele mai rspndite tipuri de cadre sunt cele destinate crerii de interfee grafice.

3. Definiie

Un sablon reprezint o soluie comun a unei probleme ntr-un anumit context.

Importana abloanelor (standardelor) n construirea sistemelor complexe a fost de

mult recunoscut n alte discipline. n cadrul comunitii proiectanilor de software
OO (orientate pe obiecte) ideea de a aplica abloane se pare c a fost inspirat de
propunerea unui arhitect, Christopher Alexander, care a lansat iniiativa folosirii unui
limbaj bazat pe sabloane pentru proiectarea cldirilor i a oraselor. Acesta afirma c:
"Fiecare ablon descrie o problem care apare mereu n domeniul nostru de activitate
i indic esena soluiei acelei probleme ntr-un mod care permite utilizarea soluiei de
nenumrate ori n contexte diferite".
Dei n domeniul sistemelor OO soluiile sunt exprimate n termeni de obiecte i
interfee (n loc de ziduri, ui, grinzi etc), esena noiunii de sablon este aceeai, adic
de soluie a unei probleme ntr-un context dat.

abloanele de proiectare sunt o memorare pentru posteritate a experienei n domeniul

proiectrii sistemelor OO.

Un ablon este descris de patru elemente:

Nume: folosete pentru identificare; descrie sintetic problema rezolvat de
ablon i soluia.
Problema: descrie cnd se aplic ablonul; se descrie problema i contextul.
Solutia: descrie elementele care intr n rezolvare, relaiile ntre ele,
responsabilitile lor i colaborrile ntre ele.
 Consecine si compromisuri: implicaiile folosirii ablonului, costuri i
beneficii. Acestea pot privi impactul asupra flexibilitii, extensibilitii sau
portabilitii sistemului, dup cum pot s se refere la aspecte ale implementrii
sau limbajului de programare utilizat. Compromisurile sunt de cele mai multe
ori legate de spaiu i timp.

4. Organizarea unui catalog de abloane

abloanele sunt la diferite niveluri de abstractizare, au granulariti diferite.
Deoarece exist multe abloane de proiectare este necesar o anumit clasificare a lor
n vederea alctuirii unui catalog.

Criterii de clasificare:
Scop - abloanele pot fi creaionale, structurale sau comportamentale.
o abloanele creaionale (creational patterns) privesc modul de creare al
obiectelor.
o abloanele structurale (structural patterns) se refer la compoziia
claselor sau al obiectelor.
o abloanele comportamentale (behavioral patterns) caracterizeaz
modul n care obiectele i clasele interacioneaz i i distribuie
responsabilitile.
Domeniu de aplicare - abloanele se pot aplica obiectelor sau claselor.
o abloanele claselor se refer la relaii dintre clase, relaii stabilite prin
motenire i care sunt statice (fixate la compilare).
abloanele creaionale ale claselor acoper situaiile n care o
parte din procesul crerii unui obiect cade n sarcina
subclaselor.
abloanele structurale ale claselor descriu modul de utilizare a
motenirii n scopul compunerii claselor.
abloanele comportamentale ale claselor utilizeaz motenirea
pentru descrierea unor algoritmi i fluxuri de control.
o abloanele obiectelor se refer la relaiile dintre obiecte, relaii care
au un caracter dinamic.
abloanele creaionale ale obiectelor acoper situaiile n care o
parte din procesul crerii unui obiect cade n sarcina unui alt
obiect.
abloanele structurale ale obiectelor descriu cile prin care se
asambleaz obiecte.
abloanele comportamentale ale obiectelor descriu modul n
care un grup de obiecte coopereaz pentru a ndeplini o sarcin
ce nu ar putea fi efectuat de un singur obiect.

n tabelul de mai jos sunt incluse cele mai importante abloane, clasificate dup
criteriile enumerate anterior:

Scop
Domeniu de Creationale Structurale Comportamentale
aplicare
Factory Method Adapter (clasa) Interpreter
Clasa Interface Template Method
Marker Interface
Immutable Delegation Chain of Responsibility
Abstract Factory Adapter (obiect) Command
Builder Bridge Iterator
Prototype Composite Mediator
Obiect Singleton Decorator Memento
Facade Observer
Flyweight State
Proxy Strategy
Visitor

5. Rolul abloanele de proiectare n rezolvarea problemele de

proiectare

abloanele de proiectare rezolv multe din problemele cu care se confrunt

proiectanii. Cteva din aceste probleme sunt urmatoarele:

5.1 Gsirea obiectelor adecvate

Un obiect, care intr n alctuirea programelor OO, mpacheteaz att date, ct i

metode (operaii) ce opereaz asupra datelor. Obiectul execut o operaie cnd
primete o cerere (mesaj) de la un client.

Mesajele reprezint singura cale prin care un obiect este determinat s execute o
operaie, n timp ce operaiile sunt singurul mod de a modifica datele interne ale
obiectului. Din cauza acestor restricii starea intern a obiectului se spune c este
ncapsulat: ea nu poate fi accesat direct, iar reprezentarea ei este invizibil dinspre
exteriorul obiectului.

Partea dificil n proiectarea unui sistem OO este descompunerea sistemului n

obiecte. Aceasta deoarece procesul este influenat de mai muli factori care acioneaz
adesea n mod contradictoriu: ncapsularea, granularitatea, dependenele,
flexibilitatea, performanele, evoluia, gradul de reutilizare etc.

Exist mai multe metodologii OO: unele se concentreaz pe substantivele i verbele

extrase din enunul problemei, altele se concentreaz pe colaborrile i
responsabilitile din sistem sau se modeleaz lumea real i obiectele gsite la
analiz se translateaz i n proiectare.
Multe din obiectele care apar la proiectare provin din modelul creat n faza de analiz.
La proiect se vor adauga ns i clase care nu au coresponden n lumea real. Unele
din aceste clase sunt de nivel primar (de exemplu tablourile), altele au un nivel de
abstractizare mai ridicat. De exemplu sablonul Composition introduce o abstracie
menit s asigure tratarea uniform a obiectelor care nu au un corespondent fizic.
Modelarea strict a lumii reale va duce la un sistem ce reflect realitatea curent, dar
nu neaprat i pe cea viitoare. Abstraciunile identificate n timpul proiectrii sunt
eseniale n obinerea unui sistem flexibil.

abloanele ne pot ajuta n identificarea unor abstraciuni mai puin evidente i a

obiectelor care le pot reprezenta. De exemplu obiectele care reprezint procese sau
algoritmi nu apar n natur, dar ele nu pot lipsi dintr-un proiect. ablonul Strategy
descrie modul de implementare a unor familii interschimbabile de algoritmi. ablonul
State reprezint fiecare stare a unei entiti sub forma unui obiect. Asemenea obiecte
sunt rareori descoperite n timpul analizei sau chiar a stadiului incipient al proiectrii.

5.2 Determinarea granularitii obiectelor

Obiectele ce compun un sistem pot varia enorm ca mrime i ca numr. Ele pot
reprezenta practic orice ncepnd de la componente hardware pn la aplicaii ntregi.
Cum decidem ce ar trebui sa fie un obiect?

Exist abloane care acoper i acest aspect. Astfel, ablonul Facade descrie modul n
care subsisteme complete pot fi reprezentate ca obiecte, ablonul Flyweight arat cum
se poate gestiona un numr uria de obiecte la nivelurile cele mai fine de
granularitate. Alte abloane descriu cile prin care un obiect poate fi descompus n
obiecte mai mici. Abstract Factory i Builder reprezint obiecte a cror unic
responsabilitate este crearea de alte obiecte. Visitor i Command reprezint obiecte a
cror unic responsabilitate este implementarea unui mesaj ctre alt obiect sau grup de
obiecte.

5.3 Specificarea interfeelor obiectelor

Pentru fiecare operaie declarat ntr-un obiect se precizeaz numele, obiectele pe

care le ia ca parametrii i valoarea returnat; aceste elemente formeaz semntura
operaiei. Mulimea tuturor semnturilor corespunztoare operaiilor dintr-un obiect
reprezint interfaa obiectului. Interfaa unui obiect descrie complet setul mesajelor
care pot fi trimise spre obiectul respectiv.

Un tip este un nume utilizat pentru a referi o anumit interfa. Astfel, vom spune
despre un obiect c este de tipul Window dac el accept toate mesajele
corespunztoare operaiilor definite n interfaa numit Window. Ca urmare, un obiect
poate avea mai multe tipuri, adic o parte a interfeei sale poate fi de un tip, iar alt
parte de alt tip. De asemenea, mai multe obiecte pot partaja un anumit tip comun, daca
interfeele lor includ tipul respectiv. Interfeele pot s conin, la rndul lor, alte
interfee ca submulimi. Avnd dou tipuri, T1 i T2, vom spune c T1 este subtip al
lui T2 dac interfaa T1 include interfaa T2. n acest caz T2 este supertip al lui T1.
Mai spunem ca T1 motenete interfaa T2.
Interfeele sunt lucruri fundamentale n sistemele OO. Obiectele sunt cunoscute doar
prin intermediul interfetelor lor. O interfa nu d nici un detaliu relativ la
implementarea unui obiect, iar obiecte distincte pot implementa n mod diferit o
aceeasi cerere. Altfel spus, dou obiecte avnd implementri complet diferite pot avea
interfee identice.

Cnd o cerere este trimis unui obiect, operaia care se va executa depinde de:
cerere
obiectul care receptioneaz cererea.

Obiecte diferite care pot recepiona cereri identice pot avea implementri diferite ale
operaiilor ce vor satisface cererile respective. Asocierea unei cereri cu un obiect i cu
o operaie a obiectului la momentul execuiei se numete asociere (legare) dinamic
(dynamic binding). Asocierea dinamic permite scrierea de programe n care:
la emiterea unei cereri s nu ne preocupe ce obiect o va recepiona, tiindu-se
c orice obiect a crui interfa include o semntura potrivit va fi bun;
obiecte avnd interfee identice pot fi substituite unul altuia la executie;
aceast posibilitate de substituire se mai numete polimorfism.

Polimorfismul este un concept esenial n cadrul tehnologiei orientate pe obiecte.

El permite:
ca un obiect client s nu aib nevoie s cunoasc altceva despre alte obiecte
dect c posed o anumit interfa;
simplificarea definiiei clienilor;
decuplarea obiectelor unele de altele;
ca la execuie obiectele s-i modifice relaiile dintre ele.

n acest context, abloanele de proiectare ne ajut la:

definirea interfeelor;
identificarea elementelor care NU trebuie s apar ntr-o interfa.

Astfel, ablonul Memento descrie modul de ncapsulare i salvare a strii interne a

unui obiect pentru ca starea respectiv s poat fi restaurat ulterior. abloanele
specific de asemenea i relaii ntre interfee.

5.4 Specificarea implementrii obiectelor

Implementarea unui obiect este definit prin intermediul clasei obiectului. Clasa unui
obiect specific datele interne ale obiectului i definiiile operaiilor pe care acesta le
poate executa.
Obiectele sunt create prin instanierea unei clase; se mai spune c un obiect este o
instan a unei clase. Procesul de instaniere a unei clase presupune alocarea de
memorie pentru datele interne ale obiectului respectiv i asocierea operaiilor cu
aceste date. O clas poate fi instaniat de mai multe ori, n felul acesta rezultnd mai
multe exemplare similare de obiecte.
Pe baza unor clase existente se pot defini noi clase, folosind motenirea claselor. O
subclas motenete de la una sau mai multe clase printe (superclase) toate datele i
operaiile definite n acestea din urm. Obiectele instane ale subclasei vor
conine toate datele definite n subclasa i n clasele printe
putea executa toate operaiile definite n subclasa i n clasele printe.

O clas abstract are drept scop principal definirea unei interfee comune pentru
subclasele sale. Implementarea operaiilor unei clase abstracte este pasat parial sau
n ntregime subclaselor sale. De aceea, o clas abstract nu poate fi instaniat.
Operaiile declarate ntr-o clas abstract, dar neimplementate se numesc operaii
abstracte. Clasele care nu sunt abstracte se numesc clase concrete.

O subclas poate detalia sau redefini comportamentul claselor printe. Mai precis,
subclasa poate redefini (override) o operaie care apare i ntr-o clas printe, ceea ce
permite subclasei s poat prelua cereri n locul superclasei.

O clasa mixin este o clas care are drept scop oferirea unei interfee sau a unei
funcionaliti opionale altor clase. Ea este similar unei clase abstracte, n sensul c
nu poate fi instaniat, dar nu poate figura singur ca printe al unor subclase, ci doar
ntr-o schem de motenire multipl.

5.4.1 Motenirea claselor i motenirea interfeelor

Este important s inelegem diferena ntre clasa unui obiect i tipul obiectului.
Clasa definete starea intern a obiectului i implementarea operaiilor lui. Tipul
obiectului se refer doar la interfaa obiectului - setul cererilor la care obiectul poate
rspunde. Un obiect poate avea mai multe tipuri, iar obiecte de clase diferite pot avea
acelai tip.

Desigur c ntre clas i tip exist o strns legtura: prin faptul c o clas definete
operaiile pe care un obiect le poate executa, automat ea definete i tipul obiectului.
Cnd spunem c un obiect este instan a unei clase, aceasta nseamn c obiectul
posed interfaa definit de clasa respectiv.

Un limbaj ca C++ folosete clasele pentru a specifica tipul obiectului i

implementarea.

Este de asemenea important s inelegem diferena dintre motenirea de clas i

motenirea de interfa (subtipizare). Motenirea de clas presupune c implementarea
unui obiect este definit n termenii implementrii altui obiect. Cu alte cuvinte, ea
reprezint un mecanism de reutilizare (partajare) a reprezentrii i a codului.
Motenirea de interfa (subtyping) este un mecanism prin care un obiect poate fi
utilizat n locul altuia.

Este destul de uor de confundat aceste concepte ntre ele deoarece majoritatea
limbajelor de programare OO nu le disting n mod explicit. De exemplu n C++
motenire nseamn att motenire de clas, ct i de interfa. O difereniere ntre
cele dou s-ar putea face astfel:
 motenirea de interfa poate fi redat ca o derivare public a unei clase
abstracte (o clas care conine funcii-membru pur virtuale);
motenirea de clas poate fi modelat prin derivarea privat a unei clase.

Multe dintre abloanele de proiectare se bazeaz pe aceast distincie. De exemplu

obiectele dintr-un Chain of Responsibility trebuie s aib un tip comun, fr ns a
avea i implementarea comun. n cadrul ablonului Composite, Component
definete o interfa comun, n timp ce Composite definete o implementare comun.
abloanele Command, Observer, State i Strategy sunt adesea implementate cu
ajutorul claselor abstracte.

5.4.2 Programarea prin interfee i nu prin implementri

Motenirea de clas este n esen un mecanism care permite:

extinderea funcionalitii unei aplicaii prin reutilizarea funcionalitii din
clasele printe;
definirea rapid a unui nou fel de obiect, n termenii unuia deja existent;
obinerea unor noi implementri aproape fr efort, prin preluarea unei mari
pri din ceea ce avem nevoie de la clase existente.

Reutilizarea implementrii reprezint doar o faet a conceptului de motenire.

Posibilitatea de a defini familii de obiecte cu interfee identice (de obicei prin
motenirea de la o clas abstract) este un alt aspect important, deoarece
polimorfismul depinde de el.

Clasele derivate dintr-o clas abstract vor partaja interfaa acelei clase. Subclasele
vor aduga sau vor redefini operaii, dar nu vor ascunde operaii ale clasei printe. n
felul acesta toate subclasele vor putea rspunde la cererile corespunztoare interfeei
clasei abstracte printe.
Exist doua avantaje ale manipulrii obiectelor prin intermediul interfeelor definite n
clasele abstracte:
clienii nu trebuie s tie tipurile particulare ale obiectelor utilizate, atta timp
ct obiectele respective sunt compatibile cu interfaa pe care clienii o
ateapt;
clienii nu trebuie s tie care sunt clasele care implementeaz obiectele
respective, tiu doar despre clasele abstracte care definesc interfaa.

Toate acestea reduc substanial dependenele dintre subsisteme, permitnd formularea

urmtorului principiu al proiectrii OO:

PROGRAMAI N TERMENI DE INTERFEE, NU DE IMPLEMENTRI.

Nu declara variabile ca fiind instane ale unor clase concrete, mai degrab angajeaz-
te s foloseti o interfa definit printr-o clas abstract. Cnd este necesar
instanierea unor clase concrete, se recomand aplicarea abloanelor creaionale
(Abstract Factory, Builder, Factory Method, Prototype, Singleton) care permit
abstractizarea procesului de creare a obiectelor. n felul acesta se realizeaz o asociere
a unei interfee cu implementrile ei transparent la momentul instanierii.

5.5 Mecanisme ale reutilizrii

Problema este cum obinem un software flexibil i reutilizabil folosind concepte ca

obiect, clas, interfa, motenire. abloanele constituie un rspuns.

Motenirea i compunerea obiectelor

Cele mai cunoscute tehnici de reutilizare a funcionalitii n cadrul sistemelor OO

sunt motenirea de clas i asamblarea sau compunerea obiectelor (object
composition).

Motenirea de clas este cunoscut i sub numele de reutilizare tip cutie alb (white-
box reuse) deoarece n majoritatea cazurilor o parte din starea intern a claselor
printe este vizibil n subclase.

Asamblarea obiectelor reprezint o tehnic de obinere a unei funcionaliti noi prin

asamblarea sau compunerea unor obiecte avnd interfee bine definite. Tehnica este
cunoscut sub numele de reutilizare tip cutie neagr (black-box reuse) deoarece
obiectele care se asambleaz nu i cunosc unul altuia starea intern, ele apar unul fa
de altul ca nite cutii negre.

Ambele tehnici au avantaje i dezavantaje. Motenirea de clas se caracterizeaz prin

urmtoarele (avantaje):
este definit static la compilare i poate fi specificat direct, fiind suportat
explicit de limbajele de programare;
permite modificarea uoar a implementrii operaiilor reutilizate, i anume
ntr-o subclas ce redefinete o parte din operaiile clasei printe pot fi afectate
i operaii motenite dac acestea apeleaz operaii redefinite. n secvena C++
de mai jos este ilustrat sintetic aceast situaie:

class Parent {
//. . .
public:
void Operation1( );
void Operation2( ); //apeleaza metoda Operation1
};
class Child: public Parent {
//. . .
public:
void Operation1( ); //redefineste Operation1
//Operation2 ramane cea mostenita
};
void aFunction( ) {
Parent p;
Child c;
p.Operation2( );
 c.Operation2( );
//deoarece Operation2 apeleaza Operation1, metoda se va comporta
//diferit pentru cele 2 obiecte
}

Dezavantaje:

implementarea motenit de la clasele printe nu poate fi modificat n

momentul execuiei;
cel mai adesea clasele printe definesc cel puin parial reprezentarea fizic a
subclaselor lor, deci subclasele au acces la detalii ale implementrii
superclaselor. De aceea se mai spune c motenirea de clas ncalc principiile
ncapsulrii;
modificrile aduse implementrii unei superclase vor fora subclasele s se
modifice i ele. Dependenele de implementare pot cauza probleme atunci
cnd se ncearc reutilizarea subclaselor: dac anumite aspecte ale
implementrii motenite nu corespund necesitilor aplicaiei clasa printe
trebuie rescris sau nlocuit. Aceast dependen limiteaz flexibilitatea i, n
ultim instan reutilizarea. O soluie n acest caz ar fi aplicarea motenirii de
la clase abstracte, deoarece ele includ implementare n mic msur.

Compunerea obiectelor se caracterizeaz prin:

se defineste n mod dinamic, la execuie, prin faptul c anumite obiecte
primesc referine ale altor obiecte;
necesit ca obiectele s-i respecte unul altuia interfaa, ceea ce presupune c
interfeele s fie proiectate astfel nct s nu mpiedice utilizarea unui obiect n
combinaie cu mai multe tipuri de obiecte. Deoarece obiectele sunt accesate
doar prin intermediul interfeelor nu este nclcat principiul ncapsulrii. n
decursul execuiei orice obiect poate fi nlocuit cu altul, atta timp ct
obiectele respective au acelai tip. n plus, datorit faptului c i
implementarea unui obiect este scris tot n termenii interfeelor altor obiecte,
dependenele de implementare vor fi substanial reduse;
prin compunerea obiectelor se obine urmatorul efect asupra unui proiect:
clasele sunt ncapsulate i focalizate asupra cte unui singur obiectiv, ceea ce
face ca ele, ca i ierarhiile lor, s aib dimensiuni mici i s fie mai uor de
gestionat. Un proiect bazat pe compunerea obiectelor se caracterizeaz printr-
un numr mai mare de obiecte i un numr mai mic de clase, iar comportarea
sistemului va depinde de relaiile dintre obiecte, n loc s fie definit ntr-o
clas.

Toate aceste aspecte conduc spre formularea celui de-al doilea principiu al proiectrii
OO:

PREFERAI COMPUNEREA OBIECTELOR MOTENIRII DE CLAS.

n mod ideal nu ar trebui create noi componente pentru a realiza reutilizarea. Pentru
obinerea funcionalitii dorite trebuie doar asamblate componentele prin intermediul
compoziiei obiectelor existente. n practic ns aceasta nu se poate realiza n
totalitate deoarece setul de componente disponibile nu este niciodat destul de bogat.
Reutilizarea prin motenire este mai uor de folosit pentru a face componente noi n
comparaie cu compunerea componentelor deja existente. De aceea motenirea i
compunerea obiectelor sunt folosite mpreun.

Experiena arat c adesea proiectanii folosesc motenirea n mod abuziv. De aceea

se recomand studiul i aplicarea abloanelor de proiectare, acestea bazndu-se foarte
mult pe compunerea obiectelor.

Delegarea

Reprezint o cale de aplicare a principiului compunerii obiectelor. ntr-o relaie de

delegare dou obiecte sunt implicate n rezolvarea unei cereri, i anume: obiectul care
recepteaz mesajul delegatorul - deleag execuia operaiei corespunztoare unui alt
obiect - delegat. Acest lucru este oarecum similar cu situaia n care subclasele
paseaz sarcina execuiei unor operaii claselor printe (este vorba despre operaiile
motenite i neredefinite). Dar, n timp ce clasa printe a unei subclase rmne aceeai
pe toat durata execuiei, n cazul delegrii obiectele delegat pot fi schimbate, cu
condiia s aib aceeai interfa.

Delegarea este considerat ca un ablon de proiectare fundamental, pe ea bazndu-se

foarte multe din celelalte abloane (de exemplu State, Visitor, Strategy, Mediator,
Chain of Responsibility, Bridge).

Principalul avantaj al delegrii este c face posibil foarte uor s se compun

comportari n timpul execuiei, inclusiv s se schimbe dinamic aceast compunere.

Dezavantajul, pe care l au i alte tehnici ce fac software-ul flexibil, este c software-

ul dinamic, parametrizat, este mai greu de neles dect software-ul static. n plus
exist i penaliti n timpul execuiei.

Motenirea i tipurile parametrizate

Tipurile parametrizate reprezint o alt tehnic de reutilizare a funcionalitii care nu

este strict legat de modelul orientat pe obiecte. Ele permit definirea de ctre
utilizatori a unui tip nou fr a specifica tipurile pe care acesta le folosete. Aceste
tipuri se vor furniza ca i parametrii unde se folosete acest tip parametrizat. De
exemplu un tip Lista poate fi parametrizat prin tipul elementelor coninute. Acesta
poate fi ntreg, ir de caractere, etc.
Printre limbajele care suport aceast tehnic se numr Ada, Eiffel (prin tipurile
generice) i C++ (prin template-uri).

Tipurile parametrizate ne ofer a treia cale pentru a compune comportarea n

sistemele OO. Exist diferene importante ntre aceste trei tehnici:
compunerea obiectelor permite modificarea n timpul execuiei a
comportamentului, dar presupune indirectare i, ca urmare, poate fi mai puin
eficient;
motenirea ofer posibilitatea de a utiliza implementri deja existente ale unor
operaii, dar i de a redefini n subclase operaiile respective;
 tipurile parametrizate permit modificarea tipurilor pe care o clas le
utilizeaz, dar, la fel ca i motenirea, sunt precizate la compilare i nu mai pot
fi modificate la execuie.

5.6 Structuri stabilite la compilare i structuri create la execuie

Structura unui program OO aflat n execuie amintete foarte puin cu structura

codului. Acesta din urm este ngheat n momentul compilrii i const dintr-un
ansamblu de clase aflate n relaii fixe de motenire. Structura la execuie const dintr-
o reea de obiecte aflate n continu schimbare i comunicare. De fapt cele dou tipuri
de structuri sunt aproape independente intre ele.

Exemplificm pe deosebirea dintre relaiile de agregare i asociere (sau cunoatere -

acquaintance) i cum se manifest acestea n timpul compilrii i execuiei. Agregarea
presupune ca un anumit obiect posed sau este responsabil fa de un alt obiect. n
general spunem despre un obiect c are sau este parte dintr-un alt obiect. Agregarea
implic faptul c un obiect agregat i proprietarul lui au durata de via comun.

Asocierea, numit i relaie de utilizare (de tip "using"), presupune c un obiect pur i
simplu tie de existena altui obiect. Cele dou obiecte asociate pot cere operaii unul
altuia dar nu sunt responsabili unul fa de altul. Asocierea este o relaie mai slab
dect agregarea i sugereaz o cuplare mai slab ntre obiecte.

Cele dou tipuri de relaii pot fi uor confundate din cauz c pot fi implementate n
mod asemntor. n C++ agregarea se poate implementa prin definirea de membrii
variabil ce sunt instane adevrate dar este mai folosit practica s o definim prin
pointeri sau referine la instane. Asocierea este implementat i ea prin pointeri i
referine.

De fapt agregarea i asocierea sunt determinate mai mult de intenia proiectantului

dect de mecanismele din limbaj. Distincia ntre ele este dificil de observat n codul
surs. Agregrile apar n numr mai mic, dar au un caracter mai stabil n timp.
Asocierile se fac i se refac mai frecvent, uneori stabilindu-se doar pe durata unei
operaii. Asocierile au un caracter mai dinamic, ceea ce le face greu de depistat n
codul surs.

Multe dintre abloanele de proiectare, mai ales cele care au domeniul de aplicare la
nivel de obiect, capteaz distincia dintre structurile stabilite la compilare i cele de la
execuie, n sensul c un specialist care cunoate abloanele de proiectare poate
detecta mai uor n codul surs structurile ce se vor crea la execuie.

6. Tema
1. Pornind de la introducerea n abloane de proiectare, dai exemple de aplicare a
urmtoarelor relaii:

agregare
 asociere
motenire de clas
motenire de interfa

Facei o apreciere n termeni de avantaje, dezavantaje i flexibilitate pentru aceste

relaii.

2. Sa se defineasca o ierarhie de clase pentru a modela mai multe tipuri de masini cu

motorizarile aferente. Masinile se impart in 2 categorii: automobile si camioane,
fiecare din acestea putand avea un motor Diesel sau pe baza de benzina.

Fiecare masina va avea o marca, o culoare si un numar de kilometrii parcursi pana in

prezent. Motorul are o marca si o serie unica.

Printr-un meniu se va permite realizarea urmatoarelor operatii:

- adaugare masina
- stergere masina
- afisarea masinilor
- schimbare tip motor masina selectata
- actualizare nr. km parcursi pentru masina specificata

Indicatie:
Se are in vedere construirea urmatoarei ierarhii de clase:
- clasa abstracta engine
- clasele derivate din engine -> dieselEngine si gasEngine
- clasa abstracta car
- clasele derivate din car -> automobile si truck

Intre engine si car exista e relatie de agregare.

Sa se discute motivatia ce sta la baza contruirii acestei ierarhii