SABLOANE DEARE (Design Patterns)

SABLOANE DE PROIECTARE (Design Patterns)

Scopul sabloanelor de proiectare este de a asista rezolvarea unor probleme similare cu unele deja intalnite si rezolvate anterior. Ele ajuta la crearea unui limbaj comun pentru comunicarea experientei despre aceste probleme si solutiile lor.

Cartea de referinta pentru sabloane de proiectare este "Design Patterns: Elements of Reusable    Object-Oriented Software", avand ca autori pe Erich Gamma, Richard Helm, Ralph Jonsopn si John Vlissides. Ea este adesea numita "Gang of Four Book" (GoF). Aparuta in 1994, ea s-a bucurat de un mare succes si a activat subiectul sabloanelor in dezvoltarea software, in ultimii ani acesta fiind tratat in numeroase conferinte, articole si carti.

Ce este un sablon de proiectare?

Un sablon de proiectare descrie o problema care se intalneste in mod repetat in proiectarea programelor si solutia generala pentru problema respectiva, astfel incat sa poata fi utilizata oricand dar nu in acelasi mod de fiecare data. Solutia este exprimata folosind clase si obiecte. Atat descrierea problemei cat si a solutiei sunt abstracte astfel incat sa poata fi folosite in multe situatii diferite.

In general, un sablon are 4 elemente esentiale:

Un nume prin care poate fi referit. Prin atribuirea de nume sabloanelor de proiectare se creaza un vocabular de proiectare, un limbaj comun de comunicare si documentare. Alegerea numelui este importanta deoarece el devine parte din vocabularul de proiectare.

Descrierea problemei. Se explica problema si contextul in care apare, cand trebuie aplicat sablonul.

Descrierea solutiei. Sunt descrise elementele care compun proiectul, relatiile dintre ele, responsabilitatile si colaborarile.

Consecintele aplicarii sablonului. Descrierea consecintelor este critica pentru evaluarea alternativelor de proiectare, intelegerea costurilor si a beneficiilor aplicarii unui sablon.

Un sablon de proiectare descrie de asemenea problemele de implementare ale sablonului si un exemplu de implementare a sablonului in unul sau mai multe limbaje de programare.

Sabloanele de proiectare pot fi generale sau specifice unui domeniu.

Descrierea sabloanelor de proiectare

In cartea de referinta (GoF), descrierea unui sablon este alcatuita din urmatoarele sectiuni:

Numele sablonului si clasificarea.

Intentia: O scurta definitie care raspunde la urmatoarele intrebari:

Ø     Ce realizeaza sablonul

Ø     Care este scopul sau

Ø     Ce problema de proiectare adreseaza

Alte nume prin care este cunoscut, daca exista.

Motivatia. Este descris un scenariu care ilustreaza o problema de proiectare si cum este rezolvata problema de clasele si obiectele sablonului. Scenariul ajuta in intelegerea descrierii mai abstracte care urmeaza.

Aplicabilitatea. Sunt descrise situatiile in care poate fi aplicat sablonul si cum pot fi recunoscute aceste situatii.

Structura. Este reprezentata grafic prin diagrame de clase si de interactiune folosind o notatie cum ar fi UML.

Participanti: clasele si obiectele care fac parte din sablonul de proiectare si responsabilitatile lor.

Colaborari: cum colaboreaza participantii pentru a-si indeplini responsabilitatile.

Consecintele: care sunt compromisurile si rezultatele utilizarii sablonului.

Implementare. Se precizeaza daca trebuie avute in vedere anumite tehnici de implementare si care sunt aspectele dependente de limbajul de implementare.

Exemplu de cod. Sunt date fragmente de cod care ilustreaza cum trebuie implementat sablonul in C++ sau Smalltalk.

Utilizari cunoscute. Sunt date exemple de sisteme reale in care se utilizeaza sablonul.

Sabloane corelate. Se specifica alte sabloane de proiectare corelate cu cel descris, care sunt diferentele, cu care alte sabloane ar trebui utilizat acesta.

Exemplu

Microsoft Foundation Classes (MFC) este un cadru de lucru (framework) general pentru dezvoltarea de aplicatii Windows. El genereaza aplicatii cu o arhitectura "Document-view", care separa datele aplicatiei de prezentarea lor. Datele sunt reprezentate printr-un obiect "Document" iar prezentarile sale sunt realizate de unul sau mai multe obiecte "Vedere". Avantajul acestei separari este faptul ca aceleasi date pot fi vizualizate in mai multe moduri. De exemplu, un set de date statistice pot fi reprezentate sub o forma textuala, o forma tabelara si una grafica. Atunci cand utilizatorul modifica una dintre vederi, celelalte doua vederi se modifica automat, deoarece toate cele trei vederi vizualizeaza aceleasi date.

Arhitectura document-vedere corespunde unui sablon de proiectare intalnit frecvent in mediile de dezvoltare a interfetelor utilizator grafice. Acest sablon are insa multe alte utilizari. El este util ori de cate ori se doreste decuplarea unui obiect de alte obiecte dependente de el. Sablonul se numeste Observer. In continuare se prezinta descrierea acestui sablon.

