Sunteți pe pagina 1din 13

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 fle ibil pentru a rezista la noi cerine i probleme ce pot apare n timp. Proiectanii cu e perien refolosesc soluiile bune de c!te ori au ocazia. " ist grupri de clase sau obiecte care se repet n cele mai diferite sisteme. #cestea rezolv probleme specifice, folosirea lor fac proiectele mai fle ibile, mai elegante, reutilizabile. $n proiectant care stp!nete 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 e emplu pentru probleme de concuren, sisteme distribuite, programare n timp real, etc.

2. Clasificare
%abloanele utilizate n sistemele && pot fi clasificate ntr-o ierarhie dup cum urmeaz' (diomuri )ecanisme *adre +framewor,s-. $n idiom este legat de un anumit limba. de programare i reprezint o convenie general acceptat de utilizare a limba.ului respectiv. " emple tipice de idiomuri pot fi gsite n cadrul limba.elor */*00. 1eturnarea unei valori ntregi care s semnifice succesul sau eecul unei funcii este un idiom din * +adoptat i de *00, pe lang generarea e cepiilor-. (mportana acestui idiom const n faptul c el reprezint un anumit stil acceptat de comunitatea utilizatorilor de * i orice programator care citete o secven * recunoate imediat aceast convenie. 2nclcarea acestui idiom are drept consecin producerea de cod greu de neles, chiar dac este corect. Practic fiecare limba. de programare i are propriile sale idiomuri. 3a fel i o echip de programatori i poate stabili un set de obiceiuri, n funcie de e periena i cultura pe care le posed. Se poate spune c un idiom este o form de reutilizare pe scar mic. $n mecanism este o structur n cadrul cruia obiectele colaboreaz n vederea obinerii unui anumit comportament ce satisface o anumit cerin a problemei.

)ecanismele reprezint decizii de proiectare privind modul n care coopereaz coleciile de obiecte. "le se mai numesc i sabloane de proiectare +design patterns-. )a.oritatea sistemelor && includ mecanisme referitoare la' persistena obiectelor controlul stocrii controlul proceselor transmisia/recepia mesa.elor distribuirea i migrarea obiectelor conectarea n reele +networ,ing tranzacii evenimente modul de prezentare +4loo, 5 feel4- al aplicaiei. $n cadru reprezint o colecie de clase care ofer un set de servicii pentru un domeniu particular. *adrul e port un numr de clase i mecanisme pe care utilizatorii le pot adapta. *adrele sunt forme de reutilizare pe scar larg. *ele mai rsp!ndite tipuri de cadre sunt cele destinate crerii de interfee grafice.

3. Definiie
$n sablon reprezint o soluie comun a unei probleme ntr-un anumit conte t. (mportana abloanelor +standardelor- n construirea sistemelor comple e a fost de mult recunoscut n alte discipline. 2n cadrul comunitii proiectanilor de software && +orientate pe obiecte- ideea de a aplica abloane se pare c a fost inspirat de propunerea unui arhitect, *hristopher #le ander, care a lansat iniiativa folosirii unui limba. bazat pe sabloane pentru proiectarea cldirilor i a oraselor. #cesta afirma c' 46iecare 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 conte te diferite4. 7ei n domeniul sistemelor && soluiile sunt e primate 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 conte t dat. %abloanele de proiectare sunt o memorare pentru posteritate a e perienei n domeniul proiectrii sistemelor &&. $n ablon este descris de patru elemente' Nume' folosete pentru identificare8 descrie sintetic problema rezolvat de ablon i soluia. Problema' descrie c!nd se aplic ablonul8 se descrie problema i conte tul. 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. #cestea pot privi impactul asupra fle ibilitii, e tensibilitii sau portabilitii sistemului, dup cum pot s se refere la aspecte ale implementrii sau limba.ului de programare utilizat. *ompromisurile 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. 7eoarece e ist multe abloane de proiectare este necesar o anumit clasificare a lor n vederea alctuirii unui catalog. *riterii 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 +fi ate 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 flu uri 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. 2n tabelul de mai .os sunt incluse cele mai importante abloane, clasificate dup criteriile enumerate anterior' Scop 7omeniu de aplicare *reationale Structurale *omportamentale

*lasa

6actor9 )ethod #dapter +clasa(nterface )ar,er (nterface (mmutable #bstract 6actor9 ;uilder Protot9pe Singleton 7elegation #dapter +obiect;ridge *omposite 7ecorator 6acade 6l9weight Pro 9

