Sabloane de Proiectare(Design Patterns)

Barbu Catalin

Balauca Dragos

Craciun George

Ismail Birkan

Muntean Andrada

Cuprins:

1. Introducere – Barbu Catalin2. Definiţii si generalitati – Barbu Catalin

3. Criterii de clasificarea sabloanelor de proiectare:3.1. Sabloane creationale - Balauca Dragos

3.2. Sabloane structural - Craciun George3.3. Sabloane comportamentale - Craciun George

4. Rolul şabloanele de proiectare în rezolvarea problemele de proiectare - Balauca Dragos

5. Mecanisme ale reutilizarii - Ismail Birkan6. XML generalitati - Ismail Birkan

6.1. Pattern-uride proiectare a structurii XML - Muntean Andrada6.2. Pattern-uri de proiectare a aplicaţiilor utilizând XML - Muntean Andrada

1. Introducere

Proiectarea software-ului orientat spre obiecte este grea,iar proiectarea software-ului orientat spre obiecte reutilizabil este si mai grea.Designul trebuie sa fie specific problemei in cauza, dar de asemenea suficient de general pentru a putea rezolva probleme si cerinte viitoare. Sabloanele de proiectare faciliteaza reutilizarea solutiilor si arhitecturilor de succes. Exprimarea tehnicilor testate sub forma de sabloane de proiectare le face mai accesibile programatorilor de sisteme noi. Acestea pot imbunatati documentatia si intretinerea sistemelor existente,asigurand o specificatie explicita a interactiunii claselor si obiectelor si a scopurilor acestora.

Experienta acumulata in realizarea unor aplicatii cu clase a condus la recunoasterea si inventarierea unor scheme (sabloane) de proiectare (“Design Patterns”), adica a unor grupuri de clase si obiecte care coopereaza pentru realizarea unor functii. In cadrul acestor scheme exista clase care au un anumit rol in raport cu alte clase si care au primit un nume ce descrie acest rol; astfel exista clase iterator, clase observator, clase “fabrica” de obiecte, clase adaptor. Dincolo de detaliile de implementare se pot identifica clase cu aceleasi responsabilitati in diferite aplicatii.

Numele sablonului este o reprezentare pe care o putem utiliza pentru a descrie in doua-trei cuvinte problema de proiectare,solutiile si consecintele ei. Numirea unui sablon mareste imediat vocabularul nostru de proiectare,Ne permite sa lucram cu un nivel mai inalt de abstractizare.Interpretarea a ceea ce este si ce nu este un sablon depinde de punctul de vedere al unei persoane.Sablonul unui programator poate fi pentru altul un element de constructie de baza.Acestea nu se refera la proiectare cum ar fi liste legate sau tabele de dispersie,al caror cod poate fi introdus in clase si reutilizat ca atare.Un sablon de proiectare denumeste, abstractizeaza si identifica aspectele cheie ale unei structuri comune de proiectare pe care o face utila pentru crearea unui design orientat spre obiecte.

Trebuie remarcat ca si clasele predefinite JDK au evoluat de la o versiune la alta in sensul extinderii functionalitatii si aplicarii unor scheme de proiectare reutilizabile. Clasele JDK (in special clase JFC) care urmeaza anumite scheme de proiectare au primit nume care sugereaza rolul clasei intr-un grup de clase ce interactioneaza : clase iterator, clase adaptor, clase “model”.

Definitii posibile pentru schemele de proiectare folosite in aplicatii cu clase:

- Solutii optime pentru probleme comune de proiectare.

- Abstractii la un nivel superior claselor, obiectelor sau componentelor.

- Scheme de comunicare (de interactiune) intre obiecte.

Argumentul principal in favoarea studierii si aplicarii schemelor de clase este acela ca aplicarea acestor scheme conduce la programe mai usor de modificat. Aceste obiective pot fi atinse in general prin clase (obiecte) “slab” cuplate, care stiu cat mai putin unele despre altele.

2. Definitii si Generalitati

Principalele recomandari care rezulta din analiza schemelor de proiectare si aplicatiilor sunt:

- Compozitia (agregarea) este preferabila in raport cu derivarea.

- Proiectarea cu interfete si clase abstracte este preferata fata de proiectarea cu clase concrete, pentru ca permite separarea utilizarii de implementare.

- Este recomandata crearea de clase si obiecte suplimentare, cu rol de intermediari, pentru decuplarea unor clase cu roluri diferite.

O clasificare uzuala a schemelor de proiectare distinge trei categorii:

- Scheme “creationale“ (Creational patterns) prin care se genereaza obiectele necesare.

- Scheme structurale (Structural patterns), care grupeaza mai multe obiecte in structuri mai mari.

- Scheme de interactiune (Behavioral patterns), care definesc comunicarea intre clase.

Cea mai folosita schema de creare obiecte in Java este metoda fabrica, prezenta in mai multe pachete, pentru crearea de diverse obiecte. Se mai foloseste schema pentru crearea de clase cu obiecte unice ('Singleton') in familia claselor colectie.Schemele structurale folosite in JDK sunt clasele “decorator” din pachetul “java.io” si clasele “adaptor” din “javax.swing”. Schemele de interactiune prezente in JDK sunt clasele iterator (“java.util”) si clasele observator si observat (“java.util”) extinse in JFC la schema cu trei clase MVC ( Model-View-Controller).

Clase si metode “fabrica” de obiecte

In cursul executiei un program creeaza noi obiecte, care furnizeaza aplicatiei datele si metodele necesare. Majoritatea obiectelor sunt create folosind operatorul new, pe baza ipotezei ca exista o singura clasa, care nu se mai modifica, pentru aceste obiecte.

O solutie mai flexibila pentru crearea de obiecte este utilizarea unei fabrici de obiecte, care lasa mai multa libertate in detaliile de implementare a unor obiecte cu comportare predeterminata.

O fabrica de obiecte (“Object Factory”) permite crearea de obiecte de tipuri diferite, dar toate subtipuri ale unui tip comun (interfata sau clasa abstracta).

O fabrica de obiecte se poate realiza in doua forme:

- Ca metoda fabrica (de obicei metoda statica) dintr-o clasa, care poate fi clasa abstracta ce defineste tipul comun al obiectelor fabricate. Aceasta solutie se practica atunci cand obiectele fabricate nu difera mult intre ele.

- Ca o clasa fabrica, atunci cand exista diferente mai mari intre obiectele fabricate.

Alegerea (sub)tipului de obiecte fabricate se poate face fie prin parametri transmisi metodei fabrica sau constructorului de obiecte “fabrica”, fie prin fisiere de proprietati (fisiere de configurare).

Metode si clase fabrica pot fi intalnite in diverse pachete din JSE (Java Standard Edition ) si, mai ales, in JEE (Java Enterprise Edition).

Putem deosebi doua situatii in care este necesara utilizarea unei metode “fabrica” in locul operatorului new:

- Pentru a evita crearea de obiecte identice (economie de memorie si de timp); metoda fabrica va furniza la fiecare apel o referinta la un obiect unic si nu va instantia clasa. Rezultatul metodei este de un tip clasa instantiabila.

- Pentru ca tipul obiectelor ce trebuie create nu este cunoscut exact de programator, dar poate fi dedus din alte informatii furnizate de utilizator, la executie. Rezultatul metodei este de un tip interfata sau clasa abstracta, care include toate subtipurile de obiecte fabricate de metoda (fabrica 'polimorfica').

Utilizarea fabricilor de obiecte poate fi privita ca un pas inainte pe calea separatiei interfata-implementare, in sensul ca permite oricate implementari pentru o interfata, cu orice nume de clase si cu orice date initiale necesare fabricarii obiectelor.

O metoda fabrica poate fi o metoda statica sau nestatica. Metoda fabrica poate fi apelata direct de programatori sau poate fi apelata dintr-un constructor, ascunzand utilizatorilor efectul real al cererii pentru un nou obiect.

Clasele de obiecte fabrica pot fi la randul lor subtipuri ale unui tip comun numit fabrica abstracta (“AbstractFactory”). Altfel spus, se folosesc uneori fabrici de fabrici de obiecte.

Uneori se stie ce fel de obiecte sunt necesare, dar nu se stie exact cum trebuie realizate aceste obiecte (cum trebuie implementata clasa); fie nu exista o singura clasa posibila pentru aceste obiecte, fie existau anterior furnizori diferiti pentru aceste clase si se incearca unificarea lor, fie sunt anticipate si alte implementari ale unei clase in viitor, dar care sa nu afecteze prea mult aplicatiile existente.

Portabilitatea dorita de Java cere ca operatii (cereri de servicii) sa fie programate uniform, folosind o singura interfata API intre client (cel care solicita operatia) si furnizorul de servicii (“provider”), indiferent de modul cum sunt implementate acele servicii, sau de faptul ca exista mai multe implementari.

Astfel de interfete API exista pentru servicii prin natura lor diversificate ca mod de realizare: pentru acces la orice baza de date relationala (JDBC), pentru comunicarea prin mesaje (JMS, SAAJ), pentru analiza de fisiere XML etc.

Pentru acces la servicii oferite de un server se creeaza un obiect “conexiune”, iar operatiile ulterioare se exprima prin apeluri de metode ale obiectului “conexiune”. Diversitatea apare in modul de creare a obiectului conexiune, care nu se poate face prin instantierea unei singure clase, cu nume si implementare cunoscute la scrierea aplicatiei. Obiectele conexiune sunt create de fabrici de conexiuni, care ascund particularitati de implementare ale acestor obiecte. Toate obiectele conexiune trebuie sa prevada anumite metode, deci sa respecte un contract cu utilizatorii de conexiuni. Fabricile de conexiuni pot fi uneori si ele foarte diferite si sa necesite parametri diferiti (ca tip si ca utilizare); de aceea, obiectul fabrica de conexiuni nu este obtinut prin instantierea unei singure clase ci este fabricat intr-un fel sau altul.

Clase cu rol de comanda (actiune)

Schema numita 'Command' permite realizarea de actiuni (comenzi) multiple si realizeaza decuplarea alegerii operatiei executate de locul unde este emisa comanda. Ea foloseste o interfata generala, cu o singura functie, de felul urmator:

public interface Command

In Swing exista mai multe interfete 'ascultator' corespunzatoare interfetei “Command”. Exemplu:

public interface ActionListener

Un obiect dintr-o clasa ascultator este un obiect 'comanda' si realizeaza o actiune. El constituie singura legatura dintre partea de interfata grafica a aplicatiei si partea de logica specifica aplicatiei (tratarea evenimentelor). Se realizeaza astfel decuplarea celor doua parti, ceea ce permite modificarea lor separata si chiar selectarea unei anumite actiuni in cursul executiei.

Pentru a compara solutia schemei 'Command' cu alte solutii de selectare a unei actiuni (comenzi), sa examinam pe scurt programarea unui meniu cu clase JFC. Un meniu este format dintr-o bara meniu orizontala (obiect JMenuBar), care contine mai multe optiuni de meniu (obiecte JMenu) si fiecare optiune poate avea un submeniu vertical cu mai multe elemente de meniu (obiecte JMenuItem). Un element de meniu este o optiune care declanseaza o actiune la selectarea ei, prin producerea unui eveniment de tip ActionEvent.

Clase cu un singur obiectUneori este nevoie de un singur obiect de un anumit tip, deci trebuie interzisa

instantierea repetata a clasei respective, numita clasa 'Singleton'. Exista cateva solutii:

- O clasa fara constructor public, cu o metoda statica care produce o referinta la unicul obiect posibil ( o variabila statica si finala contine aceasta referinta).

- O clasa statica inclusa si o metoda statica (in aceeasi clasa exterioara) care instantiaza clasa (pentru a-i transmite un parametru).

Ambele solutii pot fi intalnite in clasa Collections (neinstantiabila) pentru a se crea obiecte din colectii 'speciale' : colectii vide (EmptySet, EmptyList, EmptyMap) si colectii cu un singur obiect (SingletonSet, SingletonList, SingletonMap).

Clase “model” in schema MVC

Schema MVC (Model-View-Controller) este o extindere a schemei 'Observat-observator'. Un obiect “model” este un obiect observat (ascultat), care genereaza evenimente pentru obiectele receptor inregistrate la model, dar evenimentele nu sunt produse ca urmare directa a unor cauze externe programului (nu sunt cauzate direct de actiuni ale operatorului uman).

Arhitectura MVC foloseste clase avand trei roluri principale:

- Clase cu rol de “model”, adica de obiect observat care contine si date.

- Clase cu rol de redare vizuala a modelului, adica de obiect observator al modelului.

- Clase cu rol de comanda a unor modificari in model.

Schema MVC a aparut in legatura cu programele de birotica (pentru calcul tabelar si pentru editare de texte), de unde si numele de “Document-View-Controller”.

Separarea neta a celor trei componente (M, V si C) permite mai multa flexibilitate in adaptarea si extinderea programelor, prin usurinta de modificare separata a fiecarei parti (in raport cu un program monolit la care legaturile dintre parti nu sunt explicite). Astfel, putem modifica structurile de date folosite in memorarea foii de calcul (modelul) fara ca aceste modificari sa afecteze partea de prezentare, sau putem adauga noi forme de prezentare a datelor continute in foaia de calcul sau noi forme de interactiune cu operatorul (de exemplu, o bara de instrumente “tool bar”).

Separarea de responsabilitati oferita de modelul MVC este utila pentru realizarea de aplicatii sau parti de aplicatii: componente GUI, aplicatii de tip “client-server” s.a.

Pentru a ilustra folosirea schemei MVC in proiectarea unei aplicatii si afirmatia ca introducerea de obiecte (si clase) suplimentare face o aplicatie mai usor de modificat vom considera urmatoarea problema simpla:

Operatorul introduce un nume de fisier, aplicatia verifica existenta acelui fisier in directorul curent si adauga numele fisierului la o lista de fisiere afisata intr-o alta fereastra. Ulterior vom adauga o a treia fereastra in care se afiseaza dimensiunea totala a fisierelor selectate. Daca nu

exista fisier cu numele primit atunci se emite un semnal sonor si nu se modifica lista de fisiere (si nici dimensiunea totala a fisierelor).

3. Criterii de clasificarea sabloanelor de proiectare:

3.1 Sabloane Creationale