Numele: Observer

Intentia: Defineste o dependenta "unul la mai multi" intre obiecte, astfel incat atunci cand unul dintre obiecte isi schimba starea toate obiectele dependente sunt notificate si actualizate automat.

Alte nume prin care este cunoscut: Dependents, Publish-Subscribe.

Motivatia

Un efect secundar al partitionarii unui sistem in clase este necesitatea de a asigura consistenta intre obiectele corelate. Nu se doreste asigurarea acestei consistente printr-o cuplare puternica a claselor deoarece aceasta reduce reutilizabilitatea lor.

De exemplu, multe interfete utilizator grafice separa datele aplicatiei de prezentarile lor in interfata utilizator. In acest fel, clasele care definesc datele aplicatiei si cele care realizeaza prezentarea pot fi reutilizate independent. Ele pot fi folosite imprena astfel incat sa se obtina comportarea descrisa mai inainte. Sablonul Observer descrie cum sa se stabileasca relatiile intre aceste clase.

Obiectele cheie in acest sablon sunt subiect si observator (vezi figura). Un subiect poate avea orice numar de observatori dependenti. Toti observatorii sunt notificati ori de cate ori subiectul isi schimba starea. Ca raspuns la notificare, fiecare observator va interoga subiectul pentru a-si sincroniza starea cu starea subiectului.

Aplicabilitatea

Sablonul poate fi utilizat in oricare dintre urmatoarele situatii:

Ø     Atunci cand o abstractie are doua aspecte, unul dependent de celalalt. Daca aceste aspecte sunt incapsulate in obiecte separate, ele pot fi reutilizate independent.

Ø     Atunci cand modificarea unui obiect necesita modificarea altor obiecte si nu se stie cate obiecte trebuie sa fie modificate.

Ø     Atunci cand un obiect trebuie sa notifice alte obiecte fara a face presupuneri despre cine sunt aceste obiecte, deci cand se doreste ca obiectele sa nu fie strans cuplate.

Structura

Participantii

Subject

o        Cunoaste observatorii sai. Un obiect Subject poate fi observat de orice numar de obiecte Observer.

o        Furnizeaza o interfata pentru atasarea si detasarea obiectelor Observer.

Observer

o        Defineste o interfata pentru actualizarea obiectelor care trebuie sa fie notificate (anuntate) despre modificarile din subiect.

ConcreteSubject

o        Memoreaza starea de interes pentru obiectele ConcreteObserver.

o        Trimite o notificare observatorilor sai atunci cand i se schimba starea.

ConcreteObserver

o        Mentine o referinta la un obiect ConcreteSubject.

o        Memoreaza starea care trebuie sa ramana consistenta cu a subiectului.

o        Implementeaza interfata de actualizare a clasei Observer pentru a pastra starea sa consistenta cu a subiectului.

Colaborari

• ConcreteSubject notifica observatorii sai ori de cate ori are loc o schimbare care ar putea sa faca starea observatorilor inconsistenta cu starea sa.
• Dupa ce a fost informat de o schimbare la ConcreteSubject, un obiect ConcreteObserver il poate interoga pentru a obtine informatii. Obiectul ConcreteObserver utilizeaza aceste informatii pentru a-si adapta starea cu aceea a obiectului ConcreteSubject.

Urmatoarea diagrama de interactiune ilustreaza colaborarea dintre un subiect si doi observatori:

Un observator cere schimbarea starii subiectului. Acesta anunta toti observatorii ca trebuie sa-si actualizeze starea in concordanta cu noua sa stare. Pentru actualizarea starii, fiecare observator cere noua stare a subiectului.

Notificarea nu este intotdeauna facuta (apelata) de subiect. Poate fi apelata de un observator sau de un alt tip de obiect. Diferitele variatii sunt discutate in sectiunea Implementare.

9. Consecinte

Sablonul Observer permite definirea independenta a subiectilor si a observatorilor. Subiectii si observatorii pot fi reutilizati independent unii de altii. Pot fi adaugati noi observatori fara a modifica subiectul sau alti observatori

Alte aspecte ale utilizarii sablonului Observer sunt:

Ø     Cuplarea abstracta intre Subject si Observer

Subiectul are doar o lista de observatori care expun interfata simpla a clasei abstracte Observer. Subiectul nu cunoaste clasa concreta a niciunui observator. In acest fel, cuplarea intre subiecti si observatori este abstracta si minimala. Deoarece subiectul si observatorul nu sunt puternic cuplati, ei pot apartine la diferite nivele de abstractizare ale unui sistem

Ø     Suport pentru o comunicare broadcast.

Notificarea pe care o trimite subiectul nu necesita specificarea destinatiei. Ea este trimisa catre toate obiectele interesate care s-au inregistrat pentru ea. Subiectul nu trebuie sa stie cate obiecte interesate exista; singura sa responsabilitate este sa notifice observatorii sai. In acest fel, observatorii pot fi adaugati sau eliminati in orice moment. Este datoria observatorului sa trateze sau nu o notificare.