(nterpreter :emplate )ethod *hain of 1esponsibilit9 *ommand (terator )ediator )emento &bserver State Strateg9 <isitor

&biect

5. Rolul abloanele de proiectare n rezol!area proble"ele de proiectare


%abloanele de proiectare rezolv multe din problemele cu care se confrunt proiectanii. *!teva din aceste probleme sunt urmatoarele'

5.1 Gsirea obiectelor adecvate


$n obiect, care intr n alctuirea programelor &&, mpacheteaz at!t date, c!t i metode (operaii) ce opereaz asupra datelor. &biectul e ecut o operaie c!nd primete o cerere (mesaj) de la un client. )esa.ele reprezint singura cale prin care un obiect este determinat s e ecute o operaie, n timp ce operaiile sunt singurul mod de a modifica datele interne ale obiectului. 7in cauza acestor restricii starea intern a obiectului se spune c este ncapsulat' ea nu poate fi accesat direct, iar reprezentarea ei este invizibil dinspre e teriorul obiectului. Partea dificil n proiectarea unui sistem && este descompunerea sistemului n obiecte. #ceasta deoarece procesul este influenat de mai muli factori care acioneaz adesea n mod contradictoriu' ncapsularea, granularitatea, dependenele, fle ibilitatea, performanele, evoluia, gradul de reutilizare etc. " ist mai multe metodologii &&' unele se concentreaz pe substantivele i verbele e trase 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. )ulte din obiectele care apar la proiectare provin din modelul creat n faza de analiz. 3a proiect se vor adauga ns i clase care nu au coresponden n lumea real. $nele din aceste clase sunt de nivel primar +de e emplu tablourile-, altele au un nivel de abstractizare mai ridicat. 7e e emplu sablonul *omposition introduce o abstracie

menit s asigure tratarea uniform a obiectelor care nu au un corespondent fizic. )odelarea strict a lumii reale va duce la un sistem ce reflect realitatea curent, dar nu neaprat i pe cea viitoare. #bstraciunile identificate n timpul proiectrii sunt eseniale n obinerea unui sistem fle ibil. %abloanele ne pot a.uta n identificarea unor abstraciuni mai puin evidente i a obiectelor care le pot reprezenta. 7e e emplu obiectele care reprezint procese sau algoritmi nu apar n natur, dar ele nu pot lipsi dintr-un proiect. %ablonul Strateg9 descrie modul de implementare a unor familii interschimbabile de algoritmi. %ablonul State reprezint fiecare stare a unei entiti sub forma unui obiect. #semenea obiecte sunt rareori descoperite n timpul analizei sau chiar a stadiului incipient al proiectrii.

5.2 Determinarea granularitii obiectelor


&biectele ce compun un sistem pot varia enorm ca mrime i ca numr. "le pot reprezenta practic orice ncep!nd de la componente hardware p!n la aplicaii ntregi. *um decidem ce ar trebui sa fie un obiect= " ist abloane care acoper i acest aspect. #stfel, ablonul 6acade descrie modul n care subsisteme complete pot fi reprezentate ca obiecte, ablonul 6l9weight arat cum se poate gestiona un numr uria de obiecte la nivelurile cele mai fine de granularitate. #lte abloane descriu cile prin care un obiect poate fi descompus n obiecte mai mici. #bstract 6actor9 i ;uilder reprezint obiecte a cror unic responsabilitate este crearea de alte obiecte. <isitor i *ommand reprezint obiecte a cror unic responsabilitate este implementarea unui mesa. ctre alt obiect sau grup de obiecte.

5.3 peci!icarea inter!eelor obiectelor