Sabloanele creationale de proiectare abstractizeaza procesul de instantiere. Ele va ajuta sa faceti un system independent de modul in care sunt create, compuse si reprezentate obiectele acestuia. Un sablon creational de clasa foloseste mosternirea pentru a varia clasa care este instantiate, in timp ce un sablon creational de obiect va delega instantierea catre un alt obiect.

Sabloanele creationale devin din ce in ce mai importante, pe masura ce sistemele evolueaza spre a deprinde mai mult de compunerea obiectelor decat de mostenirea de clasa. Cand se intampla asa ceva, accentual se deplaseaza de la precizrea pron cod a unui set fix de comportamente spre definirea unui set mai mic de comportamente fundamentale, care sa poata fi compus in orice numar de comportamente mai complexe. Prin urmare, crearea obiectelor cu un anumit comportament va necesita mai mult decat simpla instantiere a unei clase.

In aceste sabloane exista 2 teme recurente. In primul rand, ele toate incapsuleaza cunostinte despre ce clase concrete utilizeaza sistemul. In al 2lea rand, ele ascund modul in care sunt create si asamblate instantele acestor clase. Tot ceea ce sistemul stie, in mare, despre obiecte este ca interfetele lor sunt definite de clase abstracte. In consecinta, sabloanele creationale va asigura flexibilitatea asupra: ce se creaza, cine creaza, cum se creaza si cand se creaza. Ele va permimt sa configurati un system cu oebiecte “produs” a caror structura si functionalitate variaza in limite largi. Configuratia poate fi static (precizata la compilare) sau dinamica (precizata prin executie).

Vom define un labirint ca un set de camera. O camera isi cunoaste veciniil vecini posibili sunt o alta camera, un perete, sau o usa catre o alta camera.

Clasele Room (camera), Door (usa) si Wall (perete) defines componentele labirintului pe care le vom utiliza in toate exemplele noastre. Din aceste clase vom define doar partile importante pentru crearea unui labirint. Vom ignora jucatorii, operatiile de afisare si parcurgere a labirintului si alte functii importante ce nu sunt insa relevante pentru construirea labirintului.

Diagrama urmatoare prezinta relatiile dintre aceste clase:

Fiecare camera are 4 laturi. In implementarile C++, vom utiliza o enumerare Direction pentru a preciza latura de nord, de sud, de est si de vest:

Enum Direction {North, South, East, West};

Implementarile Smalltalk utilizeaza simboluri corespondente pentru reprezentarea acestor directii.

Sablonul - Abstract FactoryDefinitie: Sablonul furnizeaza o interfata pentru crearea familiilor de obiecte inrudite sau

dependente, fara specificarea claselor lor concrete.

Sa luam in considerare un set de instrumente pentru interfata cu utilizatorul, care suporta mai multe standard de prezentare si aspect, cum ar fi Motif si Presentation Manager. Standardele de prezentare si aspect diferite definesc infatisari si comportamente diferite pentru “decoratiunile” interfetei cu utilizatorul, cum ar fi barele de derulare, ferestrele si butoanele. Pentru a fi portabila pe mai multe standard de prezentare si aspect, o aplicatie nu trebuie sa precizeze direct prin cod decoratiunile sale pentru un anumit standard de prezentare si aspect. Instantierea, in intreaga aplicatie, a unor clase de decoratiuni specific unui standart de prezentare si aspect face dificila modificarea ulterioara a prezentarii si aspectului.

Putem rezolva aceasta problema prin definirea clasei abstracte WidgetFactory, care sa declare o interfata pentru crearea fiecarui tip de baza de decoratiune. Exista de asemenea cate o clasa abstracta pentru fiecare tip de decoratiune, iar subclasele concrete implementeaza decoratiunile pentru standarde specific de prezentare si aspect. Interfata clasei WindgetFactory are o operatie ce returneaza un obiect decoratiune nou pentru fiecare clasa abstracta de decoratiuni. Clientii apeleaza aceste operatii pentru a obtine instante ale decoratiunii, dar nu au stiinta de clasele concrete pe care le folosesc. In acest fel, clientii raman independeti de prezentarea si aspectul predominant.

Exista cate o subclasa concreta a clasei WidgetFactory pentru fiecare standard de prezentare si aspect. Fiecare subclasa implementeaza operatii de creare a decoratiunii corespunzatoare standardului de prezentare si aspect.

De asemenea, o clasa WidgetFactory impune dependente intre clasele concrete de decoratiuni. O bara de derulare Motif trebuie utilizata doar cu un buton Motif si un editor de text Motif, iar aceasta restrictive este impusa automat ca o consecinta a utilizarii subclasei MotifWidgetFactory.

Aplicabilitate

Sablonul Abstract Factory se utilizeaza cand:

Un system trebuie sa fie independent de modul in care sunt create, compuse si reprezentate produsele sale

Un system trebuie sa fie configurat cu una dintre mai multe familii de produse Obiectele produs inrudite, dintr-o familie, sunt proiectate pentru a fi folosite impreuna si

trebuie sa impuneti aceasta restrictive Doriti sa furnizati o biblioteca de clasa de produse si nu doriti sa prezentati decat

interfetele acestora, nu si implementarile lor.

Structura

Participanti

AbstractFactory (AtelierAbstract) (WidgetFactory)- Declara o interfata pentru operatii care creeaza obiecte produs abstracte

ConcreteFactory (AtelierConcret) (MotifWidgetFactory, PMWidgetFactory)- Implementeaza operatiile pentru crearea obiectelor produs concrete

ProdusAbstract (Windows, ScrollBar)- Declara o interfata pentru un tip de obiect produs

ProdusConcret (MotifWindow, MotifScrollBar)- Defineste un obiect produs care va fi creat de atelierul concret correspondent- Implementeaza interfata ProdusAbstract

Colaborari

In mod normal, la executie se creaza o singura instanta a clasei ConcreteFactory (AtelierConcret). Acest atelier concret creaza obiecte produs care au o anumita implementare. Pentru a crea obiecte produs diferite, clientii trebuie sa utilizeze un alt atelier concret.

Clasa AbstractFactory (AtelierAbstract) transfera crearea obiectelor produs catre subclasa ConcreteFactory (AtelierConcret)

Consecinte

Sablonul Abstract Factory are urmatoarele beneficii si responsabilitati: Izoleaza clasele concrete. Sablonul AbstractFactory va ajuta sa controlati clasele

de obiecte create de o aplicatie. Deoarece un atelier incapsuleaza responsabilitatea si procesul de creare a obiectelor produs, el izoleaza clientii de implementarea claselor. Clientii manevreaza instantele prin intermediul interfetelor lor abstracte. Numele claselor produs sunt isolate in implementarea atelierului concret; ele nu apar in codul client

Faciliteaza schimbarea familiilor de produse. Clasa unui atelier concret apare o singura data intr-o aplicatie si anume cad este instantiera. Acest lucru faciliteaza schimbarea atelierului concret utilizat de o aplicatie. Aplicatia poate folosi configuratii diferite de produse, schimband pur si simplu atelierul concret. Deoarece un atelier abstract creeaza o familie complete de obiecte, intreaga familie de produse poate fi schimbata imediat. In exemplul nostrum de interfata cu utilizatorul, putem trece de la decoratiunile Motif la cele Presentation Manger, schimband obiectele atelier corespunzatoare si creand din nou interfata

Promoveaza consistenta produselor. Cand obiectele produs dintr-o familie sunt proiectate pentru a lucre impreuna este important ca o aplicatie sa foloseasca la un moment dat doar obiecte dintr-o singura familie. Clasa AbstractFactory faciliteaza respectarea acestui lucru.

Este dificil de asigurat support pentru noi tipuri de produse. Extinderea atelierelor abstracte pentru obtinerea de noi tipuri de rpoduse nu este usoara. Acest lucru se datoreaza faptului ca interfata AbstractFactory fixeaza setul de produse care poate fi creat. Suportul care poate fi creat pentru tipuri noi de produse necesita extinderea interfetei atelierului, lucru ce implica modificarea clasei AbstractFactory si a tuturor subclaselor acesteia. In sectiunea Implementare, vom discuta o solutie la aceasta problema.

Implementare

1. Atelier ca Singleton. De obiei, o aplicatie are nevoie de o singura instanta a clasei ConcreteFactory pe familii de produs. Deci, aceasta este cel mai bine implementata ca Singleton (111)

2. Crearea produselor. Clasa AbstractFactory declara doar o interfata pentru crearea produselor. Subclasele ProdusConcret sunt responsabile de crearea reala a produselor. Cea mai obisnuita cale de a realiza acest lucru este definirea unei metode de atelier pentru fiecare produs. Un atelier concret va preciza produsele sale redefinind metoda de atelier pentru fiecare dintre acestea. Desi aceasta implementare este simpla, ea necesita o subclasa atelier concret noua pentru fiecare familie de produse, chiar daca familiile de produse nu prezinta decat diferente minore.

3. Definirea atelierelor extensibile. Clasa AbstractFactory defineste de obicei cate o operatie diferita pentru fiecare tip de produs pe care-l realizeaza. Tipurile de produse

sunt precizate in codul semnaturii operatiei. Adaugarea unui nou tip de produs necesita modificarea interfetei AbstractFactory si a tuturor claselor care depend de ea.

Utilizari cunoscute

InterViews utilieaza sufixul “Kit” pentru a indica clasele AbstractFactory (AtelierAbstract). El defineste atelierele abstracte WidgetKit si DialogKit destinate generarii obiectelor de interfata cu utilizatorul, specific standardelor de prezentare si aspect. De asemenea, InterViews contine un atelier LayoutKit care genereaza diferite obiecte compuse in functie de machete dorita. De exemplu, o machete conceputa pe orizontala poate necesita diferite obiecte compuse, in functie de orientarea documentului (portret sau peisaj).

ET++ utilizeaza sablonul AbstractFactory pentru a obtine portabilitatea pe diferite sisteme de ferestre (de exemplu X Windows si SunView). Clasa de baza abstracta WindowSystem defineste interfata pentru crearea obiectelor ce reprezinta resursele sistemeuului de ferestre (de exemplu MakeWindow, MakeFont, MakeColor). Subclasele concrete implementeaza interfetele pentru un anumit system de ferestre.

La executie ET++ creaza o instanta a subclasei concrete WindowSystem care constuieste obiectele concrete resursa de system.

Sablonul – Builder

Definitie: Separa constructia unui obiect complex de reprezentarea acestuia, astfel incat acelasi process de constructive sa poata crea reprezentari diferite.

Motivatie

Un program de citire pentru formatul de schimb de comente RTF trebuie sa poata transforma RTF in multe alte formate de text. Programul de citire ar putea transforma documentele RTF in text ASCII simplu sau intr-un text care sa poata fi editat interactive. Problema este insa ca numarul de transformari posibile este nelimitat. Deci adaugarea unei noi transformari ar trebui sa fie usor de facut fara a modifica programul de citire.

O solutie este configurarea clase RTFReader cu un obiect TextConverter care transforma formatul RTF intr-o alta reprezentare de text. Pe masura ce clasa RTFReader analizeaza documentul RTF, ea foloseste obiectul TextConverter pentru efectuarea transformarii. Ori de cate ori clasa RTFReader recunoaste un token RTF ea genereaza o cerere

catre obiectul TextConverter ca sa transforme token-ul. Obiectele TextConverter raspund atat de efectuarea transformarii datelor cat si de reprezentarea token-ului intr-un anumit format. Subclasele obiectului TextConverter sunt specializate in diferite transformari si formate.

Aplicabilitate

Sablonul Builder se utilizeaza cand:

Algoritmul pentru crearea unui obiect complex trebuie sa fie independent de partile care compun obiectul si de modul in care acestea sunt asamblate

Procesul de constructive trebuie sa permita reprezentari diferite pentru obiectul care este construit

Structura

Participanti

Builder (TextConverter)- Precizeaza o interfata abstracta pentru crearea partilor unui obiect produs

ConcreteBuilder (ASCIIConverter, TeXConverter, TextWidgetConverter)- Construieste si asambleaza parti ale produsului implementand interfata Builder

(Constructor) Director (RTFReader)

- Construieste un obiect utilizand interfata Builder Produs (ASCIIText, TeXText, TextWidget)

- Reprezinta obiectul complex in constructive. Clasa ConcreteBuilder construieste reprezentarea interna a produsului si defineste procesul prin care acesta este asamblat

- Contine clase care definesc partile constituitive, inclusive interfete pentru asamblarea acestora in rezultatul final

Colaborari

Clientul creaza obiectul Director si-l configureaza cu obiectul Builder dorit Directorul instinteaza constructorul ori de cate ori trebuie construita o parte a unui

produs Builder rezolva cererile directorului si adauga partile la produs Clientul preia produsul de la constructor

Consecinte

1. Sablonul va permite sa variati reprezentarea interna a unui produs. Obiectul Builder furnizeaza directorului o interfata abstracta pentru construirea produsului. Interfata permite constuctorului sa ascunda repreezentarea si structura interna a produsului.

2. Sablonul izoleaza codul pentru construire si reprezentare. Sablonul Builder imbunatateste caracterul modular incapsuland calrea prin care este construit si reprezentat un obiect complex.

3. Sablonul va ofera un grad ridicat de control asupra procesului de constructive. Spre deosebire de sabloanele creationale care construiesc produse “dintr-un foc”, sablonul Builder construieste produsele pas cu pas, sub controlul directorului.

Sablonul – Factory Method (Sablon creational de clasa)

Sablonul defineste o interfata pentru crearea unui obiect, dar permite subclaselor sa decida ce clasa vor instantia. Sablonul Factory Method permite unei clase sa delege instantierea la subclase.

Motivatie

Cadrele de dezvoltare utilizeaza clase abstracte pentru a define si intretine relatiile intre obiecte. Deseori, un cadru de dezvoltare este de asemenea responsabil si de crearea acestor obiecte.

Sablonul Factory Method incapsuleaza cunoasterea tipului de subclasa Document care va fi creat si scoate aceasta cunoastere din cadrul de dezvoltare. Subclasele Application redefines operatia abstracta CreateDocument a clasei Application, astfel incat aceasta sa returneze subclasa Document corecta.

Aplicabilitate

Sablonul Factory Method se utilizeaza cand:

O clasa nu poate anticipa clasa obiectelor pe care trebuie sa le creeze O clasa doreste ca subclasele sale sa precizeze obiectele pe care le creeaza Clasele deleaga responsabilitatea catre una dintre mai multe subclase ajutatoare si doriti

sa localizati cunoasterea subclasei ajutatoare delegate

