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 o o

abloanele creaionale (creational patterns) privesc modul de creare al obiectelor. abloanele structurale (structural patterns) se refer la compoziia claselor sau al obiectelor. 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. 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 aplicare Clasa Creationale Structurale Comportamentale Interpreter Template Method Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

Factory Method Adapter (clasa) Interface Marker Interface Immutable Abstract Factory Builder Prototype Singleton Delegation Adapter (obiect) Bridge Composite Decorator Facade Flyweight Proxy

Obiect

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 angajeazte 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 (whitebox 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 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.

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 softwareul 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 dintro 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