Pentru fiecare operaie declarat ntr-un obiect se precizeaz numele, obiectele pe care le ia ca parametrii i valoarea returnat8 aceste elemente formeaz semntura operaiei. )ulimea tuturor semnturilor corespunztoare operaiilor dintr-un obiect reprezint interfaa obiectului. (nterfaa unui obiect descrie complet setul mesa.elor care pot fi trimise spre obiectul respectiv. $n tip este un nume utilizat pentru a referi o anumit interfa. #stfel, vom spune despre un obiect c este de tipul Window dac el accept toate mesa.ele corespunztoare operaiilor definite n interfaa numit Window. *a 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. 7e asemenea, mai multe obiecte pot parta.a un anumit tip comun, daca interfeele lor includ tipul respectiv. (nterfeele pot s conin, la r!ndul lor, alte interfee ca submulimi. #v!nd dou tipuri, T1 i T2, vom spune c T1 este subtip al lui T2 dac interfaa T1 include interfaa T2. 2n acest caz T2 este supertip al lui T1. )ai spunem ca T1 motenete interfaa T2. (nterfeele sunt lucruri fundamentale n sistemele &&. &biectele sunt cunoscute doar

prin intermediul interfetelor lor. & interfa nu d nici un detaliu relativ la implementarea unui obiect, iar obiecte distincte pot implementa n mod diferit o aceeasi cerere. #ltfel spus, dou obiecte av!nd implementri complet diferite pot avea interfee identice. *!nd o cerere este trimis unui obiect, operaia care se va e ecuta depinde de' cerere obiectul care receptioneaz cererea. &biecte diferite care pot recepiona cereri identice pot avea implementri diferite ale operaiilor ce vor satisface cererile respective. #socierea unei cereri cu un obiect i cu o operaie a obiectului la momentul e ecuiei se numete asociere (le are) dinamic (d!namic bindin ). #socierea 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 bun8 obiecte av!nd interfee identice pot fi substituite unul altuia la e ecutie8 aceast posibilitate de substituire se mai numete polimorfism. Polimorfismul este un concept esenial n cadrul tehnologiei orientate pe obiecte. "l permite' ca un obiect client s nu aib nevoie s cunoasc altceva despre alte obiecte dec!t c posed o anumit interfa8 simplificarea definiiei clienilor8 decuplarea obiectelor unele de altele8 ca la e ecuie obiectele s-i modifice relaiile dintre ele. 2n acest conte t, abloanele de proiectare ne a.ut la' definirea interfeelor8 identificarea elementelor care >$ trebuie s apar ntr-o interfa. #stfel, ablonul )emento 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." peci!icarea implementrii obiectelor


(mplementarea unui obiect este definit prin intermediul clasei obiectului. *lasa unui obiect specific datele interne ale obiectului i definiiile operaiilor pe care acesta le poate e ecuta. &biectele sunt create prin instanierea unei clase8 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. & clas poate fi instaniat de mai multe ori, n felul acesta rezult!nd mai multe e emplare similare de obiecte. Pe baza unor clase e istente se pot defini noi clase, folosind motenirea claselor. & subclas motenete de la una sau mai multe clase printe +superclase- toate datele i operaiile definite n acestea din urm. &biectele instane ale subclasei vor

conine toate datele definite n subclasa i n clasele printe putea e ecuta toate operaiile definite n subclasa i n clasele printe.

& clas abstract are drept scop principal definirea unei interfee comune pentru subclasele sale. (mplementarea operaiilor unei clase abstracte este pasat parial sau n ntregime subclaselor sale. 7e aceea, o clas abstract nu poate fi instaniat. &peraiile declarate ntr-o clas abstract, dar neimplementate se numesc operaii abstracte. *lasele care nu sunt abstracte se numesc clase concrete. & subclas poate detalia sau redefini comportamentul claselor printe. )ai 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. & clasa mi"in este o clas care are drept scop oferirea unei interfee sau a unei funcionaliti opionale altor clase. "a 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.

#$%$& 'otenirea claselor i motenirea interfeelor


"ste important s inelegem diferena ntre clasa unui obiect i tipul obiectului. *lasa definete starea intern a obiectului i implementarea operaiilor lui. :ipul obiectului se refer doar la interfaa obiectului - setul cererilor la care obiectul poate rspunde. $n obiect poate avea mai multe tipuri, iar obiecte de clase diferite pot avea acelai tip. 7esigur c ntre clas i tip e ist o str!ns legtura' prin faptul c o clas definete operaiile pe care un obiect le poate e ecuta, automat ea definete i tipul obiectului. *!nd spunem c un obiect este instan a unei clase, aceasta nseamn c obiectul posed interfaa definit de clasa respectiv. $n limba. ca *00 folosete clasele pentru a specifica tipul obiectului i implementarea. "ste de asemenea important s inelegem diferena dintre motenirea de clas i motenirea de interfa +subtipizare-. )otenirea de clas presupune c implementarea unui obiect este definit n termenii implementrii altui obiect. *u alte cuvinte, ea reprezint un mecanism de reutilizare +parta.are- a reprezentrii i a codului. )otenirea de interfa +subt9ping- este un mecanism prin care un obiect poate fi utilizat n locul altuia. "ste destul de uor de confundat aceste concepte ntre ele deoarece ma.oritatea limba.elor de programare && nu le disting n mod e plicit. 7e e emplu n *00 motenire nseamn at!t motenire de clas, c!t i de interfa. & 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-8 motenirea de clas poate fi modelat prin derivarea privat a unei clase.

)ulte dintre abloanele de proiectare se bazeaz pe aceast distincie. 7e e emplu obiectele dintr-un C(ain of )esponsibilit! trebuie s aib un tip comun, fr ns a avea i implementarea comun. 2n cadrul ablonului Composite, *omponent definete o interfa comun, n timp ce *omposite definete o implementare comun. %abloanele Command* +bserver* State i Strate ! sunt adesea implementate cu a.utorul claselor abstracte.