Structura

Participanti Product (Document)

- Defineste interfata pentru obiectele create de metoda de atelier ConcreteProduct (MyDocument)

- Implementeaza interfata Product Ceator (Application)

- Declara metoda de atelier, care returneaza un obiect de tipul Product. De asemenea, clasa Creator poate define o implementare prestabilita a metodei de atelier, care sa returneze un obiect Concrete Product implicit

- Poate apela metoda de atelier pentru a crea un obiect Produt ConcreteCreator (MyApplication)

- Redefineste metoda de atelier astfel incat sa returneze o instant a unui obiect ConcreteProduct

Consecinte

Metodele de atelier elimina necesitatea de a lega in cod clasele specific aplicatiei. Codul are de a face doar cu interfata Productl prin urmare, el va putea lucre cu orice clase ConcreteProduct definite de utilizator.

1. Furnizeaza puncte de acorare pentru subclase. Crearea obiectelor in interiorul unei clase cu ajutorul unei metode de atelier este intotdeauna o modalitate mai flexibila decat crearea directa a unui obiect.

2. Conecteaza ierarhii paralele de clasa. In exemplele despre care am discutat pana acum, metoda de atelier nu este apelata decat de clasele Creators. Sa consideram cazul figurilor desenate care pot fi manevrate interactive.

Implementare

1. Doua variante majore. Principalele doua variante ale sablonului Factory Method sunt (1) cazul in care clasa Creator este o clasa abstracta si nu asigura o implementare pentru metoda atelier pe care o declara si (2) cazul in care clasa Creator este o clasa concreta si asigura o implementare prestabilita pentru metoda de atelier.

2. Metode de atelier parametrizate. O alta variant a sablonului permite metodei de atelier sa creeze mai multe tipuri de produse. Metoda de atelier accepta un parametru care identifica tipul de obiect ce va fi creat.

3. Probleme si variante specific limbajului. Folosirea de limbaje de programare diferite duce la aparitia altor variante interesante.

4. Utilizarea tiparelor pentru evitarea generarii de subclase. Dupa cum am mentionat, o alta posibila problema la metodele de atelier este faptul ca acestea va pot oblige sa generate subclase doar pentru a crea obiecte Product corecte.

Utilizari cunoscute

Metodele de atelier se regasesc cel mai des in kiturile de instrumente si in cadrele de dezvoltare. Clasa View din cadrul de dezvoltare Smalltalk-80 Model/View/Controller are o metoda numita defaultController, care creaza un controller, iar aceasta pare a fi o metoda de atelier. Dar subclasele View precizeaza clasa controllerului lor prestabilit prin definirea metodei defaultControllerClass, care returneaza clasa din care controllerul prestabilit creeaza instante. Deci, defaultControllerClass este adevarata metoda de atelier, adica metoda ce trebuie dedefinita de catre subclase.

Sistemul Orbix ORB produs de IONA Tehnologies utilizeaza sablonul FactoryMethod pentru a genera un tip corespunzator de proxy atunci cand un obiect solicita o referinta catre un obiect la distanta. Sablonul Factory Method faciliteaza inlocuirea obiectului proxy prestabilit cu unul care utilizeaza, de exemplu, stocarea pe parte de client.

Sabloane inrudite

Sablonul Abstract Factory este deseori implementat cu metode de atelier. Exemplul Motivation din sablonul Abstract Factory ilustreaza, de asemenea, sablonul Factory Method. Metodele de atelier sunt apelate de obicei in interiorul sabloanelor Template Method. Sabloanele Prototype nu necesita generarea subclaselor Creator. Insa ele necesita deseori o operatie Intialize in clasa Product. Clasa Creator utilizeaza operatia de Initialize pentru a initializa obiectul. Sablonul Factory Method nu necesita o astfel de operatie.

3.2 Sabloane structurale

Sabloanele structural se ocupa de modul in care sunt compuse clasele si obiectele pentru a forma structurri mai complexe. Sabloanele structurale de clasa folosesc mostenirea pentru a compune interfete sau implementari. Acest tip de sablon este in special util pentru a face sa functioneze impreuna bibliotecile intre clasea dezvoltare independent. Un exemplu este forma de clasa Adapter. In general, un adaptor realizeaza o interfata conforma cu o alta, furnizand astfel o abstractizare uniforma pentru interfete diferite. Un adaptor de clasa realizeaza acest lucru prin mostenirea privata de la clasa adaptat. Apoi, adaptorul exprima interfata sa in termenii adaptatului.

In loc sa compuna interfete sau implementari, sabloanele structurale de obiect descriu moduri de compunere a obiectelor in scopul obtinerii de functionalitati noi. Flexibilitatea modului de compunere a obiecteleor provenite din capacitatea de modificare a compunerii la executie, lucru imposibil in cazul compunerii statice a claselor.

Un exemplu de sablon structural de obiect este sablonul Composite. Acest sablon descrie modul in care se construieste o ierarhie de clasa compusa din clase pentru doua tipuri de obiecte: primitive si compuse. Obiectele compuse permit sa combinam obiectele primitive si alte obiecte compuse in structuri complexe arbitrare. In sablonul proxy, un obiect proxy actioneaza ca un surogat convenabil sau ca un inlocuitor pentru alt obiect. Un proxy poate fi utilizat in mai multe feluri. El poate actiona ca un reprezentant local pentru un obiect dintr-un spatiu de adresa la distanta. El poate reprezenta un obiect de mari dimensiuni care trebuie incarcat la cerere. El poare proteja accesul la un obiect sensibil. Obiectele proxy ofera cai indirecte catre anumite proprietati ale obiectelor. Prin urmare, obiectele proxy pot restrictiona, imbunatati sau chiar altera aceste proprietati.

Sablonul Flyweight arata cum sa facem o multime de obiecte mai mici, sablonul Facade spune cum sa obtinem un singur obiect care sa reprezinte un untreg subsistem. O fatada este un reprezentant al unui set de obiecte. Fatada isi indeplineste responsabilitatile transmitand mesaje catre obiectele de implementarea sa, astfel incat sa le puteti varia independent.

Sablonul Decorator descriem odelul in care putem adauga dinamic responsabilitati la un obiect. Sablonul Decorator este un sablon structural care compune recursiv obiecte, astfel incat sa permita un numar nelimitat de responsabilitati suplimentare. De exemplu, un obiect Decorator care contine o componenta de interfata cu utilizatorul poate adauga la componenta o decoratiune cum ar fi o bordura sau o umbra, sau poate adauga functionalitate cum ar fi derularea si marirea. Putem adauga doua decoratiuni prin simpla imbricare a unui obiect. Pentru arealiza acest lucru, fiecareobiect Decorator trebuie sa se conformeze interfetei componentei sale si trebuie sa ii transmita mesaje acesteia. Obiectul decoratr isi poate indeplini sarcina fie inainte, fie dupa transmiterea unui mesaj.

Multe dintre sabloanele structurale sunt inrudite intr-o oarecare masura.

Adapter

Transforma interfata unei clase intr-o interfata care este asteptata de client. Sablonul Adapter permitelucrul impreuna pentru clase care altfel nu ar putea face acest lucru din cauza interfetelor incompatibile.

AplicabilitateSablonul Adapter se utilizeaza cand:

- doriti sa utilizati o clasa existenta, dar interfata acestuia nu corespunde celei de care aveti nevoie;

- doriti sa creati o clasa reutilizabila care sa coopereze cu clasele neinrudite sau neasteptate, adica clasele care nu au in mod necesar interfete compatibile;

- trebuie sa utilizati mai multe subclase existente, dar nu este practic sa le adaptati interfata generand subclase pentru fiecare. Un obiect adaptor poate adapta interfata clasei sale parinte.

StructuraO clasa adaptor utilizeaza mostenirea multipla pentu a adapta o interfata la alta:

Un adaptor se bazeaza pe compunerea obiectelor:

Participanti- Tinta (Shape): defineste interfata specifica domeniului, utilizata de catre client.- Client (DrawingEditor): colaboreaza cu obiectele in conformitate cu intefata Tinta- Adaptat (TextView): defineste o interfata existenta care trebuie adaptata.- Adaptor (TextShape): adapteaza interfata Adaptat la interfata Tinta

ColaborariClienti apeleaza operatii pe o instanta Adaptor. La randul lui, adaptorul apeleaza

operatiile Adapter care indeplinesc cererea.

ConsecinteClasele si obiectele adaptor au compromisuri diferite. O clasa adaptor:

- adapteaza clasa Adaptat la clasa TInta prin respectarea unei clase concrete Adaptat. Drept consecinta, o clasa adaptor nu va functiona atunci cand dorim sa adaptam o clasa si toate subclasele ei.

- permite clase adaptor sa redefineasca partial componenta clasei Adaptat, deoarece Adaptor este o subclasa a clase Adaptat.

- introduce doar un singur obiect si, pentru a ajunge la adaptat, nu este necesara nici un fel de ocolire pin folosirea unor pointeri suplimentari.

Un obiect adaptor:

- permite unei singure clase Adaptor sa lucreze cu mai multe clase Adaptat- face dificila redefinirea comportarii clasei Adaptat.

ImplementareDesi implementarea sablonului Adapter este de obicei simpla si directa, exista

cateva probleme de care trebuie tinut cont: 1. Implementarea adaptoarelor de clasa in C++. Intr-o implementare C++ a unei

clase adaptor, clasa Adaptor va mosteni public de la clasa Tinta si privat de la clasa Adaptat. In acest fel, clasa Adaptat va fi un subtip al clasei Tinta, nu al clasei Adaptat.

2. Adaptoare ce pot fi conectate.

Sabloane inruditeSablonul Bridge are o structura similara unui obiect adaptor, dar are un cu totul

alt scop: el este destinat separarii unei interfete de implementarea ei, astfel incat cele doua sa poata fi modificate independent, cu usurinta. Scopl unui adaptor este sa schimbe interfata unui obiect existent.

Sablonul Proxy defineste un reprezentant sau un surogat pentru un alt obiect si nu-i modifica interfata.

Bridge Decupleaza o abstractizare de implementarea ei, astfel incat cele doua sa poata

varia independent.

AplicabilitateSablonul Bridge se utilizeaza cand:

- dorim sa evitam o legatura permanenta intreo abstractizare si implementarea acesteia. Astfel de cazuri ar putea fi, de exemplu, cand implementarea trebuie selectata sau schimbata a executie.

- atat abstractizarile, cat si implementarile acestora trebuie sa fie extensibile prin generarea subclaselor. In acest caz, sablonul Bridge, permite sa combinam abstractizari si implementari diferite si sa le extindem imediat.

- modificarile in implementarea unei abstractizari nu trebuie sa afecteze clientii; cu alte cuvinte, codul client nu trebuie sa fie recompilat.

Structura

Participanti- Abstraction (Window): defineste interfata abstractizarii, pastreaza o referinta

catre un obiect de tipul Implementor.- RefinedAbstraction (IconWindow): extinde interfata definita de clasa Astraction.- Implementor (WindowImp) defineste interfata pentru clasele de implementare.- ConcreteImplementor (XWindowImp, PMWindowImp): implementeaza interfata

Implementor si ii defineste implementarea concreta.

ColaborariClasa Abstraction transmite catre obiectul sau Implementor cererile clientului.

ConsecinteSablonul Bridge are urmatoarele consecinte:

1. Decupleaza interfata si implementarea. O implementare nu este legata permanent la o interfata. implementarea unei abstractizari poate fi configrata la executie. Pentru un obiect, este posibil chiar sa-si modifice implementarea la executie.

2. Imbunatateste posibilitatile de extindere. Putem extinde independent ierarhiile Abstraction si Implementor.

3. Ascunde detaliile implementarii fata de clienti. Clientii pot fi feriti de detalii de implementare, ca de exemplu partajarea obiectelor Implementor si mecanismul de numarare a referintelor corespunzator.

Implementare

1. La aplicarea sablonului Bridge tinem cont de urmatoarele probleme de implementare:

2. Un singur Implementor. In situatia in care exista o singura implementare, nu este necesara crearea unei clase implementor abstracte. Acesta este un caz degenerat al clasei Bridge; Intre clasele Abstraction si Implementor exista o relatie de “unu la unu”.

3. Crearea obiectului Implementor corect.4. Partajarea implementarilor.5. Utilizarea mostenirii multiple.

Sabloane inruditeUn sablon Abstract Factory poate crea si configura un sablon Bridge particular.Sablonul Adapter este orientat asupra sistemelor, dupa ce acestea au fost

proiectate. Sablonul Bridge, pe de alta parte, este utilizat de la inceput intr-un proiect pentru a permite abstractizarilor si implementarilor sa varieze independent.

CompositeCompune un obiect in structuri de arbore pentru a reprezenta ierarhii de tip

parte-intreg. Sablonul Composite permite clientilor sa trateze uniform obiectele si compuneri de obiecte.

AplicabilitateSablonul Composite se utilizeaza cand:

- dorim sa reprezentam ierarhii de obiecte, de tip parte-intreg.- dorim ca clientii sa poata ignora diferentele dintre compunerile de obiecte

individuale. Clientii cor trata uniform toate obiectele din structura compusa.

Structura

O structura de tip obiect Composite ar putea arata astfel:

Participanti- Component (Graphic): declara interfata pentru obiectele din compunere;

implementeaza in mod corespunzator, comportarea prestabilita pentru interfata comuna tuturor claselor; declara o interfata pentru accesarea si gestionarea componentelor sale copil.

- Leaf (Rectangle,Line,Text etc.) : reprezinta obiectele frunza din compunere; defineste compunerea pentru obiecele primitive din compunere.

- Composite (Picture): defineste comportarea pentru componentele care au copii; stocheaza componentele copil.

- Client: manevreaza obiectele din compunere prin intermediul interfetei Component.

ColaborariClientii utilizeaza interfata clasei Component pentru a interactiona cu obiectele

din structura compusa. Daca destinatarul este un obiect Leaf, atunci solicitarea este rezolvata direct. Daca destinatarul este un obiect Composite, atunci aceasta transmite de obicei cererile catre componentele sale copil, punand insa sa efectueze si operatii suplimentare inainte si/sau dupa transmitere.

ConsecinteSablonul Composite:

- defineste ierarhii de clasa care contin obiecte primitive si obiecte compuse- simplifica clientii- faciliteaza adaugarea noilor tipuri de componente- poate face un proiect excesiv de general