Ø     Actualizari neasteptate.

Deoarece observatorii nu stiu unul despre altul ei nu pot cunoaste costul unei modificari la subiect. Astfel o foarte mica modificare la subiect poate antrena un numar mare de actualizari la observatori si obiectele dependente de ei. Problema este agravata de faptul ca protocolul foarte simplu de actualizare nu da detalii despre ce anume s-a schimbat la subiect.

10. Implementare

Sunt prezentate mai multe aspecte legate de implementarea mecanismului de dependenta.

Ø     Asocirea subiectilor cu observatorii lor.

Cea mai simpla modalitate de a asocia un subiect cu observatorii sai este de a memora in subiect referinte catre observatori. Solutia poate fi costisitoare ca memorie daca sunt multi subiecti si putini observatori. Se poate economisi memorie in defavoarea timpului folosind o tabela de cautare asociativa (ex. hash table) pentru a reprezenta asocierea subiect-observator. Solutia creste costul accesarii observatorilor.

Ø     Un observator este asociat cu mai multi subiecti.

In acest caz este necesar sa se extinda interfata de actualizare (Update) astfel incat observatorul sa stie de la ce subiect primeste o notificare. De ex. subiectul se poate face cunoscut printr-un parametru al operatiei Update

Ø     Cine apeleaza operatia Notify, pentru anuntarea necesitatii actualizarii?

Sunt 2 optiuni:

Notify este apelata de operatiile de modificare a starii subiectului, dupa fiecare schimbare a starii.

Ø     Avantajul : nu este necesar apelul procedurii Notify de catre clienti (din afara sablonului).

Ø     Dezavantajul: modificari succesive ale starii subiectului vor genera actualizari succesive, ceea ce este ineficient.

Clientii sunt responsabili de apelul operatiei Notify, la momentul potrivit.

Ø     Avantajul: clientul va cere actualizarea dupa acumularea unui numar de modificari succesive.

Ø     Dezavantajul: devine responsabilitatea clientilor de a cere actualizarea, ceea ce poate conduce la erori, stiind ca unii clienti pot uita sa apeleze Notify.

Ø     Stergerea unui subiect nu trebuie sa lase in urma referinte catre el la observatorii sai.

O modalitate este ca subiectul care este sters sa-i anunte pe observatorii sai inainte de a disparea.

Ø     Inainte de o notificare trebuie ca starea subiectului sa fie consistenta, deoarece observatorii interogheaza starea curenta a subiectului in cursul actualizarii propriei lor stari.

Ø     Specificarea modificarilor de interes

Poate fi imbunatatita eficienta operatiei de actualizare extinzand interfata de inregistrare a observatorilor astfel inca fiecare observator sa poata specifica evenimentele de interes. Cand are loc un astfel de eveniment, subiectul informeaza numai observatorii care s-au inregistrat pentru acel eveniment. O modalitate de implementare utilizeaza notiunea de aspect pentru obiectele subiect:

void Subject::Attach(Observer*, Aspect& interest);

void Observer::Update(Subject*, Aspect& interest);

11. Exemplu de cod

Interfata Observer este definita printr-o clasa abstracta:

class Subject;

class Observer ;

Implementarea admite ca un observer sa aiba mai multi subiecti. Subiectul transmis operatiei Update permite observatorului sa determine care subiect si-a schimbat starea atunci cand el observa mai multi subiecti.

Interfata Subject    este definita prin urmatoarea clasa:

class Subject ;

void Subject::Attach (Observer* o)


void Subject::Detach (Observer* o)

void Subject::Notify ()
}

ClockTimer este un subiect concret pentru memorarea si actualizarea orei curente. El notifica observatorii la fiecare secunda.

class ClockTimer : public Subject ;

Operatia Tick este apelata de un timer intern la intervale regulate. Ea actualizeaza starea interna a obiectului ClockTimer (care nu este reprezentata in acest exemplu) si apeleaza Notify pentru a informa observatorii despre schimbare.

void ClockTimer::Tick ()

In continuare este definita clasa DigitalClock, care afiseaza timpul. Ea mosteneste interfata clasei Observer iar functionalitatea grafica de la o clasa a mediului de dezvoltare a interfetei utilizator, numita in acest exemplu, Widget.

class Widget;

class DigitalClock: public Widget, public Observer ;

DigitalClock::DigitalClock (ClockTimer* s)

DigitalClock::~ DigitalClock ()

void DigitalClock::Update (Subject* theChangedSubject)
}

void DigitalClock::Draw ()

In mod similar este definita o clasa AnalogClock

class AnalogClock : public Widget, public Observer ;

Se creaza un obiect AnalogClock si unul DigitalClock care vor afisa intotdeauna acelasi timp

ClockTimer* timer = new ClockTimer;
AnalogClock* analogClock = new AnalogClock(timer);
DigitalClock* digitalClock = new DigitalClock(timer);

12. Utilizari cunoscute

MFC, ET++ si Smalltalk utilizeaza sablonul Observer pentru separarea claselor Document (sau Models) si View.

Sabloane corelate

Mediator

Singleton