#$%$, Pro ramarea prin interfee i nu prin implementri


)otenirea de clas este n esen un mecanism care permite' e tinderea funcionalitii unei aplicaii prin reutilizarea funcionalitii din clasele printe8 definirea rapid a unui nou fel de obiect, n termenii unuia de.a e istent8 obinerea unor noi implementri aproape fr efort, prin preluarea unei mari pri din ceea ce avem nevoie de la clase e istente. 1eutilizarea 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. *lasele derivate dintr-o clas abstract vor parta.a interfaa acelei clase. Subclasele vor aduga sau vor redefini operaii, dar nu vor ascunde operaii ale clasei printe. 2n felul acesta toate subclasele vor putea rspunde la cererile corespunztoare interfeei clasei abstracte printe. " ist doua avanta.e ale manipulrii obiectelor prin intermediul interfeelor definite n clasele abstracte' clienii nu trebuie s tie tipurile particulare ale obiectelor utilizate, at!ta timp c!t obiectele respective sunt compatibile cu interfaa pe care clienii o ateapt8 clienii nu trebuie s tie care sunt clasele care implementeaz obiectele respective, tiu doar despre clasele abstracte care definesc interfaa. :oate acestea reduc substanial dependenele dintre subsisteme, permit!nd formularea urmtorului principiu al proiectrii &&' PROGRAMAI N TERMENI DE INTERFEE, NU DE IMPLEMENTRI. >u declara variabile ca fiind instane ale unor clase concrete, mai degrab anga.eazte s foloseti o interfa definit printr-o clas abstract. *!nd este necesar instanierea unor clase concrete, se recomand aplicarea abloanelor creaionale +#bstract 6actor9, ;uilder, 6actor9 )ethod, Protot9pe, Singleton- care permit abstractizarea procesului de creare a obiectelor. 2n felul acesta se realizeaz o asociere a unei interfee cu implementrile ei transparent la momentul instanierii.

5.5 #ecanisme ale reutili$rii

Problema este cum obinem un software fle ibil i reutilizabil folosind concepte ca obiect, clas, interfa, motenire. %abloanele constituie un rspuns. 'otenirea i compunerea obiectelor *ele mai cunoscute tehnici de reutilizare a funcionalitii n cadrul sistemelor && sunt motenirea de clas i asamblarea sau compunerea obiectelor +ob.ect composition-. )otenirea de clas este cunoscut i sub numele de reutilizare tip cutie alb +whitebo reuse- deoarece n ma.oritatea cazurilor o parte din starea intern a claselor printe este vizibil n subclase. #samblarea obiectelor reprezint o tehnic de obinere a unei funcionaliti noi prin asamblarea sau compunerea unor obiecte av!nd interfee bine definite. :ehnica este cunoscut sub numele de reutilizare tip cutie nea r +blac,-bo reuse- deoarece obiectele care se asambleaz nu i cunosc unul altuia starea intern, ele apar unul fa de altul ca nite cutii negre. #mbele tehnici au avanta.e i dezavanta.e. )otenirea de clas se caracterizeaz prin urmtoarele +avanta.e-' este definit static la compilare i poate fi specificat direct, fiind suportat e plicit de limba.ele de programare8 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. 2n secvena *00 de mai .os este ilustrat sintetic aceast situaie' cla Pa!"n# $ %%. . . &'(lic) *oid O&"!a#ion1+ ,*oid O&"!a#ion2+ ,- %%a&"l"a.a /"#oda O&"!a#ion1 0cla 12ild) &'(lic Pa!"n# $ %%. . . &'(lic) *oid O&"!a#ion1+ ,- %%!"d"3in" #" O&"!a#ion1 %%O&"!a#ion2 !a/an" c"a /o #"ni#a 0*oid aF'nc#ion+ , $ Pa!"n# &12ild c&.O&"!a#ion2+ ,c.O&"!a#ion2+ ,%%d"oa!"c" O&"!a#ion2 a&"l"a.a O&"!a#ion1, /"#oda " *a co/&o!#a %%di3"!i# &"n#!' c"l" 2 o(i"c#" 0