ImplementareLa implementarea sablonului Composite, exista mai multe probleme de care

trebuie tinut cont:1. Referinte explicite catre parinte. Pastrarea referintelor de la componentele copil

la parintii lor poate simplifica tranversarea si gestioarea unei structuri compuse.2. Partajarea Componentelor. Partajarea componentelor este deseori utila, de

exemplu, pentru a reduce cerintele de stocare.3. Maximizarea interfetei Component.4. Declararea operatiilor de gestionare a copiilor.

5. Trebuie caclasa Component sa implementeze o lista de subclase component6. Ordonarea copiilor7. Depozitarea in memorie pentru imbunatatirea performantelor

Sabloane inruditeIn sablonul Chain of Responsibility se utilizeaza deseori o legatura componenta-

parinte.Sablonul Decorator este deseori utilizat impreuna cu sablonul Composite. Cand

se utilizeaza impreuna decoratorii si compozitii, ele vor trebui sa suporte Component cu operatii cum ar fi Add, Remove si GetChild.

Sablonul Flyweight, permite sa partajam componentele, dar aceastea nu se mai pot referi la paritii lor.

Sablonul Iterator poate fi utilizar pentru traversarea compozitiilor.Sablonul Visitor localizeaza operatiile si modurile de comportare care altfel ar fi distribuite printre clasele Composite si Leaf.

DecoratorAtaseaza dinamic responsabilitati suplimentare la un obiect. Decoratorii ofera

alternatica flexibila la generarea subclaselor in scopul extinderii functionalitatii.

AplicabilitateUtilizati sablonul Decorator:

- pentru a adauga dinamic si transparent responsabilitati la obiecte individuale, adica fara a afecta alte obiecte.

- pentru responsabilitati care pot fi retrase.- cand nu este practica extinderea prin generarea de subclase. Uneori, esteposibil

un numar mare de extinderi independente care vor produce o explozie de subclase ce suporta fiecare combinatie. Sau definitia unei clase ar putea fi ascunsa sau indisponibila pentru generarea de subclase.

Structura

Participanti- Component (VisualComponent): defineste interfata pentru obiectele la care se

poate adauga dinamic responsabilitati.- ConcreteComponent (TextView): defineste un obiect la care pot fi atasate

responsabilitati suplimentare.- Decorator: pastreaza o referinta catre un obiect component si defineste o

interfata care se conformeaza interfetei obiectului Component.- ConcreteDecorator (BorderDecorator,ScrollDecorator): adauga responsabilitati

la componenta.

ColaborariClasa Decorator transmite cererile catre obiectul sau Component. Inainte sau

dupa transmiterea cererii, ea poate efectua optional operatii suplimentare.

ConsecinteSablonul Decorator are cel putin doua avantaje si doua dezavantaje:1. O mai buna flexibilitate decat mostenirea statica.2. Evita prezenta la nivelurile inalte ale unei ierarhii a claselor pline de functii.3. Un decorator si componenta sa nu sunt identice.4. O multime de obiecte mici.

ImplementareCand aplicati sablonul Decorator, trebuie sa tineti cont de mai multe probleme:

1. Conformitatea interfetei. Interfata unui decorator trebuie sa se conformeze interfetei componentei pe care o decoreaza.

2. Omiterea clasei astracte Decorator. Cand trebuie sa adaugati doar o singura responsabilitate, nu este necesara definirea unei clase.

3. Pastrarea unor clase Component usoare. Pentru a asigura o interfata conforma, componentele si decoratorii trebuie sa decida dintr-o clasa Component comuna.

4. Schimbarea aspectului unui obiect sau schimbarea detaliilor interne ale acestuia.

Sabloane inruditeSablonul Adapter: un decorator difera de un adapter prin faptul ca primul

schimba doar responsabilitatile unui obiect, nu si interfata acestuia; un adaptor ofera unui obiect o interfata complet noua.

Sablonul Composite: un decorator poate fi considerat o compozitie degenerata care are o singura componenta. Insa decoratorul adauga responsabilitati suplimentare, el nu este conceput pentru agregarea obiectelor.

FlyweightUtilizeaza partajarea pentru a suporta eficient numere mari de obiecte cu

glanularitate fina.

AplicabilitateEficienta sablonului flyweight depinde foarte mult de modul si locul in care este

utilizat. Aplicam sablonul in situatiile in care toate afirmatiile urmatoare sunt adevarate:- O aplicatie utilizeaza un numar mare de obiecte.- Majoritatea starilor de obiect pot fi facute extrinseci.- Aplicatia nu depinde de identitatea obiectului

Structura

Urmatoarea diagrama de obiecte va arata cum sunt partajate obiectele flyweight:

Participanti- Flyweight(grlyph): declara o interfata prin care obiectele flyweight pot primi si pot

actiona asupra starii extrinsece.- ConecteFlyweight(Character): inplementeaza interfata Flyweight si adauga

socarea starii intrinseci, daca exista.- UnsharedConecteFlyweight(Row,Colum): nu are toate subclasele Flyweight

trebuie sa fie partajate.- FlyweightFactory: creaza si gestioneaza obiectele flyweight; asigura faptul ca

obiectele flyweight sunt partajate corect.- Client: pastreaza o referinta catre obiectul flyweight; calculeaza sau stocheaza

starea extrinseaca a obiectului flyweight.

ColaborariStarea de care este nevoie un obiect flyweight pentru a functiona trebuie sa fie

caracterizata fie ca intrinseaca, fie ca extrinseaca.Clientii nu trebuie sa instantieze direct obiectele ConcreteFlyweight. Pentru a fi

siguri ca sunt partajate corec, clientii trebuie sa obtina obiecte ConcreteFlyweight exclusiv de la obiectul FlyweightFactory.Implementare

La implementarea sablonului Flyweight, tinem cont de urmatoarele probleme:- Eliminarea starii extrinseci.- Gestionarea obiectelor partajate

Sabloane inruditeSablonul Flyweight este deseori combinat cu sablonul Composite pentru a

implementa o structura ierarhica logica intre termenii unui graf aciclic ordonator cu noduri frunza partajate.

De cele mai multe ori, este bine sa se implementeze obiectele State si Strategy ca obiecte Flyweight.

ProxySablonul asigura, pentru un alt obiect, un surogat sau un inlocuitor in scopul

controlarii accesului la acesta.

AplicabilitateSablonul Proxy poate fi aplicat oriunde este nevoie de o referinta la un obiect,

mai versatila sau mai sofisticata decat un pointer simplu.Structura

Iata cum arata o posibila diagrama de obiect pentru o structura proxy la executie:

Participanti- Proxy(ImageProxy): pastreaza o referinta care permite obiectului sa acceseze

subiectul real.- Subject(Graphic): defineste interfata comuna pentru obiecte RealSubject si

Proxy, astfel incat un obiect Proxy sa poata fi utilizat in orice loc in care este asteptat un obiect RealSubject.

- RealSubject(Image): defineste obiectul real reprezentat de obiectul proxy.

ColaborariCand se impune, obiectul Proxy transmie cereile catre obiectul RealSubject, in

functie de tipul de proxy.

ConsecinteCand acceseaza un obiect, sablonul Proxy introduce un grad de ocolire. Aceasta

ocolire suplimentara are mai multe utilizari, in functie de tipul de proxy:1. Un proxy la distanta poate ascunde faptul ca un obiect se gaseste intr-un alt

spatiu de adresa.2. Un proxy virtual poate efectua optimizari, cum ar fi crearea unui obiect la cerere.3. Atat obiectele proxy de protectie, cat si referintele inteligente permit efectuarea

unor sarcini suplimentare de intretinere, atunci cand se acceseara un obiect.

ImplementareSablonul Proxy poate exploata urmatoarele caracteristici de limbaj:

1. Supraincarcarea operatiilor de acces la membru in C++.2. Utilizarea operatiei doesNotUnderstand in Smalltalk.

3. Obiectele proxy ne trebuie sa cunoasca intodeauna tipul subectului real.

Sabloane inruditeSablonul Adapter: un adaptor furnizeaza o interfata diferitapentru subiectul pe

care-l adapteaza.Sablonul Decorator: cu toate ca decoratorii pot acea implementari similare

obiectelor proxy, ei nu au un cu totul alt scop. Un decorator adauga una sau mai multe responsabilitati la un obiect, in timp ce un proxy controleaza accesul la un obiect.

Despre sabloanele structurale

Exista similaritati in sabloanele structurale, in special in ceea ce priveste participantii si colaborarile lor. Acest lucru este adevarat probabil datorita faptului ca sabloanele structurale se bazeaza pe acelasi mic set de mecanisme ale limbajului de programare pentru structurarea codului si a obiectelor: mostenirea simpla si multipla pentru sabloanele bazate pe clasa si compunerea obiectelor pentru sabloanele de obiect. Insa similaritatile dezmint scopurile diferite ale acestor sabloane. In aceasta sectiune voi prezenta asemanarile si deosebirile dintre grupurile de sabloane structurale pentru a va crea o imagine despre meritele lor relative.

Sabloanele Adapter si Bridge au anumite atribute comune. Ambele promoveaza flexibilitatea furnizand un anumit grad de ocolire catre un alt obiect. Ambele implica tranzmiterea cererilor catre acest obiect de la o interfata, alta decat cea proprie lui.

Diferenta chieie dintre aceste sabloane se ragaseste in scopurile lor. Sablonul Adapter se concentreaza asupra rezolvari incompatibilitatilor dintre doua interfete existente. El nu se concentreaza asupra modurilor in care sunt implementate aceste interfete si nu tine cont nici de modul in care acestea pot evolua independent. Sablonul este o cale de a obtine conlucrarea a doua clase proiectate independent, fara a fi nevoie de reimplementarea vreuneia dintre ele. Sablonul Bridge, pe de alta parte, uneste o abstractizare cu implementarile acesteia (potentiale numeroase). Sablonul asigura o interfata stabila pentru clienti, chiar daca va permite sa variati clasele care o implementeaza. De asemenea, sablonul acomodeaza implementarile noi pe masura ce sistemul evolueaza.

Ca un rezultat al acestor diferente, sabloanele Adapter si Bridge sunt deseori utilizate in momente diferite ale ciclului de viata al aplicatiei software. Un adaptor devine deseori necesar atunci cand descoperiti ca doua clase incompatibile trebuie sa lucreze impreuna, in general pentru a evita replicarea codului. Cuplarea este neasteptata. In contrast, utilizatorul unei punti intelege de la inceput ca o abstractizare poate avea mai multe implementari si ca ambele pot evolua independent. Sablonul Adapter face ca lucrurile sa functioneze dupa ce au fost proiectate; sablonul Bridge le face sa functioneze inainte. Acest lucru nu inseamna ca sablonul adapter este in vreun fel inferior sablonului Bridge, ci doar ca fiecare sablon rezolva o alta problema.

Sablonele Composite si Decorator au diagrame de structura similare, care reflecta faptul ca ambele sabloane se bazeaza pe compunerea recursiva pentru a organiza un numar nelimitat de obiecte. Acest aspect comun v-ar putea tenta sa considerati un obiect decorator ca fiind un obiect Composite degenerat, dar acest lucru scapa din vedere scopul sablonului Decorator. Similaritatea se opreste la compunerea recursiva, din acelasi motiv al intentiilor si scopurilor diferite.

Sablonul Decorator este proiectat astfel incat sa va permita sa adaugati responsabilitati la obiecte, fara a recurge la generarea subclaselor. El evita explozia numarului de subclase ce poate aparea din incercarea de a acoperi static toate combinatiile de responsabilitati. Sablonul Composite are un alt scop. El se concentreaza asupra structurarii claselor, astfel incat mai multe obiecte inrudite sa poata fi tratate uniform si mai multe obiecte sa poata fi tratate ca unul singur. In acest sablon accentul cade pe reprezentare, nu pe infrumusetare.

Aceste scopuri sunt distincte, dar complementare. In consecinta, sabloanele Composite si Decorator sunt deseori utilizate impreuna. Ambele duc la tipuri de programare in care va puteti construi aplicatiile prin simpla conectare a obiectelor, fara a mai defini vreo clasa noua. Vor exista o clasa abstracta cu anumite subclase compuse, dintre care unele sunt decorator si altele implementeaza blocurile fundamentale de constructie a sistemului. In acest caz, atat compozitiile, cat si decoratori vor avea interfata comuna. Din punct de vedere al sablonului decorator, o compozitie este o clasa ConcreteComponent. Din punct de vdedere al sablonului composite, un decorator este o clasa Leaf. Bineinteles, nu este obligatoriu ca aceste doua sabloane sa fie utilizate impreuna si dupa cum s-a vazut, scopurile lor sunt destul de diferite.

Un alt sablon care are o structura sumilara celei a sablonului decorator este sablonul Proxy. Ambele sabloane descriu modul in care se asigura un anumit grad de ocolire pentru un obiect si atat implementarile obiectelor proxy, cat si cele ale obiectului decorator pastreaza o referinta la celalalt obiect catre care transmit cererile. Din nou insa, cele doua sabloane au fost realizate avandu-se in vedere scopuri diferite.

Similar sablonului Decorator, sablonul Proxy compune un obiect si ofera clientilor o interfata identica. Spre deosebire de sablonul decorator, sablonul proxy nu este preocupat de atasarea si detasarea dinamica a proprietatilor si nu este proiectat pentru compunere recursiva. Scopul sau este sa ofere un inlocuitor pentru un subiect atunci cand nu este convenabil sau nu se doreste accesarea directa a subiectului deoarece, de exemplu acesta din urma se gaseste pe un calculator la distanta, accesul la el este restrictionat sau obiectul este persistent.

In sablonul Proxy, obiectul defineste functionalitatea cheie, iar obiectul Proxy permite accesul la acesta. In sablonul Decorator, componenta asigura doar o parte din aceasta functionare, iar unul sau mai multi decoratori furnizeaza restul. Sablonul Decorator se ocupa de situatiile in care functionalitatea totala a unui obiect nu poate fi determinata la compilare, cel putin nu intr-un mod convenabil. Aceasta lipsa de limita face din compunerea recursiva o parte esentiala a sablonului decorator. Dar acesta nu

este si cazul sablonului Proxy, deoarece acesta se concentreaza pe o singura relatie- cea dintre obiectul proxy si subiectul sau – iar aceasta relatie poate fi exprimata static.

Aceste diferente sunt semnificative deoarece ele prezinta solutii la probleme specifice ce apar permanent in programarea orientata spre obiecte. Insa acest lucru nu inseamna ca aceste sabloane nu pot fi combinate. V-ati putea gandi la un obiect proxy-decorator care sa adauge functionalitate la un proxy sau la un obiect decorator-proxy care sa infrumuseteze un obiect la distanta. Cu toate ca astfel de hibrizi ar putea fi utili (nu avem la indemana exemplele reale), ei sunt divizibili in sabloane care sunt utile.

3.3 Sabloane comportamentale

Sabloanele Comportamentale se ocupa cu algoritmi si cu atribuirea responsabilitatilor intre obiecte. Sabloanele comportamentale nu descriu doar sabloane de obiecte sau clase, ci si sabloane de comunicare intre acestea. Aceste sabloane caracterizeaza fluxul complex de control ce este dificil de urmarit la executie. Ele muta centrul de atentie de la fluxul de control pentru a ca permite sa comunicati doar asupra modului in care sunt interconectate obiectele.

Sabloanele comportamentale de clasa folosesc mostenirea pentru a distribui comportarea intre clase.

Chain of ResponsibilityEvita cuplarea intre expeditorul si destinatarul oricarei cereri, acordand mai

multor obiecte o sansa de a rezolva cererea. Sablonul inlantuie obiectele destinatar si trece cererea de-a lungul lantului pana cand un obiect o rezolva.

AplicabilitateUtilizarea sablonului Chain of Responsibility cand:

- Cererea poate fi rezolvata de mai multe obiecte, iar obiectul care o va rezolva nu este cunoscut a priori. Obiectul care rezolva cererea trebuie stabilit automat.

- Dorim sa generam o cerere catre unul dintre mai multe obiecte, fara a preciza in mod explicit destinatarul.

- Setul de obiecte care pot rezolva o cerere trebuie precizat dinamic.

Structura

O structura tipica de obiect ar putea arata astfel:

Participanti- Handler(HelpHandler): defineste o interfata pentru rezolvarea cererilor.- ConcreteHandler(PrintButton,PrintDialog): rezolva cererile de care raspunde; isi

poate accesa succesorul.- Client: initializeaza cererea catre un obiect ConcreteHandler din lant.

ColaborariCand un client genereaza o cerere, aceasta se propaga de-a lungul lantului pana

cand un obiect ConcreteHandler isi asuma responsabilitatea de a o rezolva.

ConsecinteSabonul Chain Of Responsibility are urmatoarele avantaje si dezavantaje:

- Reduce cuplarea: sablonul elibereaza un oiect de obligatia de a cunoaste ce alt obiect va rezolva problema.

- Adauga flexibilitate la atribuirea responsabilitatilor la obiecte.- Receptia nu este garantata.

ImplementareaProblemele de implementare de are trebuie sa tinem cont in cazul sablonului

Chain of Responsibility:1. Implementarea lantului de succesori.2. Conectarea succesorilor.3. Reprezentarea cererilor.4. Transmiterea automata in Smalltalk.

Sabloane inruditeSablonul Chain of Responsibility este deseori in conjunctie cu sablonul

Composite. Aici, oarintele unei componente poate actiona ca un succesor al acesteia.

CommandIncapsuleaza o cerere ca obiect, permitandu-ne astfel sa parametrizam clientii cu

diferite cereri, sa formam o coada sau un registru de cereri si sa asigurati suport pentru operatiile ce pot fi anulate.Structura

Participanti- Command: declara o interfata pentru executarea operatiei.- ConcreteCommand(PasteCommand,OpenCommand): defineste o legatura intre

un obiect Receiver si o actiune.- Client(Application): creeaza un obiect ConcreteCommand si ii stabileste

destinatarul.- Invoker(MeniuItem): cere comenzii sa indeplineasca solicitarea.- Receiver(Document,Application)

ImplementareLa implementarea sablonului Command, tinem cont de urmatoarele probleme:

1. Cat de inteligenta trebuie sa fie comanda.2. Asigurarea suportului pentru anulare si refacere.3. Evitarea acumularii erorilor in procesul de anulare.4. Utilizarea tiparelor C++.

Sabloane inruditeUn sablon Composite poate fi utilizat pentru a implementa obiecte

MacroCommand.Un sablon Memento poate pastra starea de care are nevoie comanda pentru a-si

anula efectul.Interpreter

Pentru un limbaj dat, acest sablon defineste o reprezentare a gramaticii limbajului impreuna cu un implementator care utilizeaza reprezentarea pentru a interpreta pozitiile din limbaj.Structura

Participantii- AbstractExpression(RegularExpression): declara o operatieabstracta Interpret

care este comuna tuturor nodurilor din arborele de sintaxa abstracta.- TerminalExpression- Context: contine informatie globala pentru implementare.- Client: invoca operatia pentru Interpret.

ConsecinteSablonul Interpreter are urmatoarele avantaje si dezavantaje:

1. Modificarea si extinderea gramaticii este usor de realizat.2. implementarea gramaticii este usor de facut.3. Gramaticile complexe sunt greu de intretinut.4. Adaugarea unei cai noi de interpretare a expresiilor.

Sabloane inrudite

Sablonul Composite: arborele de sintaxa abstracta este o instanta a sablonului Composite.

Sablonul Flyweight: arata cum partajam simbolurile terminale in interiorul arborelui de sintaxa abstracta.

IteratorAsigura o cale de accesare secventiala a elementelor unui obiect agregat, fara a

expune reprezentarea lui de baza.

AplicabilitateSablonul se utilizeaza pentru:

- a accesa continutul unui obiect fara a expune reprezentarea interna;- a asigura suport pentru mai multe traversari ale obiectelor agregat;- a furniza o interfata uniforma pentru traversarea structurilor agregate diferit.

Structura

Participanti- Iterator: defineste o interfata pentru accesarea si traversarea elementelor.- ConcreteIterator: implementeaza interfata Iterator.- Aggregate: defineste o interfata pentru crearea unui Iteratot.- ConcreteAggregate: implementeaza interfata de creare a obiectului Iterator

pentru a returna o instanta a clasei ConcreteIterator corecta.

CoalaborariO clasa ConcreteIterator urmareste obiectul curent din agregat si poate calcula

obiectul urmator din traversare.

ConsecinteSablonul Iterator are trei consecinte importante:

1. Suporta variatii in traversarea unui agregat.2. Obiectele Iterator Simplifica Interfata Agregate.3. Pe un obiect agregat se pot derula mai multe traversari.

ImplementareSablonul Iterator are multe variante si alternative de implementare.

Compromisurile acestora depind deseori de structurile de control asigurate de limbaj. Unele limbaje asigura chiar suport direct pentru acest sablon.

Sabloane inruditeSablonul Composite: iteratorii sunt deseori aplicati pe structurile recursive cum

sunt obiectele Composite.Sablonul Factory Method: iteratorii polimorfici se bazeaza pe metode de atelier

pentru a instantia subclasa Iterator corecta.Sablonul Memento: este deseori utilizat cu sablonul Iterator. Un obiect Iterator

poate utiliza un obiect Memento pentru a captura starea unei iteratii. Iteratorul stocheaza intern obiectul Memento.

Mediator

Defineste un obiect care incapsuleaza modul in care interactioneaza un set de obiecte. Acest sablon promoveaza cuplarea slaba, interzicand obiectelor sa faca referinte explicite unul la celalalt si permite sa le modificam interactiunea independent.

AplicabilitateaSablonul mediator se utilizeaza cand:

- Un set de obiecte comunica pe cai bine definite, dar complexe. Interdependentele rezultate nu sunt structurare si sunt dificil de inteles.

- Este dificila reutilizarea unui obiect deoarece el se refera la si comunica cu mai multe alte obiecte.

- O comportare distribuita intre mai multe clase trebuie sa poata fi particularizata fara a genera o multime de subclase.

Structura

O structura tipica de obiect ar putea arata astfel:

Participanti- Mediator(DialogDirector): defineste o interfata pentru comunicarea cu obiectele

Colleague.- ConcreteMediator(FontDialogDirector): implementeaza comportarea

cooperanta prin coordonarea obiectelor Colleague.- Clasele Colleague(ListBox,EntryField): fiecare clasa Colleague isi cunoaste

obiectul Mediator; fiecare coleg comunica cu mediatorul sau si in orice situatie in care, altfel, ar fi comunicat cu un alt coleg.

-Consecinte

Sablonul mediator are urmatoarele avantaje si dezavantaje:- El limiteaza numarul de subclase generate.- Sablonul de cupleaza colegii.- Sablonul simplifica protocoalele de obiect.- Salonul abstractizeaza modul de cooperare al obiectelor.- Sablonul centralizeaza controlul.

Sabloane inruditeSablonul Facade difera de sablonul Mediator prin faptul ca abstractizeaza un

subsistem de obiecte astfel incat sa asigure o interfata mai convenabila. Protocolul sau este unidirectional; adica obiectele Facade genereaza cereri catre subclasele sistemului, dar nu si invers. Spre deosebire de sablonul Facade, sablonul Mediator permite compararea cooperanta pe care obiectele coleg nu pot sau nu vor sa o furnizeze, iar protocolul acestuia este multidirectional.

Colegii pot sa comunice cu mediatorul folosind sablonul Observer.

MementoFara a viola incapsularea, sablonul captureaza si exteriorizeaza starea interna a

unui obiect astfel incat aceasta sa poata fi redusa ulterior la respectiva stare.Aplicabilitate

Sablonul Memento se utilizeaza cand:- trebuie salvat un instantaneu al starii unui obiect, astfel incat acesta sa poata fi

readus ulterior la acea stare si- o interfata directa pentru a obtinerea starii ar expune detaliile implementarii si ar

sparge incapsularea obiectului.-

Structura

Participanti- Memento(SolverState): stocheaza starea interna a obiectului Originator;

protejeaza impotriva accesului altor obiecte, diferite de creator.

- Originator(ConstraintSolver): creeaza un memento care contine un instantaneu al starii sale interne curente.

- Caretaker(Mecanism de anulare): raspunde de pastrarea in siguranta a memento-ului; nu opereaza si nici nu examineaza nicodata continutul unui memento.

ColaborariUn obiect Caretaker solicita un memento de la un creator, il pastreaza pentru un

interval de timp si il trece inapoi creatorului, dupa cum ilustreaza urmatoarea diagrama de interactiuni:

Obiectele memento sunt pasive. Starea unui memento va fi atribuita sau preluata doar de catre obiectul Originator care l-a creat.

ConsecinteSablonul Memento are mai multe consecinte:

- Pastrarea limitelor incapsularii.- Sablonul simplifica obiectul Originaor.- Utilizarea memento-urilor poate fi costisitoare.- Definirea interfetelor reduse si largite.- Costuri ascunse ale ingrijiri obiectelor memento.

Sabloane inruditeSablonul Command: comenzile pot utiliza obiecte memento ca sa pastreze

starea operatiilor ce pot fi anulate.Sablonul Iterator: pentru o iteratie, obiectele memento pot fi utilizate asa cum a

fost descris anterior.

ObserverDefineste o dependenta “unu la mai multi” intre obiecte, astfel incat in cazul in

care un obiect isi schimba starea, vor fi instiintate si actualizate automat toate obiectele sale dependente.

Structura

Participanti- Subject: isi cunoaste observatorii; furnizeaza o interfata pentru atasarea si

detasarea obiectelor Observer.- Observer: defineste o interfata de actualizare pentru obiectele care trebuie sa fie

instiintate de modificarile dintr-un subiect.- ConcreteSubject: stocheaza starile ce prezinta interes pentru obiectele

ConcreteObserver; cand i se modifica starea trimite instiintari catre observatorii sai.

- ConcreteObserver: pastreaza o referinta catre un obiect ConcreteSubject; stocheaza starea, care trebuie sa fie consecventa cu cea a subiectului.

ColaborariUrmatoarea diagrama de interactiuni ilustreaza colaborarea dintre un subiect si

doi observatori:

ConsecinteSablonul Observer permite sa variem independent subiectii si observatorii.

Putem reutiliza subiectii fara a refolosi observatorii si viceversa. Sablonul permite sa adaugam observatori fara a modifica subiectul sau alti observatori.

Sabloane inruditeSablonul mediator: prin incapsularea semanticii actualizarilor complexe, obiectul

ChangeManager actioneaza ca un mediator intre subiecti si observatori.Sablonul Singleton: obiectul ChangeManager poate utiliza sablonul Singleton

pentru a-si asigura unicitatea si posibilitatea de accesare globala.

StatePermite unui obiect sa-si modifice comportamentul cand starea sa interna se

schimba. Obiectul va parea ca-si schimba clasa.

AplicabilitateUtilizam sablonul State in oricare din urmatoarele cazuri:

- Comportarea unui obiect depinde de starea sa si, la executie, obiectul trebuie sa-si modifice comportarea in functie de respectiva stare.

- Operatiile au instructiuni conditionale de mari dimensiuni, cu multe parti, care depind de starea obiecului. Aceasta stare este de obicei reprezentata prin una sau mai multe constante enumerate.

Structura

Participanti- Context(TCPConnection): defineste interfata de interes pentru clienti.- State(TCPState): defineste o interfata pentru incapsularea comportarii asociata

cu o anumita stare a obiectului Context.- SubclaseConcreteState: fiecare subclasa implementeaza o comportare

asociata unei stari a obiectului Context.

Sabloane inruditeSablonul Flyweight explica cum pot fi partajate obiectele State. Obiectele State

sunt deseori obiecte Singleton.

Despre sabloane comportamentale

Variatia incapsularii este o tema ce se regaseste in multe sabloane comportamentale. In cazul in care un aspect al unui program se modifica frecvent, aceste sabloane definesc un obiect ce incapsuleaza respectivul aspect. Apoi, alte parti ale programului pot colabora cu acest obiect ori de cate ori primele depind de respectivul aspect. De obicei, sabloanele definesc o clasa abstracta care descrie obiectul incapsulator, iar numele sablonului deriva din numele acestui obiect.

Aceste sabloane descriu aspecte ale unui program ce pot fi modificate. Majoritate sabloanelor au doua tipuri de obiecte: obiectul nou, care incapsuleaza aspectul, si obiectul existent, care il utilizeaza pe cel nou. De obicei, functionalitatea obiectelor noi va face parte integrala din obiectele existente, daca nu si din sablon. De exemplu, codul pentru un obiect Strategy se va regasi probabil in obiectul Context al strategiei, iar codul pentru un obiect State va fi implementat direct in obiectul context al starii.