7ezavanta.e'

implementarea motenit de la clasele printe nu poate fi modificat n momentul e ecuiei8 cel mai adesea clasele printe definesc cel puin parial reprezentarea fizic a subclaselor lor, deci subclasele au acces la detalii ale implementrii superclaselor. 7e aceea se mai spune c motenirea de clas ncalc principiile ncapsulrii8 modificrile aduse implementrii unei superclase vor fora subclasele s se modifice i ele. 7ependenele de implementare pot cauza probleme atunci c!nd se ncearc reutilizarea subclaselor' dac anumite aspecte ale implementrii motenite nu corespund necesitilor aplicaiei clasa printe trebuie rescris sau nlocuit. #ceast dependen limiteaz fle ibilitatea i, n ultim instan reutilizarea. & soluie n acest caz ar fi aplicarea motenirii de la clase abstracte, deoarece ele includ implementare n mic msur.

*ompunerea obiectelor se caracterizeaz prin' se defineste n mod dinamic, la e ecuie, prin faptul c anumite obiecte primesc referine ale altor obiecte8 necesit ca obiectele s-i respecte unul altuia interfaa, ceea ce presupune c interfeele s fie proiectate astfel nc!t s nu mpiedice utilizarea unui obiect n combinaie cu mai multe tipuri de obiecte. 7eoarece obiectele sunt accesate doar prin intermediul interfeelor nu este nclcat principiul ncapsulrii. 2n decursul e ecuiei orice obiect poate fi nlocuit cu altul, at!ta timp c!t obiectele respective au acelai tip. 2n plus, datorit faptului c i implementarea unui obiect este scris tot n termenii interfeelor altor obiecte, dependenele de implementare vor fi substanial reduse8 prin compunerea obiectelor se obine urmatorul efect asupra unui proiect' clasele sunt ncapsulate i focalizate asupra c!te unui singur obiectiv, ceea ce face ca ele, ca i ierarhiile lor, s aib dimensiuni mici i s fie mai uor de gestionat. $n proiect bazat pe compunerea obiectelor se caracterizeaz printrun 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. :oate aceste aspecte conduc spre formularea celui de-al doilea principiu al proiectrii &&' PREFERAI 1OMPUNEREA O4IE1TELOR MO5TENIRII DE 1LA6. 2n mod ideal nu ar trebui create noi componente pentru a realiza reutilizarea. Pentru obinerea funcionalitii dorite trebuie doar asamblate componentele prin intermediul compoziiei obiectelor e istente. 2n practic ns aceasta nu se poate realiza n totalitate deoarece setul de componente disponibile nu este niciodat destul de bogat. 1eutilizarea prin motenire este mai uor de folosit pentru a face componente noi n comparaie cu compunerea componentelor de.a e istente. 7e aceea motenirea i compunerea obiectelor sunt folosite mpreun. " periena arat c adesea proiectanii folosesc motenirea n mod abuziv. 7e aceea