Inca nu toate sabloanele comportamentale de obiect partitioneaza functionalitatea in acest fel. De exemplu, sablonul Chain of Responsability lucreaza cu un numar arbitrar de obiecte (adica un lant), toate putand sa existe deja in sistem.

Sablonul Chain of Responsability ilustreaza o alta diferenta intre sabloanele comportamentale: nu toate sabloanele definesc relatii de comunicare statica intre clase. Sablonul Chain of Responsability stabileste comunicare intre un numar nelimitat de obiecte. Alte sabloane implica obiecte ce sunt trecute ca argumente.

Mai multe sabloane introduc un obiect care este intodeauna utilizat ca argument. Unul dintre aceste sabloane este Visitor. Un obiect Visitor este argumpent pentru o operatie Accept polimorfica pe obiectul vizitat. Vizitatorul nu este nicodata considerat ca parte a codului obiectului Visitor pe clasele structuri de obiect.

Alte sabloane definesc obiecte care actioneaza ca token-uri care sunt trecute si invocate la un moment ulterior. In aceasta categorie intra sabloanele Command si Memento. In sablonul Command, token-ul reprezinta o cerere, in sablonul Memento, el reprezinta starea interna a unui obiect la un moment dat. In ambele cazuri, token-ul poate avea o reprezentare interna complexa, dar clientul nu este niciodata constient de acest lucru. Insa chiar si aici exista diferente. In sablonul Command este foarte important polimorfismul, deoarece executarea obiectului Command este operatie polimorfica. Spre deosebire de aceasta, interfata memento este atat de redusa incat un Memento nu poate fi trecut decat ca o valoare. Prin urmare, este foarte posibil ca el sa nu prezinte nici un fel de operatii polimorfice pentru clientii sai.

Mediator si Observer sunt sabloane concurente. Diferenta dintre ele este ca sablonul Observer distribuie comunicarea prin introducerea unor obiecte Observer si Subject, in timp ce un obiect Mediator incapsuleaza comunicarea dintre alte obiecte.

In sablonul Observer, nu exista un obiect unic care sa incapsuleze o restrictie, ci obiectele Observer si Subject trebuie sa coopereze pentru a pastra restrictia.Sabloanele de comunicare sunt determinate de felul in care sunt interconectati observatorii si subiectii: un singur subiect are de obicei mai multi observatori si, uneori, observatorul unui sbiect este, la randul lui, subiect pentru alt observator. Sablonul Observator mai mult centralizeaza decat sa distribuie. El pastreaza responsabilitatea intretinerii unei restrictii doar in obiectul mediator.

Consideram ca este mai usoara realizarea unor obiecte Observer si Subject reutilizabile decat a unor obiecte Mediator reutilizabile. Sablonul Observator promoveaza impartirea si cuplarea slaba intre obiectele Observer si Subject, ceea ce duce la clase cu granularitate mai fina, mult mai aparte pentru a fi reutilizate.

Pe de alta parte, fluxul de comunicare este mai usor de inteles in sablonul Mediator decat in sablonul Observer. Observatorii si subiectii lor sunt, de obicei, conectati imediat dupa ce au fost creati si, ulterior in program, este mai greu de observat cum sunt ei conectati. In cazul in care cunoasteti sablonul Observer, atunci intelegeti ca modul in care observatorii si subiectii sunt conectati este important si, de asemenea, stiti ce conexiuni sa cautati. Cu toate acestea, gradul de ocolire introdus de sablonul Observer ingreuneaza totusi intelegerea unui sistem.

in cazul in care obiectele care colaboreaza se refera direct unul la celalalt, ele devin dependente unul de celalalt, iar acest lucru poate avea un impact negativ asupra stratificarii si posibilitatii de reutilizare a unui sistem. Sabloanele Command, Observer, Mediator si Chain of Responsability se ocupa de modul in care puteti decupla expeditorii si destinatarii dar cu componente diferite.

Sablonul Command suporta decuplarea utilizand un obiect Command care defineste o legatura intre un expeditor si un destinatar.

Obiectul Command furnizeaza o interfata simpla pentru gestionarea cererii. Definirea conexiuni expeditor-destinatar intr-un obiect separat permite expeditorului sa lucreze cu destinatari diferiti. Acest lucru pastreaza decuplarea expeditorului de primitori, ceea ce faciliteaza reutilizarea expeditorilor. In plus, puteti reutiliza obiectul Command ca sa parametrizati un destinatar cu diferiti expeditori. Sablonul Command necesita, in mod special, o subclasa pentru fiecare conexiune expeditor- destinatar, cu toata ca sablonul descrie tehnici de implementare care evita generarea subclaselor.

Sablonul Observer decupleaza expeditorii de destinatari prin definirea unei interfete pentru semnalarea modificarilor in subiecti. Sablonul Observer defineste o legatura expeditor-destinatar mai slaba decat cea din sablonul Command deoarece un subiect poate avea mai multi observatori, iarnumarul lor poae varia la executie.

Interfetele Subject si Observer din sablonul Observer sunt proiectate pentru comunicarea modificarilor. prin urmare sablonul observer este potrvit pentru decuplarea obiectelor cand intre acestea exista dependente de date.

Sablonul Mediator decupleaza obiectele obligandu-le sase refere indirect unul la celalalt, prin intermediul unui obiect Mediator.

Un obiect Mediator transfera cererile intre obiectele Colleague si centralizeaza comunicarea lor. In consecinta, colegi pot vorbi unul cu celalalt doar prin intermediul interfetei Mediator. Deoarece aceasta interfata este data, Obiectul mediator ar putea fi obligat sa-si implementeze propria schema de transmisie pentru a obtine un grad mai

mare de flexibilitate. Cererile pot fi codificate si argumentele impachetate in asa fel incat colegii sa poata cere seturi cu numar nelimitat de operatii.

Sablonul Mediator poate reduce necesitatea generarii de subclase intr-un sistem, deoarece el centralizeaza, intr-o singura clasa, comportarea la comunicare in loc sa o distribuie in mai multe subclase. Insa schemele de transmitere ad-hoc deseori reduc siguranta tipurilor.

In final sablonul Chain of Responsability decupleaza expeditorul de destinatar prin trecerea cererii de-a lungul unui lant de destinatari potentiali.

Deoarece interfata dintre expeditori si destinatari este fixata, Sablonul Chain of Responsability ar putea necesita, de asemenea, si o schema particulara de transmitere. Prin urmare, Chain of Responsability are acelasi dezavantaj referitor la siguranta tipului ca si sablonul Mediator. Sablonul Chain of Responsability este o metoda buna de decuplare a expeditorului si destinatarului in cazul in care lantul face deja parte din structura sistemului si unul dintre obiecte are posibilitatea dea a rezolva cererea. In plus, deseori, acest sablon creste flexibilitatea prin faptul ca lantul poate fi usor modificat sau extins.

4. Rolul şabloanele de proiectare în rezolvarea problemele de proiectare

Şabloanele de proiectare rezolvă multe din problemele cu care se confruntă proiectanţii. Câteva din aceste probleme sunt urmatoarele:

Găsirea obiectelor adecvate

Un obiect, care intră în alcătuirea programelor OO, împachetează atât date, cât şi metode (operaţii) ce operează asupra datelor. Obiectul execută o operaţie când primeşte o cerere (mesaj) de la un client.

Mesajele reprezintă singura cale prin care un obiect este determinat să execute o operaţie, în timp ce operaţiile sunt singurul mod de a modifica datele interne ale obiectului. Din

cauza acestor restricţii 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 influenţat de mai mulţi factori care acţionează adesea în mod contradictoriu: încapsularea, granularitatea, dependenţele, flexibilitatea, performanţele, evoluţia, gradul de reutilizare etc.

Există mai multe metodologii OO: unele se concentrează pe substantivele şi verbele extrase din enunţul problemei, altele se concentrează pe colaborările şi responsabilităţile din sistem sau se modelează lumea reală şi obiectele găsite 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 abstracţie 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 neapărat şi pe cea viitoare. Abstracţiunile identificate în timpul proiectării sunt esenţiale în obţinerea unui sistem flexibil.

Şabloanele ne pot ajuta în identificarea unor abstracţiuni mai puţin 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 entităţi sub forma unui obiect. Asemenea obiecte sunt rareori descoperite în timpul analizei sau chiar a stadiului incipient al proiectării.

Determinarea granularităţii obiectelor

Obiectele ce compun un sistem pot varia enorm ca mărime şi ca număr. Ele pot reprezenta practic orice începând de la componente hardware până la aplicaţii î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 număr uriaş de obiecte la nivelurile cele mai fine de granularitate. Alte şabloane descriu căile prin care un obiect poate fi descompus în obiecte mai mici. Abstract Factory şi Builder reprezintă obiecte a căror unică responsabilitate este crearea de alte obiecte. Visitor şi Command reprezintă obiecte a căror unică responsabilitate este implementarea unui mesaj către alt obiect sau grup de obiecte.

Specificarea interfeţelor obiectelor

Pentru fiecare operaţie declarată într-un obiect se precizează numele, obiectele pe care le ia ca parametrii şi valoarea returnată; aceste elemente formează semnătura operaţiei. Mulţimea tuturor semnăturilor corespunzătoare operaţiilor dintr-un obiect reprezintă interfaţa obiectului. Interfaţa 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 corespunzătoare operaţiilor definite în interfaţa numită Window. Ca urmare, un obiect poate avea mai multe tipuri, adică o parte a interfeţei sale poate fi de un tip, iar altă parte de alt tip. De asemenea, mai multe obiecte pot partaja un anumit tip comun, daca interfeţele lor includ tipul respectiv. Interfeţele pot să conţină, la rândul lor, alte interfeţe ca submulţimi. Având două tipuri, T1 şi T2, vom spune că T1 este subtip al lui T2 dacă interfaţa T1 include interfaţa T2. În acest caz T2 este supertip al lui T1. Mai spunem ca T1 moşteneşte interfaţa T2.

Interfeţele 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 având implementări complet diferite pot avea interfeţe identice.

Când o cerere este trimisă unui obiect, operaţia care se va executa depinde de:

cerere obiectul care receptionează cererea.

Obiecte diferite care pot recepţiona cereri identice pot avea implementări diferite ale operaţiilor ce vor satisface cererile respective. Asocierea unei cereri cu un obiect şi cu o operaţie a obiectului la momentul execuţiei se numeşte 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 recepţiona, ştiindu-se că orice obiect a cărui interfaţă include o semnătura potrivită va fi bun;

obiecte având interfeţe identice pot fi substituite unul altuia la executie; această posibilitate de substituire se mai numeşte polimorfism.

Polimorfismul este un concept esenţial în cadrul tehnologiei orientate pe obiecte. El permite:

ca un obiect client să nu aibă nevoie să cunoască altceva despre alte obiecte decât că posedă o anumită interfaţă;

simplificarea definiţiei clienţilor;

decuplarea obiectelor unele de altele; ca la execuţie obiectele să-şi modifice relaţiile dintre ele.

În acest context, şabloanele de proiectare ne ajută la:

definirea interfeţelor; identificarea elementelor care NU trebuie să apară într-o interfaţă.

Astfel, şablonul Memento descrie modul de încapsulare şi salvare a stării interne a unui obiect pentru ca starea respectivă să poată fi restaurată ulterior. Şabloanele specifică de asemenea şi relaţii între interfeţe.

Specificarea implementării obiectelor

Implementarea unui obiect este definită prin intermediul clasei obiectului. Clasa unui obiect specifică datele interne ale obiectului şi definiţiile operaţiilor pe care acesta le poate executa.Obiectele sunt create prin instanţierea unei clase; se mai spune că un obiect este o instanţă a unei clase. Procesul de instanţiere a unei clase presupune alocarea de memorie pentru datele interne ale obiectului respectiv şi asocierea operaţiilor cu aceste date. O clasă poate fi instanţiată de mai multe ori, în felul acesta rezultând mai multe exemplare similare de obiecte.

Pe baza unor clase existente se pot defini noi clase, folosind moştenirea claselor. O subclasă moşteneşte de la una sau mai multe clase părinte (superclase) toate datele şi operaţiile definite în acestea din urmă. Obiectele instanţe ale subclasei vor

conţine toate datele definite în subclasa şi în clasele părinte putea executa toate operaţiile definite în subclasa şi în clasele părinte.

O clasă abstractă are drept scop principal definirea unei interfeţe comune pentru subclasele sale. Implementarea operaţiilor unei clase abstracte este pasată parţial sau în întregime subclaselor sale. De aceea, o clasă abstractă nu poate fi instanţiată. Operaţiile declarate într-o clasă abstractă, dar neimplementate se numesc operaţii abstracte. Clasele care nu sunt abstracte se numesc clase concrete.

O subclasă poate detalia sau redefini comportamentul claselor părinte. Mai precis, subclasa poate redefini (override) o operaţie care apare şi într-o clasă părinte, ceea ce permite subclasei să poată prelua cereri în locul superclasei.

O clasa mixin este o clasă care are drept scop oferirea unei interfeţe sau a unei funcţionalităţi opţionale altor clase. Ea este similară unei clase abstracte, în sensul că nu poate fi instanţiată, dar nu poate figura singură ca părinte al unor subclase, ci doar într-o schemă de moştenire multiplă.

5. Mecanisme ale reutilizarii

Problema este cum obţinem un software flexibil şi reutilizabil folosind concepte ca obiect, clasă, interfaţă, moştenire. Şabloanele constituie un răspuns.

Moştenirea şi compunerea obiectelor

Cele mai cunoscute tehnici de reutilizare a funcţionalităţii în cadrul sistemelor OO sunt moştenirea de clasă şi asamblarea sau compunerea obiectelor (object composition).

Moştenirea 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 părinte este vizibilă în subclase.

Asamblarea obiectelor reprezintă o tehnică de obţinere a unei funcţionalităţi noi prin asamblarea sau compunerea unor obiecte având interfeţe 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 nişte cutii negre.

Ambele tehnici au avantaje şi dezavantaje. Moştenirea de clasă se caracterizează prin următoarele (avantaje):

este definită static la compilare şi poate fi specificată direct, fiind suportată explicit de limbajele de programare;

permite modificarea uşoară a implementării operaţiilor reutilizate, şi anume într-o subclasă ce redefineşte o parte din operaţiile clasei părinte pot fi afectate şi operaţii moştenite dacă acestea apelează operaţii redefinite. În secvenţa C++ de mai jos este ilustrată sintetic această situaţie:

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 moştenită de la clasele părinte nu poate fi modificată în momentul execuţiei;

cel mai adesea clasele părinte definesc cel puţin parţial reprezentarea fizică a subclaselor lor, deci subclasele au acces la detalii ale implementării superclaselor. De aceea se mai spune că moştenirea de clasă încalcă principiile încapsulării;

modificările aduse implementării unei superclase vor forţa subclasele să se modifice şi ele. Dependenţele de implementare pot cauza probleme atunci când se încearcă reutilizarea subclaselor: dacă anumite aspecte ale implementării moştenite nu corespund necesităţilor aplicaţiei clasa părinte trebuie rescrisă sau înlocuită. Această dependenţă limitează flexibilitatea şi, în ultimă instanţă reutilizarea. O soluţie în acest caz ar fi aplicarea moştenirii de la clase abstracte, deoarece ele includ implementare în mică măsură.

Compunerea obiectelor se caracterizează prin:

se defineste în mod dinamic, la execuţie, prin faptul că anumite obiecte primesc referinţe ale altor obiecte;

necesită ca obiectele să-şi respecte unul altuia interfaţa, ceea ce presupune că interfeţele să fie proiectate astfel încât să nu împiedice utilizarea unui obiect în combinaţie cu mai multe tipuri de obiecte. Deoarece obiectele sunt accesate doar prin intermediul interfeţelor nu este încălcat principiul încapsulării. În decursul execuţiei orice obiect poate fi înlocuit cu altul, atâta timp cât obiectele respective au acelaşi tip. În plus, datorită faptului că şi implementarea unui obiect este scrisă tot în termenii interfeţelor altor obiecte, dependenţele de implementare vor fi substanţial reduse;

prin compunerea obiectelor se obţine 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 uşor de gestionat. Un proiect bazat pe compunerea obiectelor se caracterizează printr-un număr mai mare de obiecte şi un număr mai mic de clase, iar comportarea sistemului va depinde de relaţiile dintre obiecte, în loc să fie definită într-o clasă.

Toate aceste aspecte conduc spre formularea celui de-al doilea principiu al proiectării OO:

PREFERAŢI COMPUNEREA OBIECTELOR MOŞTENIRII DE CLASĂ. 

În mod ideal nu ar trebui create noi componente pentru a realiza reutilizarea. Pentru obţinerea funcţionalităţii dorite trebuie doar asamblate componentele prin intermediul compoziţiei 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 moştenire este mai uşor de folosit pentru a face componente noi în comparaţie cu compunerea componentelor deja existente. De aceea moştenirea şi compunerea obiectelor sunt folosite împreună.

Experienţa arată că adesea proiectanţii folosesc moştenirea în mod abuziv. De aceea se recomandă studiul şi aplicarea şabloanelor de proiectare, acestea bazându-se foarte mult pe compunerea obiectelor.

 

Delegarea

Reprezintă o cale de aplicare a principiului compunerii obiectelor. Într-o relaţie de delegare două obiecte sunt implicate în rezolvarea unei cereri, şi anume: obiectul care receptează mesajul – delegatorul - deleagă execuţia operaţiei corespunzătoare unui alt obiect - delegat. Acest lucru este oarecum similar cu situaţia în care subclasele pasează sarcina execuţiei unor operaţii claselor părinte (este vorba despre operaţiile moştenite şi neredefinite). Dar, în timp ce clasa părinte a unei subclase rămâne aceeaşi pe toată durata execuţiei, în cazul delegării obiectele delegat pot fi schimbate, cu condiţia să aibă aceeaşi interfaţă.

Delegarea este considerată ca un şablon de proiectare fundamental, pe ea bazându-se foarte multe din celelalte şabloane (de exemplu State, Visitor, Strategy, Mediator, Chain of Responsibility, Bridge).

Principalul avantaj al delegării este că face posibil foarte uşor să se compună comportari în timpul execuţiei, 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 înţeles decât software-ul static. În plus există şi penalităţi în timpul execuţiei.

Moştenirea şi tipurile parametrizate

Tipurile parametrizate reprezintă o altă tehnică de reutilizare a funcţionalităţii care nu este strict legată de modelul orientat pe obiecte. Ele permit definirea de către utilizatori a unui tip nou fără a specifica tipurile pe care acesta le foloseşte. Aceste tipuri se vor furniza ca şi parametrii unde se foloseşte acest tip parametrizat. De exemplu un tip Lista poate fi parametrizat prin tipul elementelor conţinute. Acesta poate fi întreg, şir de caractere, etc.

Printre limbajele care suportă această tehnică se numără 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ă diferenţe importante între aceste trei tehnici:

compunerea obiectelor permite modificarea în timpul execuţiei a comportamentului, dar presupune indirectare şi, ca urmare, poate fi mai puţin eficientă;

moştenirea oferă posibilitatea de a utiliza implementări deja existente ale unor operaţii, dar şi de a redefini în subclase operaţiile respective;

tipurile parametrizate permit modificarea tipurilor pe care o clasă le utilizează, dar, la fel ca şi moştenirea, sunt precizate la compilare şi nu mai pot fi modificate la execuţie.

6. XML generalitati

XML (eXtensible Markup Language), descendent al SGML (Standard Generalized Markup Language) este un meta-limbaj utilizat in activitatea de marcare structurala a documentelor, a carei specificatie a fost dezvoltata incepand cu 1996 in cadrul Consortiului World Wide Web (W3C), de un grup de cercetare condus de Jon Bosak de la Sun Microsystems, la care au aderat ulterior o serie de grupuri de experti din comunitatile academice (Text Encoding Initiative, NCSA, James Clark) si industriale (SUN, IBM, Netscape, Oracle, Adobe etc.). Prima versiune de XML a fost standardizata in februarie 1998, ulterior acest standard a mai fost revizuit de doua ori in octombrie 200 si respectiv in februarie 2004.

Meta-limbajul XML este o simplificare a limbajului SGML (din care se trage si HTML) si a fost proiectat in scopul transferului de date Intre aplicatii pe internet, descriere structura date.

XML este acum si un model de stocare a datelor nestructurate si semi-structurate in cadrul Bazelor de date native. Datele XML pot fi utilizate In limbajul HTML, permit o identificare rapida a documentelor cu ajutorul motoarelor de cautare. Cu ajutorul codurilor javascipt, php etc. fisierele XML pot fi inglobate in paginile de internet; cel mai elocvent exemplu este sitemul RSS care foloseste un fisier XML pentru a transporta informatiile dintr-o pagina web catre mai multe pagini web.

Documentele XML sunt realizate din unitati de stocare numite entitati, ce contin date parsate sau neparsate. Datele parsate sunt realizate din caractere, unele dintre ele formand

date caracter iar altele ca marcaje. Marcajele codifica o descriere a schemei de stocare a documentului si structura logica. XML furnizeaza un mecanism pentru a impune constringeri asupra schemei de stocare si a structurii logice.

Obiectivele de proiectare ale limbajului XML subliniaza simplitate , generalitate si usurinta in utilizare pe Internet . Reprezinta un format de date textuale, cu sprijin puternic pentru pentru limbile lumii, prin Unicode. Desi designul XML se concentreaza pe documente, este utilizat pe scara larga la reprezentarea structurilor de date arbitrare, de exemplu, in serviciile web .

Un document XML este format din marcaje (tag-uri) si date caracter.

Cuvantul marcaj (markup) a fost folosit initial pentru a descrie anumite adnotari, note marginale in cadrul unui text cu intentia de a indica tehnoredactorului cum trebuie listat un anumit pasaj. Generalizand, putem defini marcajul drept orice actiune de a interpreta explicit o portiune de interpreta explicit o portiune de text. Un marcaj (tag) este un sir de caractere delimitat de caracterele "<" si ">". Datele caracter reprezinta continutul marcajelor.

In XML, marcajele nu sunt folosite pentru afisarea datelor continute, ci au alte scopuri printre care:

asigura o sintaxa simpla si standardizata pe care analizoarele XML o pot folosi pentru a utiliza informatia stocata

asigura o metoda de a descrie structura ierarhica a continutului prin impartirea informatiei (datele caracter) in parti numite elemente care mai departe sunt descrise prin atribute. Structura ierarhica a intregului document este pusa in evidenta prin utilizarea marcajelor.

Un fisier XML cuprinde urmatoarele sectiuni:

Prolog Definitia tipului de document (optionala) Elementul radacina

Principalul motiv pentru care W3C incearca sa impuna XML este compatibilitatea.

Informatia structurata cu ajutorul XML va fi citita si interpretata ulterior in acelasi fel, indiferent de dispozitiv, fie el mobil, palmtop, PC sau Mac.

Multe interfete de programare a aplicatiilor (API-uri) au fost dezvoltate pentru a ajuta dezvoltatorii de software la prelucrarea datelor cu XML, si exista mai multe sisteme schematice pentru a ajuta la definirea de limbi bazate pe XML .

Incepand cu 2009, au fost dezvoltate sute de formate de documente folosind sintaxa XML, inclusiv RSS, Atom, SOAP si XHTML. Formatele bazate pe XML au devenit o structura de baza pentru multe instrumente de lucru in cadrul biroului, inclusiv Microsoft Office (Office Open XML), OpenOffice.org si LibreOffice (OpenDocument) si Apple iWork. XML a fost de asemenea adoptat dript limba de baza pentru protocoale de comunicare, cum ar fi XMPP .

6.1 Pattern-uri de proiectare a structurii XML

Prin pattern se intelege o solutie standard la o problema specifica, care si-a dovedit in timp eficienta.

Proiectarea structurii unui document XML

–Lungimea documentului

–Uşurinţa folosirii marcajelor(easeof authoring)

–Uşurinţa procesării (easeof processing)

–Uşurinţa validării

–Fexibilitatea

–Consistenţa

–Gradul de abstractizare

eXtensible Markup Language (XML) este un meta-limbaj de marcare recomandat de Consorțiul Web pentru crearea de alte limbaje de marcare, cum ar fi XHTML, RDF, RSS, MathML, SVG, OWL etc. Aceste limbaje formează familia de limbaje XML.

XML Design Patterns

–Oportunitatea folosirii XML-ului:UseXML

–Reutilizarea tipurilor de documente existente:

ReuseDocument Type

–Alegerea elementului/elementelor rădăcină:

Multiple Document Types,MultiRootDocumentTypes

–Stabilirea gradului de abstractizare:

Envelope,ShortUnderstandableNames,DomainElement,ContainerElement,CollectionElement

–Asocierea de metadate:Separate Metadata&Data,Metadata

in Separate Document,Head-Body,MetadataFirst

Meta-limbajul XML este o simplificare a limbajului SGML (din care se trage și HTML) și a fost proiectat în scopul transferului de date între aplicații pe internet, descriere structură date.

XML este acum și un model de stocare a datelor nestructurate și semi-structurate în cadrul bazelor de date native XML.

XML Design Patterns

–continuare

–Organizarea documentului

•Referenţierea unor construcţii: Declare Before First Use

•A ceea şi informaţie referenţiată în locuri multiple: Flyweight

•Arbore (ierarhie) versus graf:Marketplace

–Extinderea ulterioară:Catch-All Element,Role Attribute,Extensible , Content Model

–Asigurarea consistenţei: Common Attributes ,Consistent Element Se

Use XML –Determină situaţia în care XML e soluţia viabilă de reprezentare a informaţiei (semi)structurate. Existenţa unor reprezentări multiple:binar, CSV, HTML, baze de date relaţionale,obiecte serializate, XML. XML poate fi o soluţie adecvată când:

•Conţinutul (datele) trebuie separate de formatare

•Datele trebuie partajate între aplicaţii, organizaţii

•Reprezentareasă poată fi înţeleasă şi de oameni

•Reprezentareasă poată fi uşor procesată de calculator, independent de platformă şi de limbaj

Datele XML pot fi utilizate în limbajul HTML, permit o identificare rapidă a documentelor cu ajutorul motoarelor de căutare. Cu ajutorul codurilor javascript, php etc. fișierele XML pot fi înglobate în paginile de internet, cel mai elocvent exemplu este sitemul RSS care folosește un fișier XML pentru a transporta informațiile dintr-o pagină web către mai multe pagini web.

UseXML – Factori care trebuie considerati: simplitatea, extensibilitatea, interoperabilitatea, existenţa instrumentelor de procesare, transformarea facila în alte reprezentări,uşurinta validării, existenţa standardizări ShortUnderstandableNames Numele elementelor & atributelor trebuie să fie scurte şi uşor de înţeles atât de autori, cât şi de dezvoltătorii soft-ului de procesat documentul .Pattern-ul poate fi utilizat pentru orice tip de document.

Avantaje:

extensibilitate (se pot defini noi indicatori dacă este nevoie) validitate (se verifică corectitudinea structurală a datelor ) oferă utilizatorilor posibilitatea de a-și reprezenta datele într-un mod independent

de aplicație XML este simplu și accesibil (sunt fișiere text create pentru a structura, stoca și a

transporta informația) poate fi editat, modificat foarte ușor (necesită doar un editor text simplu precum

notepad, wordpad etc.)

Pattern-urile de proiectare a structurii XML presupun proiectarea unei aplicatii web (bazata pe tehnologiile XML). Acestea realizeaza separatia dintre modul de stocare a datelor, vizualizarea lor si maniera de procesare.

Pattern-ul consecrate este MVC.

Model-View-Controller (MVC)

Model-view-controller (MVC)  este un model arhitectural utilizat în ingineria software. Succesul modelului se datorează izolării logicii de business față de considerentele interfeței cu utilizatorul, rezultând o aplicație unde aspectul vizual sau/și nivelele inferioare ale regulilor de business sunt mai ușor de modificat, fără a afecta alte nivele.