se recomand studiul i aplicarea abloanelor de proiectare, acestea baz!ndu-se foarte mult pe compunerea obiectelor. Dele area 1eprezint o cale de aplicare a principiului compunerii obiectelor. 2ntr-o relaie de delegare dou obiecte sunt implicate n rezolvarea unei cereri, i anume' obiectul care recepteaz mesa.ul ? delegatorul - deleag e ecuia operaiei corespunztoare unui alt obiect - delegat. #cest lucru este oarecum similar cu situaia n care subclasele paseaz sarcina e ecuiei unor operaii claselor printe +este vorba despre operaiile motenite i neredefinite-. 7ar, n timp ce clasa printe a unei subclase rm!ne aceeai pe toat durata e ecuiei, n cazul delegrii obiectele delegat pot fi schimbate, cu condiia s aib aceeai interfa. 7elegarea este considerat ca un ablon de proiectare fundamental, pe ea baz!ndu-se foarte multe din celelalte abloane +de e emplu State, <isitor, Strateg9, )ediator, *hain of 1esponsibilit9, ;ridge-. Principalul avanta. al delegrii este c face posibil foarte uor s se compun comportari n timpul e ecuiei, inclusiv s se schimbe dinamic aceast compunere. 7ezavanta.ul, pe care l au i alte tehnici ce fac software-ul fle ibil, este c softwareul dinamic, parametrizat, este mai greu de neles dec!t software-ul static. 2n plus e ist i penaliti n timpul e ecuiei. 'otenirea i tipurile parametri-ate :ipurile parametrizate reprezint o alt tehnic de reutilizare a funcionalitii care nu este strict legat de modelul orientat pe obiecte. "le permit definirea de ctre utilizatori a unui tip nou fr a specifica tipurile pe care acesta le folosete. #ceste tipuri se vor furniza ca i parametrii unde se folosete acest tip parametrizat. 7e e emplu un tip 3ista poate fi parametrizat prin tipul elementelor coninute. #cesta poate fi ntreg, ir de caractere, etc. Printre limba.ele care suport aceast tehnic se numr #da, "iffel +prin tipurile generice- i *00 +prin template-uri-. :ipurile parametrizate ne ofer a treia cale pentru a compune comportarea n sistemele &&. " ist diferene importante ntre aceste trei tehnici' compunerea obiectelor permite modificarea n timpul e ecuiei a comportamentului, dar presupune indirectare i, ca urmare, poate fi mai puin eficient8 motenirea ofer posibilitatea de a utiliza implementri de.a e istente ale unor operaii, dar i de a redefini n subclase operaiile respective8 tipurile parametri-ate 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 e ecuie.

5.% tructuri stabilite la compilare &i structuri create la e'ecuie


Structura unui program && aflat n e ecuie amintete foarte puin cu structura codului. #cesta din urm este ngheat n momentul compilrii i const dintr-un ansamblu de clase aflate n relaii fi e de motenire. Structura la e ecuie const dintro reea de obiecte aflate n continu schimbare i comunicare. 7e fapt cele dou tipuri de structuri sunt aproape independente intre ele. " emplificm pe deosebirea dintre relaiile de agregare i asociere +sau cunoatere ac@uaintance- i cum se manifest acestea n timpul compilrii i e ecuiei. #gregarea presupune ca un anumit obiect posed sau este responsabil fa de un alt obiect. 2n general spunem despre un obiect c are sau este parte dintr-un alt obiect. #gregarea implic faptul c un obiect agregat i proprietarul lui au durata de via comun. #socierea, numit i relaie de utilizare +de tip 4using4-, presupune c un obiect pur i simplu tie de e istena altui obiect. *ele dou obiecte asociate pot cere operaii unul altuia dar nu sunt responsabili unul fa de altul. #socierea este o relaie mai slab dec!t agregarea i sugereaz o cuplare mai slab ntre obiecte. *ele dou tipuri de relaii pot fi uor confundate din cauz c pot fi implementate n mod asemntor. 2n *00 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. #socierea este implementat i ea prin pointeri i referine. 7e fapt agregarea i asocierea sunt determinate mai mult de intenia proiectantului dec!t de mecanismele din limba.. 7istincia ntre ele este dificil de observat n codul surs. #gregrile apar n numr mai mic, dar au un caracter mai stabil n timp. #socierile se fac i se refac mai frecvent, uneori stabilindu-se doar pe durata unei operaii. #socierile au un caracter mai dinamic, ceea ce le face greu de depistat n codul surs. )ulte 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 e ecuie, n sensul c un specialist care cunoate abloanele de proiectare poate detecta mai uor n codul surs structurile ce se vor crea la e ecuie.

%. (ema
A. Pornind de la introducerea n abloane de proiectare, dai e emple de aplicare a urmtoarelor relaii'

agregare asociere motenire de clas motenire de interfa

6acei o apreciere n termeni de avanta.e, dezavanta.e i fle ibilitate pentru aceste relaii. B. Sa se defineasca o ierarhie de clase pentru a modela mai multe tipuri de masini cu motorizarile aferente. )asinile se impart in B categorii' automobile si camioane, fiecare din acestea putand avea un motor 7iesel sau pe baza de benzina. 6iecare masina va avea o marca, o culoare si un numar de ,ilometrii parcursi pana in prezent. )otorul 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. ,m parcursi pentru masina specificata (ndicatie' Se are in vedere construirea urmatoarei ierarhii de clase' - clasa abstracta engine - clasele derivate din engine -C diesel"ngine si gas"ngine - clasa abstracta car - clasele derivate din car -C automobile si truc, (ntre engine si car e ista e relatie de agregare. Sa se discute motivatia ce sta la baza contruirii acestei ierarhii

S-ar putea să vă placă și