Model-View-Viewmodel (MVVM) este un design pattern folosit în ingineria software care a fost introdus prima oară de către Microsoft ca o metodă de particularizare a modelului de prezentare introdus de Martin Fowler. De fapt se pare că Microsoft folosea MVVM pentru proiectele dezvoltate intern, precum Microsoft Expression Blend, pe când nucleul platformei WPF era în construcție. Bazat în mare parte pe modelul Model-View-Controller (MVC), acesta se adresează în special dezvoltării interfeței cu utilizatorii a platformelor moderne ((HTML5, Windows Presentation Foundation, - WPF, și Silverlight), acolo unde există un dezvoltator orientat special spre acest lucru, având sarcini diferite de ale unui dezvoltator obișnuit care se ocupă în general de logica business și de dezvoltarea interacțiunii cu serverul.

Ca structură, acesta este alcatuit din trei părți esențiale ce pot fi deduse și din denumirea design pattern-ului: un Model, un View și un ViewModel. Această structură seamană cu cea a MVC-ului, dar oferă în plus ușurința utilizării XAML-ului și a Windows

Presentation Foundation, prin cuplarea datelor cât mai aproape de Model folosind XAML, View Model și orice verificare de date a nivelului Business pentru a valida datele înaintea afișării acestora pe interfață. Modelul se referă la datele efectiv cu care se lucrează dar și la nivelul de acces la aceste date. Spre exemplu într-un model ar putea fi accesate obiecte care citesc din baza de date informații legate de o anumită persoană. View-urile, la fel ca și în cazul clasic se referă la partea vizuală care va fi afișată pe interfața grafică, cum ar fi butoanele, ferestrele, graficele și alte controale. Acestea nu conțin partea de logică business. Marele avantaj în acest caz este că un designer poate să se ocupe de partea grafică a aplicației lucrând doar cu view-ul, în timp ce logica din spate rămâne neafectată. ViewModel-urile reprezintă niște modele pentru view-uri, mai precis acestea se referă la o abstractizare a view-urilor care servesc și la binding-ul datelor între view și model. Pot fi privite și ca niște aspecte specializate ale Controalelor din design pattern-ul MVC (care acționează ca și data bindgins sau converters) în așa fel încât să schimbe informația din formatul modelului în formatul view-ului și să paseze comenzi din view în model. ViewModel-urile expun proprietățile publice, comenzile și abstractizările și au fost asemănate cu o stare conceptuală a datelor, spre depsebire de starea reală a datelor din model. Există discuții în ceea ce privește clasa din spatele view-ului. Majoritatea specialiștilor susțin că aceasta ar trebui să conțină doar metoda InitializeComponent() în cazul WPF și Silverlight, însă în anumite cazuri nu se merită mutarea unor metode în viewmodel.

View-ul comunică doar cu ViewModel-ul, în timp ce ViewModel-ul este privit ca un punct intermediar între View și Model. De asemenea, Modelul este singurul care interacționează cu baza de date. Acest model are sens în practică doar dacă se folosește în combinație cu o bază de date. În caz contrar obiectele de date precum entitățile din EDMX și Linq nu au logică în acest context. O diagramă a acestui design pattern poate fi observată și in figura de mai jos.

Alte două funcționalități care fac ca acesta să fie atât de des folosit sunt data template-urile și resursele de sistem. Template-urile aplică View-uri asupra obiectelor unui ViewModel. Programatorii pot să le declare în XAML și să lase resursele de sistem să localizeze în mod automat iar apoi să aplice acele template-uri la runtime.

Întrucât aceast design pattern poate fi destul de greu de implementat, au fost create câteva platforme care să ajute programatorii în implementarea lui cum ar fi MVVM Light sau Caliburn. Personal îl recomand pe cel din urmă deoarece oferă avantajul recunoașterii automate a view-ului de către viewmodel, nemaifiind necesară crearea unei clase ajutătoare care să facă acest lucru.

Să luăm un exemplu simplu cu o aplicație care afișează dintr-o bază de date informații despre produse : nume, preț unitar și id. În model va trebui să avem partea de accesare a datelor. Modul în care acestea vor fi accesate rămâne la latitudinea programatorului. Această clasă va implementa INotifyPropertyChanged și va conține cele 3 proprietăți, fiecare având pe setter OnPropertyChanged(„Proprietate”) pentru a semnaliza modificarea valorii proprietății. Trebuie acordată atenție în mod special numelui proprietății deoarece acesta se transmite ca și string.

Scopul MVC este de a tine separate logica business-ului si interfata utilizator, astfel incat cei care intretin aplicatia sa schimbe mult mai usor o parte, fara a afecta alte parti. In MVC, modelul contine informatiile (datele) si regulile business; view contine elemente din interfata utilizator (texte, input-uri ale formularelor etc); controller-ul genstioneaza comunicatia dintre model si view.

MVC-ul este compus din 3 tipuri de obiecte. Modelul este obiectul aplicatie. Vizualizarea este prezentarea sa pe ecran, iar Controllerul defineste calre prin care interfata cu utilizatorul reactioneaza la actiunile utilizatorului. Inainte de aparitia MVC , designul interfetei cu utilizatorul avea tendinta de a ingramadi aceste obiecte. MVC le separe pentru a creste gradul de flexibilitate si de reutilizare.

MVC separa vizualizare si modele , stabilind intre ele un protocol de tip abonat/instiintare. O vizualizare trebuie sa se asigure ca aspectul sau reflecta starea modelului.Ori de cate ori datele modelului se schimba, aceasta instiinteaza vizualizarile care depend de el. Ca raspuns, fiecare vizualizare obtine posibilitatea de a se actualize. Aceasta abordare va permite sa atasati la un model mai mare vizualizari are sa asigure prezentari diferite.

O alta caracteristica a MVC-uli este faptul ca vizualizarile pot fi imbricate. De exemplu, un panou de control cu butoane poate fi implementat ca o vizualizare complexa ce are imbricate vizualizari de butoane.Interfata cu utilizatorul pentru u inspector de obiecte poate fi compusa din vizualizarile imbricate prin clasa Composite View, o subclasa a clasei View, obiectele CompositeView actioneaza la fel ca obiectele View, o vizualizare compusa poate fi utilizata oriunde se poate utiliza o vizualizare, dar de asemenea ea contine si gestioneaza vizualizarea imbricate.

MVC-ul permite de asemenea sa se schimbe modulul in care o vizualizare raspunde la actiunile utilizatorului , fara a schimba prezentarea vizuala. De exemplu, pentru a schimba modul in care o vizualizare raspunde la utilizarea tastataturii sau ca ea sa foloseasca un meniu pop-up in locul tastelor de comanda. MVC-ul incapsuleaza mecanismul de raspuns intr-un obiect Controller. Exista o ierarhie de clase de controller , ceea ce faciliteaza crearea unui controller nou ca variatie a unuia existent.

O vizualizare utilizeaza o instant a unei subclase controller pentru a implementa o anumita stategie de raspuns. Ca sa implementeze o strategie diferita, ar trebui sa se inlocuiasca pur si simplu aceasta instant cu alt tip de controller. Chiar este posibil sa se schimbe controllerul unei vizualizari la rulare pentru a permite vizualizarii sa se schimbe modul in care raspunde la actiunile utilizatorului.De exemplu, o vizualizare poate fi dezactivata astfel incat sa nu accepte introducerea datelor, daca I se da pur si simplu un controller care ignora evenimentele de introducere a datelor.

Relatia vizualizare-controller este un exemplu de sablon de proiectare Strategy. O stategie este un obiect care reprezinta un algoritm . Sablonul este util cand se doreste schimbarea statistica sau dinamica a unui algoritm, cand este o multime de variante al

unui algoritm sau cand algoritmul are structure complexe de date pe care sa le incapsuleze.

MVC ul utilizeqaza si alte sabloane de proiectare cum ar fi Factory Method care precizeaza clasa prestabilita de controller pentru o vizualizare si Decorator care adauga derularea intr-o vizualizare. Insa principalele relatii MVC sunt date de sabloanele de proiectare Observator , Composite si Strategy.

Pattern-ul MVC are cele trei componente implementate in urmatorul mod:

- Model: aceasta componenta este destinata a inmagazina logica aplicatiei si starea sistemului. Este implementata prin Stratul de Persistenta (Entity Beans) si prin FaçadeSession Bean-uri.

- Control: reprezinta clasele ce realizeaza comunicarea intre clasele din Model si cele din View – in aplicatie se implementeaza prin clasele Action.

- View: este o colectie de clase reprezentand interfata cu utilizatorul (toate obiectele pe care utilizatorul le poate vedea pe ecran si cu care poate interactiona, cum ar fi butoane, casete de text, etc.) – este implementata prin totalitatea paginilor JSP, HTML, a stilurilor si a elementelor de design.

In afara de MVC, Yii introduce un front-controller, cu numele application, care reprezinta contextul in care se executa procesarea cererii client. Application rezolva cererea utilizator si o trimite mai departe controller-ului corespunzator care va trata efectiv cererea.

Urmatoarea diagrama arata structura statica a unei aplicatii Yii:

Urmatoarea diagrama arata fluxul tipic de lucru al unei aplicatii Yii atunci cand trateaza o cerere client:

1. Un utilizator face o cerere prin URL-ul http://www.example.com/index.php?r=post/show&id=1, iar serverul Web trateaza cererea prin executarea fisierul bootstrap index.php.

2. Fisierul index.php creaza o instanta application si o ruleaza.3. Aplicatia obtine informatii detaliate despre cererea utilizatorului de la o the detailed

user request information from componenta a aplicatiei cu numele request.4. Aplicatia determina controller-ul si action-ul cu ajutorul componentei urlManager. In

acest exemplu, controller-ul este post si se refera la clasa PostController; action-ul este show, iar semnificatia numelui este determinata de controller-ul in cauza.

5. Aplicatia creaza o instanta a controller-ului necesar pentru a trata mai departe cererea. Controller-ul intelege ca show se refera la metoda cu numele actionShow din clasa controller-ului. Apoi, aplicatia creaza si executa filtrele (ex. controlul accesului, benchmarking, etc) asociate cu aceast action. Action-ul este executat daca este permis de catre filtre.

6. Action-ul citeste din baza de date un model Post al carui ID este 1.7. Action-ul genereaza un view cu numele show si cu modelul Post.8. View-ul citeste si afiseaza atributele modelului Post.9. View-ul executa cateva widget-uri.10.Rezultatul generat de view este inclus intr-un layout.11.Action-ul termina generarea view-ului si afiseaza rezultatul utilizatorului.

Model

Această parte a controlatorului manipulează operațiunile logice și de utilizare de informație (trimisă dinainte de către rangul său superior) pentru a rezulta de o formă ușor de înțeles.

Viziune (View)

Acestui membru al familiei îi corespunde reprezentarea grafică, sau mai bine zis exprimarea ultimei forme a datelor: interfața grafică ce interacționează cu utilizatorul final. Rolul său este de a evidenția informația obținută până ce ea ajunge la controlator. De cele mai multe ori este construit dupa Model. Foarte frecvent orice proprietate din Model va avea propria component in GUI, numita editor. Anumite tipuri de proprietati au asociate adesea tipuri de editor standard.

Controller

Cu acest element putem controla accesul la aplicația noastră. Pot fi fișiere, scripts sau programe; orice tip de informație permisă de interfață. În acest fel putem diversifica conținutul nostru de o formă dinamică și statică, în același timp. Controllerul nu este deobicei un actualmente obiect, ci o colectie de metode si de listeners, deobicei construite impreuna atat in Model cat si in Viziune. Sablonul general este faptul ca atat Model-ul cat si View-ul au o anumita interfata ce ofera acces la valorile lor de date sau respective la editor.

Validarea (Validation)

Cand este posibila, este de preferat sa permitem modelului sa faca toate validarile valorilor necesare. Din pacate, in cazul anumitor limbaje sau in anumite circumstante, acest lucru nu este posibil. Atunci cand fie Modelul fie View-ul hotarasc ca o valoare ce a trecut de validare este invalid, controller-ul va trebui sa comunice View-ului ca acea valoare este invalida.

XML In-Out Tray

Organizeaza activitatea componentelor implicate in procesele de colectare si de vizualizare a datelor

Scop: dezvoltarea de conexiuni intre component traversate de date XML pastrand o cuplare slaba si o coeziune ridicata (similar cu pattern-ul Proxy)

Existenta unui “lipici” intre component

Rezulta independent de limbaj/platform

Information Grouping

Date la intrare documente XML, pattern-ul ofera o modalitate de a formata datele XML, grupate pe diverse criteria (asemanator lui group-by din SQL)

Asigura separarea intre formatul de reprezentare sic el de stocare a datelor, putand organiza informatiile intr-un mod diferit de cel al stocarii.

Alte exemple de pattern-uri de proiectare in XML:

External Assistant- Procesul de generare a formatului de prezentare plencad de la XML este

realizat de o aplicatie externa XML In Out Tray

- Rezolva problema obtinerii, procesarii si returnarii datelor XML, procesele interne de prelucrare fiind ascunse

XML Mediator- Rezolva problema inter-operabilitatii dintre aplicatii care utilizeaza

documente XML cu structure eterogene

External Assistant- Procesul de generare a formatului de prezentare plencad de la XML este realizat

de o aplicatie externa XML In Out Tray

- Rezolva problema obtinerii, procesarii si returnarii datelor XML, procesele interne de prelucrare fiind ascunse

XML Mediator- Rezolva problema inter-operabilitatii dintre aplicatii care utilizeaza documente

XML cu structure eterogene

Bibliografie:

1. Introducere2. Definitii si Geralitati

[1] – “Design Patters” by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides[2] – Wikipedia

3.1 Sabloane creationale[1] -  The evolution of MVC and other UI architectures from Martin Fowler.

[2] – “Design Patters” by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides

3.2 Sabloane structural3.3 Sabloane comportamentale

[1] – “Design Patters” by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides

[2] - Elemente de software reutilizabil orientat pe obiect. Traducere de Radu Biris, Editura Teora

4. Rolul şabloanele de proiectare în rezolvarea problemele de proiectare[1] - " The DCI Architecture: A New Vision of Object-Oriented Programming - Trygve Reenskaug and James Coplien - March 20, 2009.

[2] -  Simple Example of MVC (Model View Controller) Design Pattern for Abstraction

[3] - Buschmann, Frank (1996) Pattern-Oriented Software Architecture.

5. Mecanisme ale reutilizarii6. XML generalitati

[1] – “Design Patters” by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides[2] – Wikipedia

6.1 Pattern-uride proiectare a structurii XML6.2 Pattern-uri de proiectare a aplicaţiilor utilizând XML

[1] – E. Gamma et. Al.”Design Patterns” , Adisson – Wesley 1995

[2] – D. Baum, U. Merten “System Arhitecture with XML” Esevier Science 2003

[3] – S. Buraga , “Semantic Web” , Matrix Rom - 2004