Tehnici de proiectare software - Tipografia

TEHNICI DE PROIECTARE SOFTWARE
Proiectare orientată pe şabloane
Prof. univ. Dr. Tudor Bălănescu

Cuprins
I. Introducere...........................................................................................1
1.1. De ce şabloane?............................................................................................ 1
1.2. Scurt istoric ................................................................................................. 1
1.3. Concepte de bază în şabloane..................................................................... 2
II. Şabloane creaŃionale ..........................................................................3
II. 1. Abstract Factory........................................................................................3
11.2. Builder............."...........................................................................................7
11.3. Factory Mcthod ........................................................................................11
11.4. Prototype...................................................................................................14
11.5. Singleton................................................................................................... 17
III. Şabloane comportamentale ............................................................ 20
111.1. Chain Of Responsibility..........................................................................20
111.2. Command ............................................................................................... 24
111.3. Interpreter ...............................................................................................28
111.4. Iterator....................................................................................................31
111.5. Mediator ................................................................................................. 35
111.6. Memento ................................................................................................. 38
111.7. State ........................................................................................................ 41
111.8. Strategy...................................................................................................45
111.9. Visitor ..................................................................................................... 49
111.10. Template Method ................................................................................. 54
IV. Şabloane structurale ....................................................................... 58
IV.l. Adapter ................................................................................................... 58
IV.2. Bridge.......................................................................................................62
IV.3. Composite ................................................................................................65
IV.4. Decorator .................................................................................................69
IV.5. Facade ..................................................................................................... 73
IV.6. Flyvveight ................................................................................................ 76
IV.7. Half-Objcct Plus Protocol (HOPP)........................................................ 79
IV.8. Proxy ........................................................................................................83
V. Concluzii .........................................................................................87
Bibliografie ............................................................................................88

I. Introducere
1.1. De ce şabloane?
De multe ori realizarea unui proiect software, asemănător construcŃiei unei
^ase. nu conduce la rezultatul scontat. De aceea avem nevoie de îndrumare, de
echivalentul unui arhitect, de cineva care posedă cunoştinŃele şi experienŃa necesare
pentru design-ul unui software: avem nevoie de un guru în domeniul proiectării.
Din păcate, astfel de guru nu sunt prea mulŃi în lume, prin urmare companiile
trebuie să-şi formeze proprii experŃi software. Deci dorim crearea unui software de
calitate, dar nu ştim cum să luăm deciziile corecte, decizii care să ne conducă în final
'a realizarea unui produs de calitate.
Dacă totuşi există o modalitate de a colecŃiona cunoştinŃele de care avem
r.evoie tară prea mari dificultăŃi? Dacă putem totuşi să înregistrăm conceptele de
.iesign de software, construind o bază pentru generaŃiile viitoare? Există o astfel de
cale - şabloanele de proiectare.
Se ştie că experŃii recurg deseori la aplicarea unor soluŃii pe care le-au mai
rolosit atunci când rezolvă probleme noi. Apelează la vechile soluŃii pe care le
generalizează, adaptând apoi soluŃia generală Ia contextul noii probleme.
Ideea din spatele şabloanele de proiectare este realizarea unei căi standard de
reprezentare a soluŃiilor generale ale problemelor des întâlnite în dezvoltarea de -
oftware. Există câteva avantaje ale acestui lucru:
- cu timpul se pot construi cataloage de şabloane
- începătorii în dezvoltarea de software pot beneficia de pe urma
experienŃei acumulate în trecut
- şabloanele standard îi ajuta atât pe începători cât şi pe experŃi să înŃeleagă
implicaŃiile deciziilor pe care le iau
- şabloanele de proiectare au un vocabular comun, acest lucru făcând
comunicarea deciziilor către cei care dezvolta software-ul mult mai uşoară; decât să
r.escriem un design în detaliu, putem folosi un nume de şablon pentru a explica ceea
.e dorim să realizăm; putem de asemenea face o legătură între şabloane, putându-se
.-.cutând despre un set de şabloane de proiectare pentru Smalltalk într-o prezentare la
. nferinŃa OOPSLA din 1987. James Coplien a promovat de asemenea şabloanele,
^r;md o carte despre dezvoltarea şabloanelor pentru C++ la începutul anilor '90.
OOPSLA a oferit mediul excelent pentru schimbul de idei între creatorii
^Hoanelor de proiectare. Un alt forum important care a ajutat la evoluŃia şabloanelor
.: rost Hillside Group, creat de Kent Beck şi Grady Booch.

Probabil contribuŃia cea mai importantă în popularizarea şabloanelor de
proiectare a avut-o cartea din 1995 "Şabloane de proiectare: Elemente de re utilizare a
software-ului orientat pe obiecte", scrisa de Erich Gamma, Richard Helm, Ralph
Johnson şi John Vlissides.
După publicarea acestor două cărŃi, şabloanele de proiectare au început să se
bucure de un mare interes în rândul comunităŃii software. Limbajul Java s-a dezvoltat
in acelaşi timp în care şabloanele câştigau popularitate, deci cei care foloseau Java au
început să aplice şabloanele în proiectele lor. Continua creştere a popularităŃii
şabloanele de proiectare în Java s-a manifestat prin prezentări în conferinŃe ca
JavaOne. precum şi prin articole privind şabloanele în revistele dedicate limbajului
Java.
1.3. Concepte de baza în şabloane
La baza ideii de şablon stă conceptul de standardizare a informaŃiilor despre o
problemă comună şi soluŃia ei. Unul din cele mai folositoare rezultate ale muncii lui
Alexander a fost dezvoltarea formei sau formatului în care e reprezentat şablonul.
Este important ca un şablon să aibă un nume sugestiv şi să răspundă la
întrebarea "Ce face aceste şablon?". în plus, trebuie să mai includă o discuŃie asupra
problemei, o explicaŃie asupra modului în care şablonul rezolvă problema şi o
indicaŃie privind beneficiile şi importanŃa folosirii şablonului respectiv.
Evident, de-a lungul timpului au apărut variaŃii ale formei Alexandriene,
dezvoltate conform necesităŃiilor apărute în crearea unui anumit software. în cele ce
urmează se va folosi forma formată din următoarele template-uri:
a) Nume - un nume descriptiv al şablonului
b) Cunoscut şi ca - un nume alternativ, dacă există
c) ProprietăŃile şablonului - clasificarea şablonului. Şablonul va fi definit prin:
obiecte
l.Tip:
- creationale - şabloane pentru crearea obiectelor
- comportamentale - şabloane ce coordonează interacŃiunea obiectelor
- structurale - şabloane care asigură relaŃiile statice şi structurale dintre
- de sistem - şabloane care asigură interacŃiune la nivel a sistemului
2. Nivel:
- clasă - şablonul aplicat unei singure clase
- componentă - şablonul ce cuprinde un grup de clase
- arhitectural - şablonul e folosit pentru a coordona acŃiunile sistemului
sau ale subsistemului
d) Scop - o scurtă explicaŃie privind ceea ce face şablonul
e) Introducere - o scurtă descriere a unei probleme unde poate fi folosit şablonul
f) Utilizare - unde şi cum se poate folosi şablonul de proiectare
L T ) Descriere - discuŃie detaliată asupra şablonului - ce face şi cum se comportă
h) Implementare - o discuŃie despre ce trebuie făcut pentru a implementa şablonul
î) Beneficii şi inconveniente - consecinŃele utilizării şablonului
I) Variante ale şablonului - implementări alternative posibile
k) Şabloane asociate - alte şabloane care sunt asociate sau apropiate de şablon

II. Şabloane creaŃionale
Aceste şabloane realizează unul dintre cele mai comune lucruri în programarea
iernată pe obiecte - crearea obiectelor într-un sistem. Majoritatea sistemelor
ientate pe obiecte necesită instanŃierea în timp a multor obiecte, iar aceste şabloane
: iiină crearea obiectelor prin:
- instanŃiere generică - aceasta face ca obiectele să fie create în sistem fără a
:ntifica o clasă specifică în cod
- simplitate - unele şabloane fac uşoara crearea unui obiect, astfel că nu mai
■nuie scris un cod mare şi complex pentru instanŃierea obiectului
- constructori - unele şabloane forŃează constructorii de un anumit tip pentru a
:a obiectele în cadrul sistemului
II.l. Abstract Factory
• Cunoscut şi ca Kit sau Toolkit
ProprietăŃi
■ Scop
- Tip: creaŃional
- Nivel: componentă
Să asigure o modalitate de creare a familiilor de obiecte dependente sau
■r.rudite fără a specifica clasele lor concrete.
• Introducere
Presupunem că de doreşte crearea unei aplicaŃii care să fie un manager
personal de informaŃii, cuprizând adrese şi numere de telefoane. AplicaŃia va fi o
combinaŃie între o carte de telefoane şi un planificator personal, urmând a utiliza
intensiv datele ce conŃin adresele şi numerele de telefoane. Se pot crea iniŃial clase -
are să reprezinte adresa şi numărul de telefon. Se scrie apoi codul acestor clase astfel
încât ele să reŃină informaŃiile relevante. De exemplu, toate numerele de telefon din
America de Nord sunt formate din maxim zece cifre iar codul poştal are un format
specific.
Imediat ce codul claselor a fost scris corespunzător acestor condiŃii, ne dăm
seama că trebuie să facem acelaşi lucru şi pentru adrese şi numere de telefon din altă
;ară. de exemplu Olanda. Dar aici sunt alte reguli privind numerele de telefon şi
adresele, prin urmare clasele Address şi PhoneNumber trebuie modificate pentru a lua
in considerare regulile din noua Ńară.

Urmează apoi introducerea informaŃiilor despre altă Ńară şi aşa mai departe. Cu
fiecare nou set de reguli, clasele Address şi PhoncNumber devine din ce în ce mai
încărcate cu cod şi mai greu de lucrat cu ele. necesitând mereu şi o noua compilare.
Şablonul Abstract Factory rezolvă această problemă. Folosind acest şablon, se
poate defini o clasă generică AddressFactory care produce obiecte ce urmează
şablonul general dat de Address şi PhoneNumber.
Astfel fiecare Ńară va avea propria versiune a claselor Address şi
PhoneNumber. In loc de a adaugă mereu informaŃie claselor, se extinde Address la
AddressHolland şi PhoneNumber la PhoneNumberHolland. InstanŃe ale ambelor clase
sunt create printr-o clasa AddressFactoryOlanda. Acest lucru oferă o mare libertate de
extindere a codului iară a face modificări structurale majore în restul sistemului.
• Utilizare
Şablonul Abstract Factory se foloseşte când:
- clientul e independent de crearea produselor
- aplicaŃia e configurată folosind una din multele familii de produse
- obiectele trebuie create ca un set pentru a fi compatibile
- se doreşte relevarea unei colecŃii de clase doar prin legăturile şi relaŃiile
dintre clase şi nu prin implementarea lor
■ Descriere
Câteodată o aplicaŃie necesită folosirea unei game diferite de resurse sau medii
operative. Exemple ar fi lucrul în Windows, fişierele sistem sau comunicarea cu alte
aplicaŃii sau sisteme.
Astfel că se doreşte realizarea unei aplicaŃii destul de flexibile încât să
folosească o gama larga de resurse fără a fi nevoie să se rescrie aplicaŃia de fiecare
dată când o nouă resursă e introdusă. O modalitate de a rezolva această problemă este
de a introduce un creator generic de resurse şi anume Abstract Factory. Acesta are una
sau mai multe metode de creare, care pot fî apelate pentru a produce resurse generice
sau produse abstracte.
Tehnologia Java rulează pe mai multe platforme, de fiecare dată existând o
altă implementare a fişierelor sistem. SoluŃia pe care Java a adoptat-o este de a
abstractiza conceptele de fişiere şi de a nu arată implementarea lor propriu-zisă.
AplicaŃia poate fi dezvoltată folosind capacităŃile generice ale resurselor care prezintă
o funcŃionalitate reală.
în timpul rulării, clasele ConcreteFactories şi ConcreteProducts sunt create şi
folosite de aplicaŃie. Clasele concrete sunt conforme cu definirile lor din clasele
AbstractFactory şi AbstractProducts, astfel că ele pot fi utilizate direct fără a fi
rescrise sau recompilate.

Implementare
Diagrama de clase a şablonului Abstract Factory este următoarea:
De regulă pentru implementarea şablonului Abstract Factory de folosesc:
- AbstractFactory - o clasă abstractă sau o interfaŃă care defineşte metodele de
. _/.:e ale produselor abstracte
- AbstractProduct - o clasă abstractă sau o interfaŃă care descrie
- ".vM-iamentul general al resurselor care vor 1! folosite de aplicaŃie
- ConcreteFactory - o clasă derivată din clasa AbstractFactory şi care
■ .mentează metode de creare pentru unul sau mai multe produse concrete
- ConcreteProduct - o clasă derivată din clasa AbstractProduct şi care conŃine
■ j:nentarea unei resurse sau a unui mediu de operare specific
5

Beneficii şi inconveniente
In şablon Abstract Factory ajută la creşterea pe ansamblu a flexibilităŃii unei
i caŃii. Această flexibilitate se manifestă atât în etapa de design cât şi în cea de
.;ve a aplicaŃiei. în timpul design-ului. trebuie să se decidă viitoarele utilizări ale
:caŃiei. La rulare, aplicaŃiei îi pot fi uşor integrate noi caracteristici şi resurse.
Un alt beneficiu al acestui şablon este acela că el poate simplifica testarea
:ului aplicaŃiei. Implementarea unor clase de test şi anume TestConcreteFactory şi -
tConcretcProduct este simplă, putându-se astfel simula comportamentul aşteptat al
.:rselor.
Pentru a putea beneficia de acest şablon, trebuie definită cu atenŃie o interfaŃă
.crică corespunzătoare pentru produsul abstract. Daca produsul abstract e definit -
rect. realizarea unor produse concrete poate fi dificilă sau chiar imposibilă.
Variante ale şablonului
După cum s-a menŃionat anterior, se pot defini AbstractFactory şi
stractProduct ca interfeŃe sau clase abstracte, în funcŃie de necesităŃile aplicaŃiei sau
^referinŃe. Unele variante ale şablonului Abstract Factory permit producerea mai
.'.tor obiecte ConcreteFactory. rezultând o aplicaŃie care poate folosi simultan
tiiii multiple de ConcreteProducts.
Şabloane asociate
Printre şabloanele asociate lui Abstract Factory se numără:
- Factory Method
- Singleton
- Data Access Object
Exemplu
Dacă se doreşte ca un program să afişeze date în două locaŃii diferite, folosind
\;ză de date locală sau la distanŃă, se poate implementa o interfaŃă cu ajutorul
.-iiului Abstract Factorv astfel:
Bcneficii §'\ inconveniente
l.'n sablon Abstract Factory ajuta la crestcrca pe ansamblu a flexibilitatii unei
:catii. Aceasta flexibilitate se manifests atat in etapa de design cat si in cea de
^rc a aplicatiei. In timpul design-ului. trebuie sa se decida viitoarele utilizari ale
■.catiei. La rulare. aplicatiei fi pot fi usor integrate noi caracteristici si resurse.
Un alt beneficiu al acestui sablon este acela ca el poate simplifica testarea
v.ilui aplicatiei. Implementarea unor clase de test si anume TestConcreteFactory §i -
:ConcreteProduct este simpla, putandu-se astfel simula comportamentul asteptat al
.:rselor.
Pentru a putea beneficia de acest sablon, trebuie defmita cu atentie o interfata
.erica corespunzatoare pentru produsul abstract. Daca produsul abstract e definit
Meet, realizarea unor produse concrete poate fi dificila sau chiar imposibila.
\ ariante ale §ablonului
Dupa cum s-a mentionat anterior, se pot defini AbstractFactory si
straetProduct ca interfete sau clase abstracte, in functie de necesitatile aplicatiei sau
: v eferinte. Unele variante ale sablonului Abstract Factory permit producerea mai

.'.tor obiecte ConcreteFactory. rezultand o aplicatie care poate folosi simultan
::!ii multiple de ConcreteProducts.
Sabloane asociate
Printre sabloanele asociate lui Abstract Factory se numara:
- Factory Method
- Singleton
- Data Access Object
Exemplu
Daca se doreste ca un program sa afiseze date in doua locatii diferite, folosind
\;za de date locala sau la distanta, se poate implementa o interfata cu ajutorul
.-nului Abstract Factory astfel:
r.~-;:rface ConnectionFactory {
Local qetLocalConnection(); Remote
getRemcteCor.nection ( ) ;
\.;=s DataKanager implements ConnectionFactcry { boolean local = false;
Datalnfo[] data; public Local ger.LocalConnection() {
return new Local Mode(); } public Remote
getRemoteConnection() {
return new RemoteMode();
public void loadData { ) { if(local){
Local conn = getLccalConnection ( ) ; data = conn. ioadDB (
"dlo.db"; ;
.. r.z-:-,rface ConnectionFactory {
Local qetLocalConnection(); Remote
getRemcteCor.nection ( ) ;
r-. ass DataKanager implements ConnectionFactcry { boolean local = false;
Datalnfo[] data; public Local ger.LocalConnection() {
return new Local Mode(); } public Remote
getRemoteConnection() {
return new RemoteMode();
public void loadData { ) { if(local){
Local conn = getLccalConnection ( ) ; data = conn. ioadDB (
"dlo.db"; ;

II.2. Builder
ProprietăŃi
Scop
telse {
Rerr.ote conn = getRenoieConnecti ori (} ;
conn . connect2WWW ( "v«w . sorr.e . vihere . con:'
data = conn.loadDB("db.db");
i
)lic void setConnection(boolean b) { local = b;
- Tip: creaŃional
- Nivel: componentă
Sa simplifice crearea obiectelor complexe prin definirea unei clase al cărui
-:e de a construi instanŃe ale altei clase. Şablonul Builder realizează un produs
'dl în care. chiar dacă există mai multe clase, conŃine întotdeauna o clasă
Introducere
în managerul personal de informaŃii, utilizatorii pot dori a lucra cu un calendar
'.. Pentru aceasta trebuie definită o clasă Appointment conŃinând informaŃii
■J un singur eveniment, urmărind informaŃii precum:
- date de început şi sfârşit ale întâlnirilor
- o descriere a întâlnirii
- locaŃia întâlnirii
- participanŃii la întâlnire
Evident, aceste informaŃii sunt introduse de un utilizator atunci când îşi
jj./.ă o întâlnire, deci trebuie definit un constructor care să permită crearea unui
'Mect de tip Appointment (întâlnire). Diferite informaŃii sunt necesare pentru
JJ unui obiect întâlnire, depinzând de tipul acesteia. Unele întâlniri presupun
.Tiirea unei liste de participanŃi. Unele pot avea o dată de început şi una de sfârşit.
pot avea o singură dată. Când sunt luate în considerare aceste opŃiuni, crearea
:elor Appointment nu este trivială.
Sunt doua posibilităŃi de creare a obiectelor, insa nici una din ele atractivă. Se
rea constructori pentru fiecare tip de întâlnire în parte sau se poate scrie un
: ..etor enorm cu o mare funcŃionalitate logică. Fiecare dintre aceste modalităŃi
".convenienŃe - constructori mulŃi, logica devenind mult mai complexă. Mai rău
.-*.. ambele modalităŃi creează probleme atunci când se încearcă implementarea -
uhelase a clasei Appointment.

Daca însă responsabilitatea creării unei întâlniri e cedată unei clase speciale
AppointmentBuilder, atunci are loc simplificarea codului clasei Appointment.
AppoinlmentBuilder conŃine metode de creare a părŃilor unei întâlniri, având nume
sugestive. In plus. clasa AppointmentBuilder asigură că informaŃiile introduse la
crearea unei întâlniri sunt valide.
• Utilizare
Şablonul Builder se foloseşte când o clasă:
- are o structură internă complexă, în special una cu un set variabil de obiecte
asociate
- are atribute care depind unele de altele. Unul din lucrurile pe care şablonul
Builder îl poate face este să forŃeze construirea unui obiect complex
- foloseşte alte obiecte ale sistemului care pot fi dificil de obŃinut în timpul
creării
• Descriere
Deoarece şablonul se ocupă de construirea unui obiect complex din mai multe
surse posibile şi diferite, el se numeşte Builder - constructor. Pe măsura ce crearea
obiectelor creşte în complexitate, crearea obiectelor cu ajutorul constructorului poate
deveni dificilă. Acest lucru se întâmplă de regulă când obiectul nu depinde exclusiv
de resursele care se află sub controlul său.
Obiectele de tip afacere fac parte din această categorie. Ele necesită frecvent
date dintr-o bază de date pentru a se iniŃializa, precum şi asocierea cu alte obiecte de
tip afacere pentru a reprezenta cât mai fidel modelul de afacere. Un alt exemplu ar fi
un obiect compus din sistem, cum ar fi obiectul care reprezintă un desen într-un
program vizual de editare. Un astfel de obiect trebuie asociat cu un număr arbitrar de
alte obiecte imediat ce este creat.
In astfel de cazuri, este convenabilă definirea unei alte clase care să fie
responsabilă cu crearea. Şablonul Builder coordonează asamblarea obiectului produs:
crează resurse, reŃine rezultate intermediare şi pune la dispoziŃie structura funcŃională
a creării. In plus. el poate obŃine resurse de sistem necesare pentru construirea
obiectului produs.
• Implementare
Diagrama de clase a şablonului Builder este următoarea:
Director
-AbstractBuilderf] builder
+Product buildProductQ
pentru fiecare parte a
produsului builder.buildPartQ
0..*
ConcreteBuilder
+void buildPartQ
+Product getProductQ
inter face
AbstractBuilder
+void buildPartQ
creează. Product

Pentru implementarea şablonului Builer este nevoie de:
- Director - are o referinŃă către o instanŃa AbstractBuilder. Clasa Director
apelează metodele creaŃtionale pentru a construi diferite părŃi ale produsului, precum
şi Builder-ul
- AbstractBuilder - interfaŃa care defineşte metodele de creare disponibile
pentru crearea părŃilor diferite ale produsului
- ConcreteBuilder - implementează interfaŃa AbstractBuilder. Implementează
toate metodele necesare creării unui obiect real de tip Product. Metodele acestei clase
ştiu cum să proceseze informaŃiile primite de la clasa Director şi să construiască
părŃile respective ale obiectului Product. Clasa ConcreteBuilder are de asemenea ori o
metodă getProduct sau o metodă creatională care returneazâ instanŃa produsului
- Product - obiectul rezultat. El poate fi definit fie ca o clasă, fie ca o interfaŃă
■ Beneficii şi inconveniente
Pentru obiectele care necesită o creare în mai mulŃi paşi, Builder se comportă
ca un obiect de nivel înalt care supervizează procesul. F,I poate coordona şi valida
crearea tuturor resurselor şi dacă este nevoie pune Ia dispoziŃie o strategie de reluare a
procesului în cazul apariŃiei unei erori. Pentru obiectele care au nevoie de resurse de
sistem în timpul creării, cum ar fi conexiuni cu baza de date sau obiecte de tip afacere
deja existente, Builder are un o modalitate convenabilă de control al acestor resurse.
Principalul inconvenient al acestui şablon este acela că există o legătură
strânsă între produse şi toate obiectele create în timpul construirii acestora. Prin
urmare, schimbări care apar în produsul creat de Builder conduc de regulă şi la
modificări ale Builder-ului.
■ Variante ale şablonului
Este posibilă implementarea mai multor şabloane Builder în jurul unei singure
clase Builder. Pentru o mai mare flexibilitate, se poate extinde acest şablon de bază
prin una sau mai multe din următoarele posibilităŃi:
- se creează un şablon Builder abstract. Prin definirea unei clase sau interfeŃe
care să specifice metodele de creare, se poate produce un sistem mult mai generic care
poate găzdui diferite tipuri de Buildere
- se definesc metode ereaŃionalc multiple pentru Builder. Unele Buildere
definesc metode multiple pentru a pune la dispoziŃie o mai marc varietate de moduri
de iniŃializare a resurselor necesare
- se dezvoltă delegaŃi creaŃionali. Astfel, un obiect de tipul Director conŃine
metoda de creare ale produsul general şi apelează o serie de metode crcaŃionale ale
obiectului Builder. In acest caz, Obiectul Director se comportă ca manager al
:esului de creare al Builder-ului
■ Şabloane asociate
Printre şabloanele asociate se numără şablonul Composite. De multe
ori . donul Builder este folosit pentru a produce obiecte de tip Composite care au o .
jetură foarte complexă.
• Exemplu
Se poate folosi §ablonul Builder pentru crearea unui produs complex, de
.'.xemplu o mtalnire:

. ■ - - 2 class /ippoir tmGnt Bui 1 de r {
public static final int START_DATE_REQUIRED =■ 1; public static final
int END_ DATE_RF,QU1RED = 2; public static final int
DESCRTPTION__REQUIRED = 4; public static final int
ATTENDEE_REQUIRED = 8; public static final int
LOCATION_REQUIRED = 16; protected Appointment appointment;
protected int requiredElements; public void buildAppointment () {
appointment = new Appointment();
public void buildDates(Date starcDate, Dare endDate) { Date currentDate = new
Date(); if ( (startDate i= null) && (startDate.after (currentDate))) {
appointment.setstartDate(startDate); }
if ((endDate != null) && (endDate.after (startDate))) {
appointment.setEndDate(endDate); }
public void buildDescriution(String newDescription) {
appointment.setDescription(newDescription);
public void build-Attendees (ArrayList attendees) {
if ((attendees != null) && (!attendees.isEmpty())) {
appointment.setAttendees(attendees); }
public void buildLocation(Location newLocation) { if (newLocation !=
null) {
appointment.setLocation(newLocation); }
}
public Appointment getAppointment() throws
Inf orrriationRequiredException { requiredElements = 0; rf
(appointment.getStartDate() == null) {
requiredElements += START_DATE_REQUIRED; } if
(appointment.getLocation() == null) {
requiredElements += LOCATION_REQUIRED; } if
(appointment.getAttendees().isEmpty()) {
requiredElements += ATTENDEE_REQUIRED; } if
(requiredElements > 0) {
throw new InformationRequiredException
(requiredElements); } return
appointment;
public int getRequiredElements() { return
requiredElements;
II.3. Factory Method
• Cunoscut şi ca Virtual Constructor
• ProprietăŃi
Scop
- Tip: creaŃional
- Nivel: clasă
Să definească o metodă standard de creare a unui obiect, diferită de un
constructor, lăsând însă subclasei alegerea tipului obiectului ce urmează a fi creat.
• Introducere
Presupunem că se lucrează cu un manager personal de informaŃii. Acesta va
conŃine multe bucăŃi de informaŃii esenŃiale vieŃii de zi cu zi: adrese, întâlniri, date,
cărŃi citite şi altele. Aceste informaŃii nu sunt statice; de exemplu trebuie să se poată
modifica adresa a unei persoane atunci când aceasta se mută sau să se modifice
detaliile unei întâlniri dacă persoana de contact întârzie.

Managerul personal de informaŃii e responsabil de modificarea fiecărui câmp.
Marele dezavantaj este acela că el trebuie să cunoască toate tipurile de întâlniri
precum şi modificările care se pot face asupra lor. Fiecare articol conŃine diferite
câmpuri şi utilizatorul trebuie să vadă un ecran de intrare apropiat acestor câmpuri.
Devine foarte greu de introdus informaŃii despre noile tipuri de sarcini pentru că
trebuie adăugată managerului personal de informaŃii o noua capacitate de editare de
fiecare dată. potrivită pentru modificarea noului tip de articol. Mai mult. fiecare
schimbare apărută într-o sarcina specifică, cum ar fi adăugarea unui câmp nou unei
întâlniri, înseamnă modificarea managerului astfel încât el să recunoască noul câmp.
Se ajunge la un manager personal de informaŃii foarte încâlcit şi greu de întreŃinut.
SoluŃie este lăsarea articolelor, ca întâlnirile, să fie responsabile cu punerea la
dispoziŃie a propriilor editoare pentru administrarea adăugărilor şi modificărilor.
Managerul de informaŃii trebuie doar să ştie cum să ceară un anumit editor folosind
metoda getEditor. care se afla în fiecare articol ce poate fi editat. Metoda returnează
un obiect care implementează interfaŃa ItemEditor. managerul urmând a utiliza acest
obiect pentru a cere o componenta JComponent sau un editor GUI. Utilizatorii pot
modifica informaŃiile articolului pe care doresc sa-1 editeze şi editorul asigură că
schimbările sunt aplicate corect.
Toate informaŃiile despre cum trebuie editat un anumit articol sunt conŃinute în
editor, care este pus la dispoziŃie de articolul însăşi. Reprezentarea grafică a editorului
este de asemenea creată de editor. Acum se pot introduce noi tipuri de articole fără a
fi nevoie de modificarea managerului personal de informaŃii.
• Utilizare
Şablonul Factory Method se foloseşte când:
- se doreşte o flexibilitate mai mare prin lăsarea anumitor decizii, cum ar fi
cele privind tipul obiectului ce trebuie creat, pe mai târziu
11

- se doreşte ca o subclasa şi nu supraclasa ei. să decidă ce tip de obiect trebuie
creat
- se ştie când trebuie creat un obiect dar nu se ştie lipul acestuia
- este nevoie de câŃiva constructori suprascrişi care au aceeaşi listă de
parametri, lucru nepermis în Java. în schimb, se folosesc câteva şabloane Factory
Method cu nume diferite
■ Descriere
Acest şablon este numit Factory Method pentru că el creează obiecte atunci
când se doreşte acest lucru. Când se începe scrierea unei aplicaŃii, de multe ori nu este
clar ce tipuri de componente o să se utilizeze. în mod normal există o idee generală
despre operaŃiile pe care urmează să le facă anumite componente, dar implementarea
se face ulterior şi nu reprezintă consecinŃa acelui moment.
Flexibilitatea poate fi obŃinută utilizând interfeŃe pentru aceste componente.
Dar problema programării cu interfeŃe este aceea că nu se pot crea obiecte dintr-o
interfaŃă. Trebuie să existe o clasă implementată pentru a obŃine un obiect. In loc de a
codifica o clasă specifică implementată în aplicaŃie, se extrage funcŃionalitatea
constructorului şi se introduce într-o metodă. Aceasta metodă este Factory Method. Se
creează astfel o clasa ConcreteCreator a cărei responsabilitate este de a crea obiectele
corecte. Clasa ConcreteCreator creează instanŃe ale implementării - ConcreteProduct -
unei interfeŃe - Product.
• Implementare
Diagrama de clase a şablonului Factory Method este următoarea:
interface Creator
+Product facioryMethodQ
ConcreteCreator
+Product factoryMethodQ
return nevv ConcreteProductQ
instanŃia/.ă
interface Product
ConcreteProduct
Pentru implementarea şablonului Factory Method este nevoie de:
- Product - interfaŃa obiectelor create de şablon
- ConcreteProduct - clasa care implementează interfaŃa Product. Obiectele
acestei clase sunt create de clasa ConcreteCreator

- Creator - interfaŃa ce defineşte metoda iactorvMethod
- ConcreteCreator - clasa ce extinde clasa Creator şi conŃine implementarea
metodei factoryMethod. Ea poate returna orice obiect care implementează interfaŃa
Product
Beneficii şi inconveniente
Un beneficiu major este acela că managerul personal de informaŃii poate fi
foarte generic. Trebuie doar să ştie cum să ceară un editor pentru un articol.
InformaŃia privind modul de editare al unui articol specific este conŃinută în editor.
Editorul poate de asemenea crea interfaŃa grafică cu utilizatorul pentru editare. Acest
lucru face managerul de informaŃii mult mai uşor de utilizat, putându-se introduce noi
tipuri de informaŃii fără a fi nevoie de modificarea programului central.
Inconvenientul acestui şablon este acela că pentru a adăuga un nou tip de
produs, trebuie adăugată şi implementată o nouă clasă şi trebuie ori modificată o clasă
ConcreteCreator deja existentă ori creată o nouă clasă care să implementeze interfaŃa
Product.
• Variante ale şablonului
Există mai multe variante ale şablonului Factory Method:
- clasa Creator poate avea o implementare standard pentru metodele de tip
factoryMethod. In acest fel, clasa Creator nu trebuie să fie o clasă abstractă sau o
interfaŃă. Beneficiul este acela că nu trebuie implementată o subclasa a clasei Creator
- interfaŃa Product poate fi implementată ca o clasă abstractă, astfel putând fi
adăugate implementări pentru alte metode
- metoda factoryMethod poate avea un parametru. Poate apoi crea mai multe
tipuri de obiecte Product pe baza parametrului dat. Acest lucru duce la scăderea
metodelor de tip factoryMethod necesare.
• Şabloane asociate
Printre şabloanele asociate şablonului Factory Method se află:
- Prototype - evită implementarea unei subclase a clasei Creator
- Template Method - metodele de tip Template apelează de regulă metode de
tip factoryMethod
- Data Access Object - foloseşte şablonul Factory Method pentru a putea crea
instanŃe specifice ale obiectelor de tip Data Access Objects fără a necesita cunoştinŃe
despre baza de date specifică
■ Exemplu
Şablonul Factory Method poate fi folosit pentru realizarea unei picturi, după
cum urmează:
13

î n t e r r ci L.. e o h d o e \
public voia craw(;; }
dass Line impiements Shape {
Point x, y;
Line(Point a, Foint b; { x = a; y = b; }
public voj.d drawŃ; { //se desenează o linie } }
dass Square implemerits Shape {
Point start;
int width, height;
Square (Point s, irit w, int. h) {
start = s ; w i d t h = w ; height
= h;
}
public void drawŃ) { //se desenează un pătrat }
}
d a s s P a i n t in g {
Point x, y;
int width, height, radius; Painting(Point a,
Point b, int w, int h, int r)
x = a;
y = b;
width = w;
neight = h;
radius = r;
Shape pic;
Painting pt;
Shape drawLine Ń) {
return new Line(x,y);
Shace drawSquare ( ) {
return new Square(x, width, height);
ii (line) pic = pt.drawLine(); if
(square) pic = pt.drawSquare()
II.4. Prototype •
ProprietăŃi
• Scop
- Tip: creaŃional
- Nivel: clasă unică
Să facă crearea dinamică mai uşoară prin definirea de clase ale căror obiecte se
pot duplica.
14

• Introducere
In managerul personal de informaŃii, se doreşte copierea unei adrese astfel
încât utilizatorul să nu fie nevoit să introducă manual toate informaŃiile atunci când
creează un nou contact. O modalitate de rezolvare a acestei situaŃii presupune
următorii paşi:
- crearea unui nou obiect de tip Address
- copierea valorilor apropiate din obiectul de tip Address existent
Cu toate că acesta abordare rezolvă problema, ea are un mare inconvenient -
încalcă principiul încapsulării. Pentru a aplica soluŃia de mai sus, trebuie introduse
apelări ale metodelor pentru a copia informaŃiile din clasa Address în afara ei. Acest
lucru duce la îngreunarea întreŃinerii codului clasei Address. Este de asemenea dificilă
reutilizarea clasei Address în alte proiecte.
Deoarece codul ce se doreşte copiat aparŃine clasei Address, se pot evita
greutăŃile întâmpinate prin definirea unei metode de copiere în clasă. Această metodă
produce un duplicat al obiectului de tip Address cu aceleaşi date ca şi obiectul
original. Apelarea metodei printr-un obiect de tip Address existent rezolvă problema
într-o manieră mai bună şi mai apropiată de regulile programării orientate pe obiecte.
• Utilizare
Şablonul Prototype se foloseşte pentru crearea unui obiect care este copia unui
obiect deja existent.
• Descriere
Numele acestui şablon este sugestiv; el foloseşte un obiect drept prototip
pentru a crea o nouă instanŃă a lui cu aceleaşi valori. El permite programelor să
execute operaŃii cu copia unui obiect şi să iniŃializeze obiectele într-o stare care a fost
stabilită prin utilizarea sistemului. Acest lucru este de multe ori preferabil iniŃializerii
obiectului cu un set generic de valori.
Exemple clasice pentru acest şablon se regăsesc în editoarele grafice şi de text,
unde funcŃiile de copiere şi lipire pot îmbunătăŃi productivitatea utilizatorilor. Unele
sisteme de afaceri folosesc aceeaşi modalitate, producând un model iniŃial pe baza
unui obiect existent, model ce poate fi apoi modificat în funcŃie de noile cerinŃe.
• Implementare
Diagrama de clase a şablonului Prototype este următoarea:
Client
+void operationQ
Prototype p = new prototype.copy()
Prototype
+Prottotype copy()
15

Pentru implementarea şablonului Prototype este nevoie de:
- Prototype - conŃine metoda de copiere. Metoda întoarce o instanŃă a aceleaşi
clase cu aceleaşi valori ca şi instanŃa originală. Noua instanŃă poate fi o copie fidelă
sau superficială a celei originale
• Beneficii şi inconveniente
Şablonul Prototype este folositor deoarece permite sistemelor să producă o
copie a unui obiect utilizat, cu variabile deja setate la anumite valori, iară a depinde
de cele definite în constructor.
O copie superficiala face duplicatul doar a elementelor principale ale clasei;
astfel se obŃine o copie mai rapidă dar care poate să nu acopere toate necesităŃile.
Deoarece caracteristicile sunt copiate din original, copia indică tot obiectul iniŃial.
Prin urmare modificarea unui astfel de obiect afectează toate copiile.
OperaŃiile de copiere în adâncime fac duplicatul tuturor caracteristicilor unui
obiect. Acestea durează de regulă mai mult decât copierile superficiale şi pot fi foarte
costisitoare pentru obiectele care au o structură complexă. Acest lucru asigură faptul
că modificările într-o copie sunt izolate de alte copii.
• Variante ale şablonului
Variantele şablonului Prototype includ:
- Copy Constructor - acest constructor de copiere ia o instanŃă a aceleaşi clase
ca argument şi returnează o nouă copie cu aceleaşi valori ca şi argumentul. Beneficiul
acestei variante este aceea că intenŃia de a crea o noua instanŃă este clară dar o
singură modalitate de copiere poate fi executată.
- Clone Method - limbajul Java defineşte o metodă de donare în clasa
java.lang.Object - supraclasa tuturor claselor Java. Pentru ca metoda să poată fi
utilizată într-o instanŃă, clasa obiectului respectiv trebuie să implementeze interfaŃa
java.lang.Clonable pentru a indica că o instanŃă a acestei clase poate fi copiată
■ Şabloane asociate
Printre şabloanele asociate şablonului Prototype se afla:
- Abstract Factory - poate folosi şablonul Prototype pentru a crea noi obiecte
bazate pe cele aflate în uz
- Factory Method - poate folosi şablonul Prototype ca un template pentru noile
obiecte
• Exemplu
Un exemplu de şablon Prototype este chiar suprascrierea unei metode:
interface Shape {
public void draw();
i
class Line implements Shape {
public void draw() { System.out.println("line"); } }
16

c_i_ass bquare : nplenenus Sna". e ■,
pudic voi ci draw j ; { "yc .:-::.. : u~. . p r .ir.t In ( "squar e" ) ; }
L
J
class Circle irr.plerrents Shapc- {
public void draw() ; Systcr,.cur.priritInŃ"circle"); }
class Paintina {
public sr_a~ic void .tain ( Suriri g [ J args; {
Shape si ~- nev» L i n e ( ) ;
Shape s2 = nes Square();
Shape s3 = new Circle ( ) ;
oaint; ( si} ;
painr(s2);
paint ( s3} ; } static
void paint(Shape s) {
if (s instanceof Line) s.drawŃ)
if (s instanceof Square) s.draw
if îs insranceof Circle) s.draw
II.5. Singleton
• ProprietăŃi
• Scop
- Tip: creaŃional
- Nivel: obiect
Să existe doar o singură instanŃă a acestei clase în sistem, permiŃând altor clase
acces la această instanŃă.
■ Introducere
Din când în când este nevoie de un obiect global, unul care să fie accesibil de
oriunde dar care să fie creat o singură dată. Se doreşte ca toate părŃile aplicaŃiei să
poată utiliza obiectul folosind aceeaşi instanŃă. Un exemplu ar fi un istoric - o listă de
acŃiuni pe care le-a tăcut utilizatorul în timpul lucrului cu aplicaŃia. PărŃi multiple ale
aplicaŃiei folosesc acelaşi obiect HistoryList, fie pentru a adăuga o acŃiune a
utilizatorului fie pentru a şterge acŃiuni anterioare. O modalitate de a face acest lucru
este crearea unui obiect global de către aplicaŃie, urmând ca fiecare obiect care are
nevoie de el să aibă o referinŃă către obiectul global. Totuşi, poate fi foarte dificil de
determinat cum să se trimită această referinŃă şi ce părŃi ale aplicaŃiei au nevoie de
acest obiect.
O altă cale este de a crea valori globale folosind variabile statice. AplicaŃia ar
avea câteva obiecte statice în interiorul unei clase pe care le va accesa direct. Dar şi
această abordare are câteva inconveniente. Un obiect static nu este suficient deoarece
el va fi creat atunci când clasa se încarcă, nelăsând astfel nici o oportunitate de a
introduce date înainte de instanŃiere. Aici intra în joc şablonul Singleton. El permite
accesul uşor al întregii aplicaŃii la obiectul global.
17

• Utilizare
Şablonul Singleton se foloseşte când se doreşte o singură instanŃa a unei clase
care sa fie disponibilă peste tot.
■ Descriere
Şablonul Singleton asigură crearea unei singure instanŃe de către JVM. Pentru
a fi siguri că deŃinem controlul asupra instanŃtierii, constructorul trebuie declarat
privat. Apare însă o problemă: este imposibil de creat o instanŃă, astfel că o metoda de
acces este pusă la dispoziŃie de o metodă statică getlnstanceQ. Această metodă
creează o singură instanŃă, dacă nu există deja, şi returnează referinŃa singleton-ului
celui care apelează metoda. ReferinŃa către singleton este stocată ca un atribut static
privat al clasei singleton-ului pentru viitoare apelări.
Cu toate că metoda de acces poate crea singleton-ul. de cele mai multe ori el
este creat atunci când clasa este încărcată. întârzierea construcŃiei este necesară doar
dacă o anumită formă de iniŃializare trebuie făcuta înainte ca singleton-ul sa fie
instanŃiat.
• Implementare
Diagrama de clase a şablonului Singleton este următoarea:
Singleton
-Sinaleton instance = new SinaJetonO
-SingletonŃ) +Singleton
gctlnstanceQ
return instance
Pentru implementarea şablonului Singleton este nevoie de:
- Singleton - clasa ce conŃine un constructor privat, menŃine o referinŃă statică
privată către singura instanŃă a acestei clase şi pune la dispoziŃie o metodă de acces
statică care returnează referinŃa către singura instanŃă
• Beneficii şi inconveniente
Şablonul Singleton este singura clasă ce-şi poate crea o instanŃă. Nu se poate
crea o astfel de instanŃa fără utilizarea metodei statice puse la dispoziŃie. Nu este
nevoie a se trimite referinŃa către toate obiectele care folosesc acest singleton.
Totuşi. în funcŃie de implementare, pot apărea probleme ale firelor de execuŃie.
Trebuie avut mare grijă atunci când se iniŃializează un singleton într-o aplicaŃie cu
multiple fire de execuŃie. Fără un control adecvat, aplicaŃia poate conduce la un
"război" al firelor de execuŃie.

• Variante ale şablonului
Una dintre opŃiunile şablonului Singleton. de multe ori nebăgată în seama, este
aceea de a avea mai mult de o instanŃă într-o clasă. Beneficiul este că restul aplicaŃiei
poate rămâne la fel. în timp ce acelea care ştiu de aceste instanŃe multiple pot utiliza
alte metode pentru o obŃine alte instanŃe.
Metoda de acces a singleton-ului poate fi punctul de intrare către un set de
instanŃe, toate de un subtip diferit. Metoda de acces poate determina la rulare ce subtip
specific de instanŃă să returneze. Acest lucru poate părea ciudat, dar este foarte
folositor atunci când se utilizează clase dinamice. Sistemul care foloseşte singleton-ul
rămâne neschimbat, în timp ce implementarea specifică a singleton-ului poate fi
diferită.
• Şabloane asociate
Printre şabloanele asociate Singleton-ului se număra:
- Abstract Factory
- Builder
- Prototype
• Exemplu
unica:
Şablonul Singleton se poate utiliza pentru crearea unei conexiuni la distanŃă
final class KemoteConnection {
private Connect con;
privare static RemoteConnecticn re = nev;
RemoteConnection(connection) ; private
RemoteConnection(Connect c) { con = c;
public static RemoteConnection getRemoteConnection ( ) {
return re; } public void
setConnection(Connect c) f
this(c);
\
19

III. Şabloane comportamentale
Şabloanele comportamentale se concentrează pe controlul dintr-un sistem.
Unele căi de organizare a controlului într-un sistem pot aduce beneficii mari atât în
ceea ce priveşte eficienŃa cât şi în mentenanŃa sistemului.
III.l. Chain Of Responsibility
• ProprietăŃi
• Scop
- Tip: comportamental
- Nivel: componentă
Să stabilească un lanŃ în sistem astfel încât un mesaj să poată fi utilizat la
nivelul la care a fost primit sau să fie direcŃionat către un obiect care îl poate folosi.
• Introducere
Managerul personal de informaŃii poate fi folosit şi pentru managementul
proiectelor. El poate fi văzut ca o structură arborescentă de sarcini. O sarcină este
rădăcina arborelui, reprezentând proiectul însuşi. Sarcina de bază are un set de
subsarcini, fiecare din acestea având la rândul lor un set de subsarcini, şi aşa mai
departe. In acest fel, proiectul poate fi împărŃit într-un set de obiective legate între ele.
Cum se lucrează cu informaŃiile dintr-o astfel de structură? De exemplu, ar fi
de ajutor să se poată vedea cine e responsabil pentru un anumit set de sarcini. Cum se
atribuie grupuri de sarcini cuiva sau cum se trec sarcini altcuiva?
O modalitate este definirea unui atribut pentru fiecare sarcină care să
reprezinte persoana care o îndeplineşte. Când aceasta se schimbă, toate sarcinile şi
subsarcinile sunt modificate încât să conŃină numele noii persoane care le execută.
Insă această cale de reŃinere a persoanei răspunzătoare de o anumită sarcină este
ineficientă, necesitând înregistrarea unei cantităci mari de informaŃii. O alternativă
este referinŃa către unul sau mai multe obiecte centrale care reŃin numele
responsabililor de sarcini. Cu toate că această abordare utilizează mult mai eficient
memoria, ea necesită multă muncă pentru a realiza legăturile dintre sarcini şi obiectele
centrale folosite pentru reŃinerea datelor.
Ce se întâmplă însă atunci când se foloseşte arborele de sarcini însuşi pentru
managementul responsabililor de sarcini? Se defineşte o metodă în clasa sarcinii
numită getOwner, care atunci când este apelată, verifică dacă responsabilul a fost
specificat şi-i returnează numele în caz afirmativ. In caz contrar, sarcina apelează
metoda getOwner a sarcinii părinte a sa. Această soluŃie necesită mai puŃină muncă
decât în ambele cazuri de mai sus şi rămâne eficientă şi în ceea ce priveşte utilizarea
memoriei. Responsabilul de sarcini trebuie specificat doar într-o singură locaŃie a
arborelui. Obiectele de tip Task fac restul muncii, predând apelul metodei getOwner
sarcinilor părinte ale lor până când este găsită una ce conŃine informaŃii. Acesta e un
exemplu al şablonului Chain Of Responsibility.
20

• Utilizare
Şablonul Chain Of Responsibility se foloseşte când:
- există un grup de obiecte în sistem care pot răspunde la acelaşi tip de mesaj
- mesajele trebuie folosite de unul din obiectele din sistem
- mesajele folosesc modelul "folosire sau trimitere mai departe", adică unele
mesaje pot fi utilizate la nivelul unde au fost recepŃionate sau produse, în timp ce
altele trebuie trimise mai departe către alte obiecte
■ Descriere
Când unele acŃiuni au loc într-un sistem orientat pe obiecte, acestea sunt de
regulă reprezentate printr-un eveniment sau mesaj. Un astfel de mesaj poate lua forma
unei metode care e apelată sau poate fi un obiect al sistemului. Mesajul este apoi
direcŃionat către un alt obiect care poate răspunde sau utiliza mesajul. In cele mai
simple cazuri, acelaşi obiect care produce mesajul, răspunde la el. De exemplu, un
câmp unde se introduce un text poate produce un eveniment ca răspuns la acŃiunea
utilizatorului - cum ar fi tastarea.
In cele mai complexe cazuri, răspunsul la mesaje implică mai multe lucruri.
Un mesaj care cere o modificare în apariŃia interfeŃei grafice cu utilizatorul poate fi
analizat la mai multe niveluri. Dacă cererea este aceea de a se modifica aliniamentul
textului dintr-un câmp. componenta însăşi poate răspunde. însă o cerere de
schimbarea a aliniamentului întregului text va fi probabil direcŃionată către nişte
obiecte de nivel înalt.
Şablonul Chain Of Responsibility reprezintă un lanŃ pentru mesaje. Dacă un
obiect nu poate răspunde la un mesaj primit, el trimite mesajul mai departe către alt
obiect. în mod frecvent, şablonul Chain Of Responsibility este implementat după un
model părinte-fiu. Astfel, mesajele ce nu pot fi utilizate de către fiu sunt trimise
părintelui, şi aşa mai departe dacă este cazul, până când este întâlnit un obiect ce
poate răspunde mesajului. Şablonul Chain Of Responsibility este potrivit pentru o
varietate mare de activităŃi efectuate cu o interfaŃă grafică cu utilizatorul orientată pe
obiecte. FuncŃiile de ajutor, structura componentelor, formatare şi poziŃionare
cuprinse în interfaŃa grafica pot folosi acest şablon.
■ Implementare
Diagrama de clase a şablonului Chain Of Responsability este următoarea:
Client
interface Handler
void handleMessage ()
ConcreteHandler
-Handler handler
+void handleMessageQ
+void handlerMethod()
if(can handle)
handlerMethodQ
else
succesor.handleMessage()
21

Pentru implementarea şablonului Chain Of Responsibility este nevoie de:
- Handler - interfaŃa ce defineşte metoda folosită pentru trimiterea mesajului
către următorul Handler. Acest mesaj reprezintă de regulă doar apelarea metodei, dar
în cazul în care o cantitate mai mare de date trebuie încapsulată, poate fi trimis de
asemenea şi un obiect
- ConcreteHandler - clasa care implemetează interfaŃa Handler. Ea păstrează o
referinŃă către următoarea instanŃă către Handler. Această referinŃă este fie conŃinută
în constructorul clasei sau într-o metodă proprie. Implementarea metodei
handleMessage poate determina cum să se folosească metoda, cum să se apeleze
metoda handleMethod şi cum să se trimită mesajul către următorul Handler
■ Beneficii şi inconveniente
Şablonul Chain Of Responsibility oferă flexibilitate mare în procesarea
evenimentelor pentru o aplicaŃie, deoarece oferă posibilitatea de management a unor
evenimente complexe prin împărŃirea responsabilităŃilor între un număr de elemente
simple. Permite ca un set de clase să se comporte ca un întreg, astfel ca evenimentele
produse într-o clasă pot fi trimise către celelalte clase. Insă flexibilitatea acestui
şablon are un preŃ, el devenind dificil de dezvoltat şi testat. Pe măsură ce lanŃul devine
mai complex, trebuie monitorizată cu atenŃie propagarea evenimentelor. Eşecul în
trimiterea evenimentelor poate avea ca rezultat pierderea mesajelor, acestea rămânând
fără răspuns.
Daca mai multe mesaje sunt produse într-o perioadă scurtă de timp, ele fiind
apoi trimise de mai multe ori până sunt utilizate, are loc încetinirea sistemului.
• Variante ale şablonului
Exista mai multe căi de adaptare a şablonului Chain Of Responsibility încât el
sa răspundă cerinŃelor diverselor aplicaŃii. Cele două strategii luate în considerare sunt
cele de utilizare - handling - şi cele de trimitere mai departe - forwarding - a
mesajelor.
La cele de utilizare important este modul în care a fost implementat handler-ul.
Printre variantele acestor strategii se număra:
- Default Handler - unele implementări pornesc de la un handler de bază.
Acesta este de regulă folosit atunci când nu este definită explicit o clasă care să
trimită mesajul mai departe. Este de mare ajutor în evitarea pierderilor de mesaje
- Handle And Extend - în cazul acestei variante, utilizarea evenimentelor
implică adăugarea lor într-un comportament de bază pe măsura ce ele sunt propagate
de-a lungul lanŃului. Acesta este de ajutor în activităŃile de logare
- Dynamic Handler - unele implementări ale şablonului Chain Of
Responsibility permit ca structura de trimitere a mesajelor să fie modificată la rulare.
Prin definirea unei metode de setare pentru fiecare clasă a lanŃului, se poate defini şi
modifica lanŃul pe măsură ce este folosit în cadrul aplicaŃiei
Strategiile de trimitere mai departe a mesajelor definesc modalităŃi de utilizare
sau trimitere a mesajelor produse de o componentă:

- Handle By Default - utilizează orice mesaj care nu e trimis mai departe în
mod implicit
- Propagate By Default - trimite mai departe un mesaj care nu a fost utilizat
implicit
- Forward To Default Handler - mult mai complexă decât şablonul de baza,
aceasta abordare utilizează un handler implicit de mesaje. Orice mesaj care nu este
utilizat la nivel de componentă sau care nu este trimis mei departe către un alt handler,
va fi trimis automat handler-ului implicit
- Ignore By Default - orice mesaj care care nu e utilizat sau trimis mai departe,
este aruncat. Daca clasele din lanŃ produc evenimente care nu sunt folosite în
aplicaŃie, această variantă este o metodă acceptabilă de a le elimina. Totuşi, ea trebuie
utilizată cu atenŃie pentru a nu se elimina mesaje de care sistemul are nevoie
• Şabloane asociate
Printre şabloanele asociate se număra şablonul Composite. Şablonul
Composite pune la dispoziŃie suport pentru o structură arborescentă şi pentru
propagarea mesajelor iar Chain Of Responsibility conŃine reguli privind modul de
propagare. în plus, şablonul Composite tinde să trimită mesaje în jos - de la rădăcină
către ramuri - în timp ce şablonul Chain Of Responsibility trimite de obicei mesaje în
sus - de la ramuri către rădăcină.
• Exemplu
Se presupune că atunci când se cheltuiesc banii unei companii, trebuie cerută
aprobarea şefului sau a şefului şefului:
abstract class PurchasePcwer {
pretecred final double base = 500; protected
PurchasePower successor; public voia
setSuccessor(PurchasePower successor){
this.successor = successor; } abstract public
void processRequest(PurchaseRequest
requesr); i
ciass Manager extenas PurchasePower {
private final double ALLOWA3LE = 10 * base; public
void processRequest(PurchaseRequest request ) {
if(requesr.getAmount() < ALLOWABLE)
System.out.println("Manager will
approve Ş"+ request: . getAmount ());
el.se if (successor != nuli)
successor.processRequest(request);
class Director extenas PurchasePower {
private final double ALL0WA3LE = 20 * base; public void
processRequest(PurchaseRequest request ) { if (request.
getAmouni () < ALLOWABLE )
System, out . println ( "Director will approve $"■+-
request. gecAiriourit ( ) ) ;
else if(successor !— nuli)
successor.processRequest(request); }
23

class PurcnaseKequest {
privare irit r.unbei;
private dcubie artiourit;
private String purpose;
public PurchaseRecuest ( i:vo runcer, dcubie amount, String
puroose){
this.num.ber = riun;cer;
this . arr.ount -■ arnount;
this.purpose = purpose;
public aoubie getAmount { ) { return amounr.; } public void
setAmount(double amt) { amourit = amt; } public String
geiPurpose() { return purpose; } public void setPurpose(String
reason) {purpose = reason;} public irit getNurr.ber () { return
number; } public void setNumber (int nun;) { number = num; } }
class CheckAuthority {
public static void n;ain (String'] args) throws Exception{
Manager manager = new Manager(); Director director =
new Director(); manager.setSuccessor(director);
while (true) {
System.out.prinŃ In("IntroduceŃi suma:") ;
System.out.prinŃ(">");
double d = Double.parseDouble(new
BufferedReader(new inputStreamReader
(System.in)).readLine());
manager.crocessRequest(new PurchaseRequest(0,
d, "General"));
III.2. Command
• Cunoscut şi ca Action, Transaction
• ProprietăŃi
• Scop
- Tip: comportamental
- Nivel: obiect
Să învăluie o comandă într-un obiect astfel încât să poată fi stocată, trimisă
către diferite metode şi returnată ca oricare alt obiect.
• Introducere
Când un utilizator selectează o acŃiune ce urmeazc a fi executată, aplicaŃia
trebuie să ştie de unde să extragă datele relevante şi comportamentul acestora. în mod
normal, aplicaŃia ştie numărul opŃiunilor pe care le are un utilizator şi va reŃine acest
lucru într-un loc central. Când o opŃiune e selectată, aplicaŃia află ce trebuie să facă,
asamblează datele necesare şi apelează metodele corespunzătoare.
24

Multe din aplicaŃiile curente permit anularea fiecărei comenzi până la un
anumit punct, cum ar fi ultima salvare efectuată. Daca se doreşte introducerea acestui
lucru în aplicaŃia curentă, este nevoie de crearea unui istoric - o listă cu toate acŃiunile
pe care utilizatorul le-a efectuat, cu toate datele utilizate şi cu starea precedentă. După
vre-o trei sau patru acŃiuni, istoricul devine mai mare decât întreaga aplicaŃie şi asta
din cauza redundanŃei datelor.
Are mai mult sens combinarea acŃiunii utilizatorul într-un singur obiect -
obiectul Command. Acesta conŃine datele necesare pentru o acŃiune specifică, precum
şi comportamentul lor. Astfel, aplicaŃia doar invocă metoda de execuŃie a obiectului
Command care execută comanda. AplicaŃia nu mai trebuie să cunoască toate opŃiunile
disponibile şi poate fi uşor modificată încât să includă mai multe acŃiuni ale
utilizatorului.
• Utilizare
Şablonul Command se foloseşte pentru:
- anularea comenzilor, logare şi / sau tranzacŃii
- executarea comenzilor în momente diferite
• Descriere
O aplicaŃie care nu foloseşte şablonul Command trebuie să conŃină metode
care să se ocupe de fiecare eveniment care poate apărea. Prin urmare handler-ul
trebuie să aibă toate informaŃiile pentru a putea executa acŃiunea. Introducerea unor
noi acŃiuni necesită adăugarea de noi metode clasei handler-ului.
Şablonul Command încapsulează atât datele cât şi funcŃionalitatea necesară
pentru a executa o acŃiune sau cerinŃă specifică. El pune la dispoziŃie o separare între
cum trebuie executată o acŃiune şi momentul când trebuie executată. O aplicaŃie care
foloseşte şablonul Command creează o sursă, un receptor şi o comandă. Comanda
primeşte referinŃa către receptor şi sursa primeşte o referinŃă către comandă.
Obiectul comandă este trimis către cel care 1-a invocat, care implementează
interfaŃa Command. în forma ei cea mai simplă, interfaŃa are o metodă de executare.
Clasele care o implementează reŃin receptorul ca o variabilă de instanŃă. Când metoda
de executare e apelată, Command apelează metoda doAction din clasa Receiver.
Command poate apela mai multe metode ale clasei Receiver.
• Implementare
Diagrama de clase a şablonului Command este următoarea:
Invoker
interface Command
+void execulef)
ConcreteCommand
-Receiver target
----
►
Receiver
+void execute()
+void action()
25

Pentru implementarea şablonului Command este nevoie de:
- Command - interfaŃa ce defineşte metodele pe care le foloseşte clasa Invoker
- Invoker - clasa care apelează metodele de executare ale obiectului Command
- Receiver - Ńinta obiectului Command şi obiectul care îndeplineşte cerinŃa
- ConcreteCommand - clasa ce implementează interfaŃa Command
Atunci când metoda de executare e apelată, clasa ConcreteCommand apelează
una sau mai multe metode ale clasei Receiver. Când se implementează şablonul
Command, trebuie tăcute anumite alegeri privind utilizarea apelurilor. Se poate face
unul din următoarele lucruri:
- clasa care implementează interfaŃa Command se poate obŃine combinând
clasele Invoker şi Receiver. trimiŃând astfel direct toate apelurile
- clasa ConcreteCommand poate fi ia receptorul, rezolvând ea însăşi cerinŃele
• Beneficii şi inconveniente
Şablonul Command oferă flexibilitate în mai multe moduri:
- decuplarea sursei evenimentului de la obiectul care are cunoştinŃele necesare
pentru a efectua sarcina
- împărŃirea instanŃelor către Command între mai multe obiecte
- permite înlocuirea comenzilor şi receptorilor la rulare
- adăugarea uşoară de noi comenzi; se scrie o alta implementare a interfeŃei şi
se adaugă aplicaŃiei
• Variante ale şablonului
Printre variantele şablonului Command se numără:
- Undo - când se extinde interfaŃa Command cu o metodă de anularea a
comenzii, povara implementării acestei metode revine clasei care implementează
interfaŃa
Pentru a realiza anularea doar a ultimei comenzi, aplicaŃia trebuie să reŃină o
referinŃă doar către ultima comandă. Când se execută o anulare, aplicaŃia apelează
metoda de anulare doar a ultimei comenzi. Insă. utilizatorii pot să nu fie satisfăcuŃi
doar cu anularea ultimei comenzi. Pentru a realiza anulări multiple, aplicaŃia trebuie
să păstreze toate comenzile într-un istoric. Pentru a putea anula o comandă, interfaŃa
Command trebuie să salveze toate informaŃiile necesare reparării unui obiect
modificat. Aceste informaŃii includ receptorul şi orice argumente şi valori vechi.
Receptorul trebuie schimbat astfel încât comanda să poată restaura valorile originale.
Comenzile pot fi folosite de mai multe ori în contexte diferite. Prin urmare,
comanda trebuie copiată înainte de a fi introdusă în istoric. Copierea comenzii previne
erorile ce pot apărea în urma anulării şi executării repetate a ei. Mergând înapoi şi
înainte în istoric nu ar trebui să fie o problemă, dar în cazul unei implementări
incorecte, apar erori. Pentru a preveni asta. comanda ar trebui să reŃină câtă informaŃie
este necesară pentru inversarea acŃiunii. Dacă o parte din informaŃii sunt stocate în
receptor, şablonul Memento este cel mai indicat să reŃină starea receptorului.
26

- MacroCommand - o macrocomandă este o colecŃie de alte comenzi.
Macrocomenzile se pot crea folosind şablonul Composite. O macrocomandă conŃine o
listă de subcomenzi. Când metoda de executare e apelată, macrocomandă trimite
subcomenzi. Dacă macrocomandă suporta anulare, atunci toate comenzile interne
trebuie să suporte anulări
istoric
• Şabloane asociate
Printre şabloanele asociate se află:
- Composite - folosit pentru implementarea macrocomenzilor
- Memento - reŃine starea receptorului în vederea anularii unei comenzi
- Prototype - poate fi folosit pentru a copia comanda înainte de a o plasa în
- Singleton - în multe aplicaŃii, istoricul este implementat ca un Singleton
• Exemplu
Un exemplu al şablonului Command este următoarea clasă ce realizează
începerea şi terminarea unei acŃiuni:
class SubmitAction extends AbstractAction {
private Component target;
public SubmitAction (String name, Icon icon, Component: t){
putValue(Action.NAME, name);
putVaiue(Action.SMALL_ICON, icon);
putValue(Action.SHORT_DESCRIPTION, name + " the
program");
target = t;
public void actionPerformed(ActionEvent evt) {
JOptionPane.showMessageDialog(target, "click pentru
începere") ,-
class ExitAction extends AbstractAction {
private Component target;
public ExitAction(String name, Icon icon, Component t){
putValue(Action.NAME, name); putValue(Action.SMALL
ICON, icon); putValue(Action.SHORT_DESCRIPTION,
name + " the
program"); target - t; } public
void actionPerformed(ActionEvent evt) {
int answer = JOptionPane.showConfirmDialog(target,
"DoriŃi să ieşiŃi? ",
"Confirmare", JOptionPane.YES_NO_OPTION); if
(answer == JOptionPane.YES OPTION) {
System.exit(0);
27

III.3. Interpreter
• ProprietăŃi
• Scop
- Tip: comportamental
- Nivel: clasă
Să definească un interpretor pentru un limbaj.
• Introducere
Cum se rezolvă un puzzle? O persoană înzestrată poate primi cele 5000 de
piese şi după nişte calcule, ştie unde trebuie plasată fiecare piesă. O altă modalitate
este aceea de a alege piesele care aparŃin unei părŃi a puzzle-ului, încercând apoi
rezolvarea părŃii mai mici. Se încearcă piesele până când doua dintre ele se potrivesc,
repetându-se apoi procedeul până când o parte mai mica e terminată. Se combină după
aceea părŃile mai mici completându-se tot puzzle-ul.
De multe ori rezolvarea unei probleme se face în acest mod. împărŃindu-se
problema în subprobleme recursiv. Urmează apoi rezolvarea subproblemelor. Dar
când problemele sunt interdependenŃe, rezolvarea lor este dificilă.
Cea mai bună soluŃie este crearea unui limbaj simplu care să modeleze o
problemă complexă şi să rezolve fraza ce o descrie. Se poate simplifica astfel sarcina
obŃinerii soluŃiei.
• Utilizare
Şablonul Interpreter se foloseşte când:
- trebuie interpretat un limbaj simplu
- probleme recursive pot fi exprimate în acel limbaj
- eficienŃa nu este o problemă importantă
• Descriere
Şablonul Interpreter împarte o problemă în părŃi mai mici, apoi le reuneşte
într-o frază aparŃinând unui limbaj simplu. Se interpretează apoi fraza şi se rezolvă
problema pas cu pas. Acest lucru se face creând un arbore de sintaxă abstract.
O exemplu matematic simplu este: rezultat = (a + b) / c; rezultatul depinde de
valorile lui a, b şi c. Presupunând că valorile sunt 4, 2 şi 3. rezultatul va fi 2. Cum se
ştie acest lucru? Mai întâi, i se asociază mental lui a valoarea 4. lui b 2 şi lui c 3. Apoi
se adună a cu b, rezultând valoarea 6 care se împarte apoi la c. Rezolvând problema
cu şablonul Interpreter, se parcurge un set de paşi similar. Fiecare din variabile este un
operand, la fel cum sunt şi valorile intermediare. Regulile gramaticale (+ pentru
adunare şi / pentru împărŃire) sunt operaŃii sau operatori. Fiecare regulă gramaticală
este implementată într-o clasă separată şi fiecare valoare din dreapta regulii devine o
variabilă instanŃă.
28

• Implementare
Diagrama de clase a şablonului Interpretei" este următoarea:
Client
Context
Şablonul Interpretei" necesită:
interface Exprcssion
+void interpreUContext c)
TerminalExpression NonterminalExpression
+void interpret(Context c) +void interpret(Context c)
- Expression - interfaŃa prin intermediul căreia utilizatorul interacŃionează cu
expresiile
- TerminalExpression - clasa care implementează interfaŃa Expression,
utilizată pentru nodurile terminale ale arborelui de sintaxă
- NonterminalExpression - cealaltă implementare a interfeŃei Expression.
utilizată pentru nodurile neterminale ale arborelui de sintaxă. ConŃine o referinŃă către
următoarea expresie şi apelează metoda de interpretare pentru fiecare dintre copiii săi
- Context - conŃine informaŃiile necesare în mai multe locuri ale
interpretorului. Serveşte drept un canal de comunicare între instanŃele mai multor
expresii
- Client - construieşte sau primeşte o instanŃă a unui arbore de sintaxă abstract.
Acest arbore de sintaxă este compus din instanŃe ale obiectelor de tip
TerminalExpressions şi NonterminalExpressions
• Beneficii şi inconveniente
Şablonul Interpreter poate fi uşor modificat pentru a reflecta schimbările
produse în gramatică. Pentru adăugarea unei noi reguli se creează o altă clasă care
implementează interfaŃa Expression. O regulă se poate modifica uşor prin extinderea
clasei vechi şi suprascrierea metodei de interpretare.
Şablonul Interpreter nu este potrivit atunci când gramatica este mare. El poate
conduce la un număr mare de clase în cazul în care limbajul conŃine multe reguli.
Fiecare regulă adăugata limbajului necesită crearea unei noi clase în interpretor. Acest
lucru poate duce în final la probleme de testare şi mentenanŃă.
Se pot adăuga metode interfeŃei Expression pentru a mari funcŃionalitatea
expresiilor. Pentru o mai mare flexibilitate, se foloseşte şablonul Visitor care permite
schimbarea dinamică a metodei de interpretare.
29

Crearea arborelui de sintaxă abstract poate pune probleme, el nefiind definit de
şablonul Interpreter. Acesta presupune că arborele a fost creat altundeva.
• Şabloane asociate
Printre şabloanele asociate se află:
- Composite - structura pentru interpretarea expresiilor se bazează pe şablonul
Composite, folosind expresii terminale şi neterminale
- Flyweight - pentru reducerea numărului de obiecte redundante sau similare
- Iterator - pentru iterarea în cadrul arborelui de sintaxă abstract şi a nodurilor
sale
- Visitor - prin folosirea acestui şablon. Interpreter câştigă flexibilitate
• Exemplu
Considerând o expresie dată. cu ajutorul şablonului Interpreter se poate filtra
informaŃia care se doreşte:
public void myParser() {
StringTokenizer holder = new StringTokenizer
(expression, token); String[]
toBeMatched = r.ew Strir.g
[holder.countTokens()];
int idx == 0;
while(holder.hasMoreTokens () ) {
String item = holder.nextToken(); int start =
item.indexOf(","); if (start=--C) { iten = item.
substring ( 2 ) ; } toBeMatched[idx] = item; idx +4;
}
result = Arrays.asList(toBeMatched); }
public List getParseResult() { return result; }
public void interpret() {
StringBuffer buffer = new StringBuffer();
Listlterator iist = result.listlterator();
while(Iist.hasNext()){
Stri.ng tcken = (String)1 ist.next(); if
(token.equais("SFO")) {
token = "San Francisco";
}else if(token.equais("CA")) {
token = "Canada"; }
buffer.append(" " ^ token); }
interpreted = buffer.toString();
}
public String getInterpretedResult() {
return interoreted;
30

III.4. Iterator
• Cunoscut şi ca Cursor
• ProprietăŃi
• Scop
- Tip: comportamental -
Nivel: componentă
Să pună la dispoziŃie o cale de acces secvenŃial la articolele dintr-o colecŃie
care este independentă sau separată de colecŃia de bază.
• Introducere
Managerul personal de informaŃii utilizează multe colecŃii de vreme ce Ńine
evidenŃa unei cantităŃi mari de date. Adrese, contacte, proiecte, întâlniri, notiŃe, liste
cu lucruri ce trebuie făcute - toate aceste presupun abilitatea de a se reŃine grupuri de
obiecte legate între ele. Pentru a se putea salva toate aceste tipuri de informaŃii, se pot
crea clase care sa reŃină fiecare grup de articole în parte. în acest fel. se pot dezvolta
colecŃii care să îndeplinească nevoile specifice fiecărui grup de obiecte.
Apare însă o problemă atunci când se doreşte parcurgerea fiecărei colecŃii.
Dacă se creează clase care să îndeplinească nevoile obiectelor stocate, nu există nici o
garanŃie că elementele pot fi retrase şi folosite într-o modalitate uniformă. Întâlnirile
pot fi organizate în subgrupuri în funcŃie de date. în timp ce contactele pot fi stocate
alfabetic iar notiŃele pot fi ordonate secvenŃial.
Acest lucru conduce la scrierea de cod specific fiecărei colecŃii în parte pentru
a se putea naviga printre articolele fiecărui grup. precum şi copierea codului respectiv
în fiecare parte a sistemului unde se foloseşte un grup. Rezultă un cod foarte
complicat şi greu de întreŃinut. Mai mult. trebuie cunoscute fiecare tipuri de colecŃii
folosite în detaliu pentru a menŃine obiectele în managerul personal.
Şablonul Iterator rezolvă aceste probleme prin definirea unei interfeŃe
uniforme pentru parcurgerea oricărei colecŃii. Când se folosesc iteratori în sistem, se
pot utiliza aceleaşi metode de apel atunci când se navighează printr-o listă de
contacte, precum şi atunci când se printează o listă cu lucrurile ce trebuie făcute.
• Utilizare
Şablonul Iterator se foloseşte pentru:
- a pune la dispoziŃie o cale uniformă şi consistentă de a parcurge elementele
unei colecŃii care nu este legată de implementarea colecŃiei
- a permite parcurgerea colecŃiilor multiple, lăsând mai mulŃi clienŃi să
navigheze simultan în cadrul aceleaşi colecŃii de bază

■ Descriere
Şablonul Iterator permite standardizarea şi simplificarea codului ce trebuie
scris pentru parcurgerea unei colecŃii. Clasele ce implementează colecŃiile tind să fie
create pe baza a ceea ce se stochează şi nu pe baza cerinŃelor de parcurgere. Avantajul
oferit de Iterator este acela că prezintă o cale consistentă de a naviga în cadrul
colecŃiilor indiferent de structura de bază.
Un Iterator în Java foloseşte de regulă o interfaŃă care defineşte operaŃiile lui
principale, punând apoi la dispoziŃie una sau mai multe implementări care fac legătura
cu colecŃia de bază. OperaŃiile fundamentale ale Iterator-ului sunt:
- First
-Next
- IsDone
- Currentltem
Aceste operaŃii definesc serviciile de bază pe care un Iterator le oferă. în
termeni mai generali, un Iterator ar trebui să ofere următoarele capacităŃi:
- Navigation - mişcarea în faŃă şi în spate în cadrul colecŃiei
- Retrieval - obŃinerea elementului curent la care se face referinŃă
- Validation - deciderea dacă mai sunt elemente în colecŃie, Ńinându-se cont de
poziŃia curentă a Iterator-ului
Iteratorii pot conŃine şi operaŃii extinse, cum ar fi metode de mişcare către
primul sau ultimul element al colecŃiei.
• Implementare
Diagrama de clase a şablonului Iterator este următoarea:
interface Iterator
+Object fir st ()
+ Objecl nexJf)
+boolean hasMoreElement'()
+Object getCurrentElement'()
Concretelterator
+Object first()
+Object next()
+boolean hasMoreElement()
+Object getCurrentElement()
interface Aggregate
+Iterator gel'Iterator•()
ConereteAggregate
+Iterator getlteratorQ
return new ConcretelteratorQ
32

Pentru implementarea şablonului Iterator este nevoie de:
- Iterator - interfaŃa care defineşte metodele standard ale Iterator-ului. Minim,
ea trebuie să conŃină metode pentru parcurgerea, obŃinerea şi validarea elementelor
(first, next, hasMoreElements şi getCurrentltem)
- Concretelterator - clase care implementează interfaŃa Iterator. Aceste clase
conŃin o referinŃă către colecŃia de bază. în mod normal, instanŃele sunt create de clasa
ConcreteAggregate. Deoarece există o strânsa legătură între ConcreteAggregate şi
Concretelterator, aceasta din urmă face de obicei parte din prima
- Aggregate - interfaŃa ce defineşte o metodă pentru producerea Iterator-ului
- ConcreteAggregate - clasa ce implementează interfaŃa Aggregate, construind
la comanda un obiect de tip Concretelterator. Ea execută acŃiuni în funcŃie de
responsabilitatea fundamentală a sa de reprezentare a colecŃiilor de obiecte din sistem
• Beneficii şi inconveniente
Multe din beneficiile şablonului Iterator sunt date de avantajele definirii unei
interfeŃe uniforme pentru parcurgerea colecŃiilor. Se simplifică astfel considerabil
utilizarea colecŃiilor şi se permite folosirea polimorfismului în lucrul cu colecŃiile.
Pentru printarea elementelor dintr-o colecŃie, de exemplu, se poate folosi un Iterator,
apelându-se metoda toString pentru orice obiect, indiferent de colecŃia de bază.
în plus, Iteratorii permit clienŃilor navigarea multiplă în cadrul aceleiaşi
colecŃii. Iterator-ul poate fi privit ca un cursor în interiorul colecŃiei.
Un inconvenient al acestui şablon este acela că oferă iluzia de ordine în
structurile neordonate. De exemplu, pentru un set ce nu suportă ordonare, Iterator-ul
va pune la dispoziŃie elementele într-o secvenŃă arbitrară care se poate schimba de-a
lungul timpului. Dacă nu se observă acest lucru, se poate scrie un cod pentru
asigurarea consistenŃei în structura de bază, apărând astfel probleme.
• Variante ale şablonului
Şablonul Iterator prezintă mai multe posibilităŃi de implementare. Obiectele de
tip Concretelterator pot fi interne sau externe. Iteratorii externi au metode specifice
pentru navigarea în cadrul colecŃiei, în timp ce Iteratorii interni permit navigarea în
ciclu printre elemente.
Obiectele de tip Concretelterator pot fi dinamice sau statice. Un obiect
dinamic face o referire directă către colecŃia de bază, deci va reflecta mereu starea
acesteia. Pe de alta parte, un obiect static creează un instantaneu al colecŃiei,
referindu-se la această copie pe durata utilizării.
Iteratorii nuli pot fi definiŃi pentru parcurgerea structurilor complexe, cum ar fi
arborii. Folosind un iterator ce reprezintă un "nod final", este posibilă scrierea unui
cod recursiv simplu pentru vizitarea tuturor nodurilor arborelui.
• Şabloane asociate
Printre şabloanele asociate se află:
- Factory Method - clasele ce implementează colecŃiile conŃin de regulă o
metodă de producere a Iterator-ului
33

- Visitor - atunci când şablonul Yisitor este folosit pentru un grup de obiecte,
un Itcrator este de asemenea folosit pentru parcurgerea în ciclu a elementelor
- Value List Handler - acest şablon se bazează pe Iterator în sensul că permite
clientului să sară peste o colecŃie
• Exemplu
Avem interfaŃa Emplovee şi clasele Manager şi Worker care o implementează.
Clasa EmployeeTcst va crea o listă şi va folosi un iterator pentru a o parcurge:
interface Employee { public abstracr. double earr.ings ( ) ; )
class Manager inpîements Err.ployee { private dcuble
weeklySalary; private String name; public Manager (String
narne, double s) {
this.nane = name; setWeeklySalary ( s) ;
} void setWeeklySalary(double s) {
if (s > 0) { weeklySalary = s; }
else weeklySalary = 0;
}
public double earnings() { return weeklySaiary; }
public String get Name () { return narr.e; }
public Strinq toStringO {return "Manager:" + getName();}
}
class Worker impienents Employee { private doubie
wagePerPiece; private int quantity; private
String name; public Worker (Strmg narne, douoi e
w, mt q) {
this.name = name;
setWagePerPiece Ńw) ;
setQuantity(q);
i
void setWagePerPiece(double w) {
if (w > 0) wagePerPiece = w;
else wagePerPiece = 0;
}
void setQuantity(int q) {
if ( q > 0) quantity = q; else
quantity = 0; }
public String getName() { return name; }
public double earnings() {return quantity*wagePerPiece;} public
String toString() {return "Worker:" + getName(); } ) class
EmployeeTest {
public static void main(String[] args) {
iava.util.List list = new ArrayList();
list.add(new Manager("Bill", 800.00));
list.add(new Worker("Al", 2.5, 200));
list.add{new Manager("Peter", 1200.00));
list.add(new Worker("Mark", 4.5, 333));
Iterator iterator = list.iterator();
while(iterator.hasNext()) {
Employee em == (Employee ) iterator . next ();
System.out.prinŃ(ei + " câştigă $"); System,
out .println (ora. earnings ( ) } ;
34

III.5. Mediator
• ProprietăŃi
• Scop
- Tip: comportamental
- Nivel: componentă
Să simplifice comunicarea între obiectele unui sistem prin introducerea unui
singur obiect care să se ocupe de transmiterea mesajelor între celelalte.
• Introducere
O caracteristică folositoare a managerului personal de informaŃii este aceea de
distribuire a informaŃiilor între mai mulŃi utilizatori, astfel încât cineva să poată aranja
o întâlnire la care un alt utilizator să participe. în acest fel, toŃi participanŃii vor fi
ŃinuŃi la curent cu planurile de întâlniri.
Cum se pot însă administra întâlnirile, presupunând că mai multe managere de
informaŃii rulează? O modalitate este de a da fiecăruia o copie a unui obiect de tip
Appointment, asigurându-se că ele au acces local la date. Apare o problemă: cum se
menŃine informaŃia consistentă între toŃi utilizatorii? De exemplu, dacă un utilizator
creează o întâlnire iar mai târziu îi schimbă data. cum află ceilalŃi participanŃi la
întâlnire acest lucru? Se poate face aplicaŃia utilizatorului responsabilă şi cu
administrarea modificărilor, Totuşi, dacă unuia dintre participanŃii la întâlnire i se
permite să facă modificări, asta înseamnă că fiecare manager de informaŃii trebuie să
urmărească activitatea celorlalte managere. Administrarea comunicării între un număr
mare de participanŃi devine foarte dificilă. în cel mai bun caz, este ineficient şi
costisitor în ceea ce priveşte reŃeaua: în cel mai rău caz. planificarea unei întâlniri se
transformă în haos.
Având în vedere posibila complexitate a sistemului, este preferabilă
trimiterea/primirea cerinŃelor către/de la un obiect central care să ia decizii privind
metodele de apelare. Aceasta este esenŃa şablonului Mediator. în loc de a face
obiectul de tip Appointment responsabil de trimiterea modificărilor, se creează un
obiect AppointmenfMediator. De fiecare dată când obiectul Appointment se modifică,
se apelează o metoda a Mediator-ului care poate decide apelarea unor metode pentru a
confirma modificările. în funcŃie de rezultat, obiectul AppointmentManager transmite
mesajul original sau o versiune revizuită a lui care conŃine datele privind modificarea
orei întâlnirii sau anularea acesteia.
Utilizare
Şablonul Mediator se foloseşte când:
- există reguli complexe ale comunicării între obiectele sistemului
- se doreşte ca obiectele să fie păstrate simple şi uşor de administrat
35

• Descriere
Pe măsură ce comunicarea între obiectele unei aplicaŃii devine din ce în ce mai
complexă, administrarea acesteia este mult mai dificilă. Manipularea evenimentelor
pentru controlul unei simple foi de calcul tabelar poate implica scrierea unui cod
pentru fiecare componentă reŃea. Totuşi, dacă interfaŃa grafică cu utilizatorul este
estinsă pentru a include o reŃea, un grafic şi pentru a înregistra câmpurile afişate, ea
devine mult mai dificilă în ceea ce priveşte administrarea codului. O schimbarea a
uneia dintre componente poate produce modificări în alte componente.
Şablonul Mediator permite rezolvarea acestei probleme, definind o clasă a
cărei responsabilităŃi este comunicarea în general. Se simplifică mult celelalte clase
ale sistemului, nemaifiind necesară administrarea comunicărilor propriu-zise.
Obiectul mediator are rolul unui drum al sistemului, centralizând logica privind
trimiterea şi primirea mesajelor. Componentele trimit mesaje către mediator şi se
bazează pe acestea să le trimită notificări ale modificărilor apărute. Implementarea
Mediator-ului se face atunci când interfaŃa grafică cu utilizatorul trebuie să se
comporte ca un întreg.
Pentru a ilustra utilitatea reală a şablonului Mediator, se pot considera
conferinŃele telefonice. Multe companii de telefonic oferă teleconferinŃe iar interfaŃa
de comutare a interlocutorilor este un fel de mediator. Ea permite transmiterea
mesajelor între indivizii care participa la conferinŃa.
• Implementare
Diagrama de clase a şablonului Mediator este următoarea:
interface Mediator interface Client
+void broadcastEventf)
+void broadcastEventQ
-Client[] clients
ConcreteMediator
pentru toŃi clienŃii c c.handleEventQ
Implementarea şablonului Mediator necesită:
+void handleEventf)
+void
broadcastEventf)
+void
ConcreteClient
-Mediator mediator
handleEventQ +void
broadcastEventQ
med iator.broadcastEvent()
- Mediator - interfaŃa care defineşte metodele pe care clienŃii le pot apela
36

- ConcrcteMediator - clasa care implementează interfaŃa Mediator. Această
clasă reprezintă un mediator între mai multe clase de clienŃi. ConŃine informaŃiile
despre procese, precum şi referinŃe către clienŃii săi. Pe baza informaŃiilor pe care le
primeşte Mediator-ul, ea poate fie invoca metodele specifice, fie o metodă generică
pentru a informa clienŃii de modificările survenite, fie o combinaŃie a acestora
- Client - interfaŃa care defineşte metodele generale pe care un Mediator le
poate folosi pentru a crea instanŃe ale clienŃilor
- ConcreteClient - clasa care implementează interfaŃa Client şi toate metodele
client. Ha poate păstra o referinŃă către o instanŃă Mediator pentru a informa clienŃii
când apare o schimbare
• Beneficii şi inconveniente
Componentele individuale devin mai simple şi mai uşor de utilizat, deoarece
ele nu mai sunt nevoite sa trimită mesaje direct între ele. Strategiile de comunicarea
generală devin mai uşor de administrat, ele fiind acum responsabilitatea exclusivă a
mediator-ului. Clasele unei aplicaŃii pot fi folosite şi în cadrul aplicaŃiei, fiind
necesară doar rescrierea Mediator-ului pentru noua aplicaŃie.
Testarea unor implementări complexe ale unui Mediator poate fi destul de
dificilă, deoarece trebuie testată o componentă care constă din Mediator şi obiectele
asociate lui. Codul Mediator-ului poate deveni greu de administrat pe măsura ce
numărul şi complexitatea participanŃilor creşte. O posibilă soluŃie este de a transforma
mediatorul într-o structură compusă, bazată pe un număr de mediatori foarte
focalizaŃi. în acest caz. Mediator-ul e format dintr-un obiect central de administrare
asociat unui număr de clase individuale, fiecare punând la dispoziŃie o parte de
funcŃionalitate.
■ Variante ale şablonului
- UnidirecŃional Communication - unele implementări permit doar trimiterea
sau doar primirea de clienŃi în sistem
- Threading - ca multe alte şabloane comportamentale. Mediator-ul foloseşte
lucrul cu multiple fire de execuŃie
- Configurable Roles - în această variantă, clientul defineşte un rol, care se
poate modifica pe măsură ce sistemul rulează, rol ce defineşte cerinŃele trimiterii de
mesaje. Deja cu o implementare complexă, definirea participanŃilor ca roluri poate
conduce la un Mediator mai generic
- Client Puii - un Mediator poate stoca mesaje detaliate şi trimite doar o
notificare generală către clienŃi. ClienŃii pot cere apoi informaŃii detaliate despre un
eveniment dacă este cazul
• Şabloane asociate
Printre şabloanele asociate se află:
- Observer - acest şablon este de obicei folosit pentru a administra
comunicarea dintre Client şi Mediator, atunci când aceasta este locală
- Half-Object Plus Protocol - şablonul Mediator ce rulează de-a lungul unei
reŃele poate folosi şablonul Half-Object Plus Protocol care conŃine suport pentru
comunicare
37

Exemplu
Având o interfaŃă grafică complexă, de fiecare dată când se apasă pe un buton
o acŃiune este pornită sau oprită. Se poate descrie o clasă Mediator care să conŃină
toate clasele asociate:
class Mediator {
BtnView btnView;
BtnSearch btnSearch;
Btr.Book btnBook;
LbIDisplay show;;
void registerView (5tr.Vi.ew v) { btnView = v; }
void registerSearch(BtnSearch s) { btnSearch = s; }
void registerBook(BtnBook b) { btnBook = b; }
void registerDisplay(LbIDisplay d) { show = d; }
veid book() {
btnBooK.setEnabled(false);
btnView.setEnabled(true);
btnSearch.setEnabled(true);
show.setText("booking...");
btnView.setEnabled(false);
btnSearch.setEnabled (true) ;
btnBook.setEnabled(true);
void search() {
btnSearch.setEnabled ( false);
btnView.setEnabled(true);
btnBook.setEnabled(true);
show.setText("searching...");
III.6. Memento
• Cunoscut şi ca Token, Snapshot
• ProprietăŃi
• Scop
- Tip: comportamental
- Nivel: obiect
Să păstreze un instantaneu al stării unui obiect, astfel încât obiectul să poate
reveni la starea originală fără a-şi dezvălui conŃinutul restului lumii.
• Introducere
Fiecare aplicaŃie are obiecte ale căror informaŃii trebuie păstrate şi după
terminarea duratei de viaŃă a obiectelor. De regulă, acest lucru se face prin distribuirea
datelor, dar dacă informaŃiile private ale unei obiect trebuie păstrate? Trimiterea de
date către un alt obiect este o idee rea. încălcând principiul încapsulării. Dacă se trimit
date către alte obiecte, acestea pot citi sau, mai rău. pot modifica datele.
38

Este asemănător cu mersul la un parc naŃional unde se protejează elanul.
Obiectul ale cărui date sunt salvate este elanul. Xu este permisă luarea acasă a
elanului, dar vederi şi tricouri cu elanul sunt disponibile la magazinul de suveniruri al
parcului.
O mai bună abordare este folosirea unui obiect care să conŃină datele ce
trebuie salvate. Se trimite acest obiect care poate fi folosit pentru recrearea
originalului, în loc de a trimite datele neprelucrate. Alte obiecte nu ar putea citi sau
modifica datele deoarece acestea ar fi încapsulate. Acesta este şablonul Memento,
unde un obiect este folosit ca un suvenir cu ajutorul căruia se poate restabili starea
originală a obiectului iniŃial.
• Utilizare
Şablonul Memento se foloseşte când:
- este nevoie reŃinerea unui instantaneu al stării obiectului
- acest instantaneu e utilizat pentru recrearea stării originale a obiectului
- o interfaŃă directă către obiect încalcă încapsularea
• Descriere
Dacă încapsularea a fost implementată corect, atunci toate obiectele au stări
private şi vor permite acces la atribute doar prin metode. Dar poate fi necesară
trimiterea stării curente către un alt obiect, de exemplu, în vederea restaurării stării
iniŃiale într-un moment ulterior. O posibilitate de a face asta este de a trimite starea
direct către obiectul interesat. Apar însă inconveniente, cum ar fi expunerea structurii
interne a obiectului sau posibilitatea modificării stării obiectului de către un altul.
SoluŃia este învăluirea stării care se doreşte păstrată într-un alt obiect folosind
şablonul Memento. Memento este un obiect care conŃine starea internă curentă a
obiectului original de tip Originator. doar acesta din urma putând accesa şi retrage
informaŃii din Memento. Pentru restul lumii, Memento reprezintă doar un obiect
arbitrar.
■ Implementare
Diagrama de clase a şablonului Memento este următoarea:
Originator
-State state
+void setMemento(Memento m)
+Object getMemento()
1 creează
t
Memento
StateHolder
-State state Memento este o clasa statica
interna a Originator-ului
+State getState() +void
setState(State s)
39

Pentru implementarea şablonului Memento este nevoie de:
- Originator - creează Memento, lblosindu-1 ulterior pentru a-şi restaura starea
- Memento - clasa statică a Originator-ului şi păstrătorul stării acestuia.
Originator-ul determină câte date sunt păstrate de Memento. Starea reŃinută de
Memento trebuie să fie inaccesibilă tuturor, cu excepŃia Originator-ului
- StateHolder - obiectul care doreşte să păstreze starea. El nu trebuie să ştie ce
se afla în interiorul obiectului Memento: trebuie doar să ştie că obiectul pe care-1
primeşte îi permite să restaureze starea Originator-ului
Deoarece Memento trebuie să fie accesibil doar Originator-ului, este preferabil
ca Memento să fie o clasă publică din interiorul Originator-ului. Toate metodele sunt
declarate private astfel că sunt disponibile doar Memento-ului şi clasei care-1 conŃine.
InstanŃe ale unei clase interne sunt mereu asociate cu cele are clasei externe. Acest
lucru este necesar deoarece o clasă internă are întotdeauna acces la instanŃe ale
variabilelor clasei externe. Acest lucru cauzează însă o problemă în această situaŃie.
Memento ar trebui să fie independent de o instanŃă specifică a Originator-ului. Prin
urmare clasa Memento trebuie să fie statică.
■ Beneficii şi inconveniente
Folosirea şablonului Memento are următoarele consecinŃe:
- respectă principiul încapsulării - chiar şi când starea Originator-ului trebuie
să fie stocată în afara obiectului de tip Originator într-un client, starea este
inaccesibilă clientului. Are doar o referinŃă către obiectul Memento, neexistând nici o
cale de a accesa informaŃia din interior. Totodată face treaba clientul mai simplă
deoarece el nu mai trebuie să ştie totul despre lucrul intern al Originator-ului,
exceptând modul de obŃinere şi de utilizare a Memento-ului
- un Originator simplu - presupunând că Originator-ul trebuie să urmărească
toate stările, el va deveni curând plin şi greu de mânuit. Este mult mai uşor dacă se dă
această responsabilitate clientului. Originator-ul trebuie acum doar să fie capabil să
creeze şi să utilizeze Memento-ul
- Memento-uri costisitoare - Memento-urile sunt costisitor de creat daca
fiecare bucată a stării Originator-ului trebuie stocată în Memento. Daca Originator-ul
este mare. şablonul Memento nu este unul potrivit
- stocare costisitoare a Memento-ului - obiectul care păstrează starea este
responsabil cu administrarea ciclului de viaŃă după ce primeşte Memento-ul de la
Originator. Totuşi, el nu ştie cât de mare este Memento-ul de fapt. Daca el nu este
păstrat cât de mic posibil, obiectul StateHolder va avea de plătit preŃul
• Variante ale şablonului
Dacă Memento-ul trebuie să fie o clasă de sine stătătoare şi nu o clasă internă,
trebuie definite două interfeŃe - WideMemento şi NarrowMemento. InterfaŃa largă
este pentru Originator-ul Memento-ului astfel încât el să poată accesa Memento-ul
pentru a-si extrage starea. InterfaŃa restrânsă este pentru obiectele StateHolder şi
pentru alŃi clienŃi folosiŃi.
40

• Şabloane asociate
Printre şabloanele asociate se află:
- Command - poate folosi Memento-uri pentru a urmări stările în vederea
anulării unor acŃiuni
- State
• Exemplu
Şablonul Memento poate 11 folosit, de exemplu, pentru a reŃine un număr:
class Memento { ir.t num;
Memento(int c) {
num = c; } int
getNum() {
return num;
x
III.7. State
• Cunoscut şi ca Objects For States
• ProprietăŃi
• Scop
- Tip: comportamental
- Nivel: obiect
Să schimbe uşor comportamentul unui obiect la rulare.
• Introducere
De multe ori, o aplicaŃie se comportă diferit în funcŃie de valorile variabilelor
ei interne. De exemplu, când se lucrează cu un fişier text, acesta trebuie salvat din
când în când. Multe dintre editoarele de text curente permit salvarea documentului
doar când acesta s-a modificat. Imediat ce textul a fost salvat, el este considerat
"curat"; conŃinutul fişierului este identic cu cel afişat pe ecran.
Implementarea acestui lucru într-o metodă individuală face codul greu de
menŃinut şi de citit. Aceste metode vor conŃine structuri if/else. O tactică ar fi
reŃinerea stării unui obiect într-o singură variabilă folosind constante pentru o valoare,
caz în care metodele vor conŃine structuri switch/case care vor fi asemănătoare în
fiecare metodă.
Obiectele reprezintă stare şi comportament; starea este păstrată în atributele lor
iar comportamentul este definit în metode. Şablonul State permite schimbarea
dinamică a comportamentului unui obiect. Acest comportament dinamic este obŃinut
prin delegarea tuturor apelurilor de metode care se bazează pe anumite valori către un
41

obiect de tip State. Acest obiect este la rândul l u i comportamental, prin urmare
schimbarea unor obiecte State duce la obŃinerea unui comportament diferit. Metodele
specifice din clasele State nu mai trebuie sa folosească structuri if/else sau
switch/case; obiectul State defineşte comportamentul pentru o singură stare.
■ Utilizare
Şablonul State se foloseşte când:
- comportamentul obiectului depinde de starea sa. aceasta schimbându-se
frecvent
- metodele conŃin structuri condiŃionale mari care depind de starea obiectului
■ Descriere
Obiectele care au un comportament diferit în funcŃie de starea lor curentă pot
fi greu de implementat fără şablonul State. Implementarea fără acest şablon presupune
folosirea de constante pentru urmărirea stării curentă şi implementarea unor structuri
switch lungi. Majoritatea acestor metode aflate în aceeaşi clasă au o structură similară.
Considerând o uşa, care sunt operaŃiile normale care se pot face cu o simplă
uşă? Aceasta poate fi deschisă şi închisă, deci ea se poate afla în una din cele două
stări - închis sau deschis. Apelarea metodei de închidere a unei uşi închise nu duce la
nimic, dar apelarea acesteia pentru o uşa deschisă conduce la schimbarea stării uşii.
• Implementare
Diagrama de clase a şablonului State este următoarea:
Context
-State currentState
+void setCurrentState(State s)
i k
i
k T
1 1 1 1
__ L
_
interface State
+void someMethod()
------------- * ----------------
ConcreteStateA ConcreteStateB
+void someMethod()
Implementarea şablonului State necesită:
+void someMethodQ
- Context - menŃine o referinŃă către starea curentă, fiind interfaŃa utilizată de
clienŃi
- State - defineşte metodele care depind de starea obiectului
- ConcreteState - clasa care implementează interfaŃa State şi comportamentul
specific unei stări
42

Context sau ConcreteState pot determina tranziŃiile între stări. Când numărul
stărilor este fixat, cel mai apropiat loc în care se poate reŃine logica tranziŃiei este
Context, lotuşi, se obŃine o flexibilitate mai mare dacă aceasta se plasează în
subclasele clasei State. în acest caz. fiecare obiect State determină tranziŃia - care este
următoarea stare. în ce circumstanŃe şi când are loc tranziŃia. Acest lucru face mai
uşoară schimbarea unei părŃi a obiectului State şi adăugarea unuia nou. Inconvenientul
este că fiecare clasă care implementează clasa State depinde de alte clase. Dacă
implementarea clasei State determină tranziŃia, interfaŃa Context trebuie să conŃină o
calc pentru introducerea noii stări în context.
• Beneficii şi inconveniente
Printre beneficiile şi inconvenientele şablonului State se numără:
- partiŃionarea comportamentului în funcŃie de stări - acest lucru oferă o
vederea mai bună a comportamentului. Când un obiect se află într-o stare specifică,
privind subclasele corespunzătoare clasei State se observă că toate comportamentele
posibile ale acelei stări sunt incluse acolo
- oferă structură, având o intenŃie clară - o variantă des folosită a şablonului
State este utilizarea constantelor şi a unei structuri switch pentru a determina acŃiunile
următoare. Aceasta este o soluŃie slabă deoarece creează duplicate. Multe metode
folosesc aproape în acelaşi fel structura switch. Dacă se doreşte adăugarea unei noi
stări, trebuie modificate toate metodele clasei Context prin adăugarea unui nou
element fiecărei structuri switch. Prin contrast, aceeaşi schimbare în sistem, folosind
şablonul State, este realizată simplu prin crearea unei noi implementări a stării
- tranziŃiile sunt explicite - când se folosesc constante pentru stări, este uşor să
se confunde o schimbare de stare cu o atribuire a unei variabile deoarece sintactic
arată la fel. Utilizând şablonul State, stările sunt compartimentate în obiecte, făcând
mult mai uşoară recunoaşterea unei schimbări de stări
- stările pot fi distribuite - dacă subclasele clasei State conŃin doar
comportamente şi nu instanŃe ale variabilelor, ele devin practic şabloane Flyweights.
Orice stare de care au nevoie poate să le fie trimisă prin intermediul interfeŃei
Context. Se reduce astfel numărul obiectelor din sistem
- şablonul State foloseşte un număr mare de clase - acest lucru poate fi
considerat un dezavantaj. Şablonul State creează cel puŃin o clasă pentru fiecare stare
posibilă. Insă este de preferat acest lucru, alternativa fiind lungi structuri switch
• Variante ale şablonului
Unul din lucrurile importante în ceea ce priveşte şablonul State este
determinarea cui guvernează tranziŃiile dintre stări. O altă opŃiune, în afara subclaselor
lui State şi Context, ar 11 privirea tranziŃiilor într-o structură de tabel, cu un tabel
pentru fiecare stare. Se transformă astfel codul de tranziŃie într-o operaŃie de privire a
unui tabel. Pentru a schimba criteriul de tranziŃie, doar datele din tabel trebuie
schimbate în loc de a modifica codul. Dezavantajele sunt însă numeroase: tabelele
sunt de multe ori mai ineficiente decât apelul unei metode; introducerea logicii unei
tranziŃii într-un tabel o face mult mai greu de înŃeles. Principala diferenŃă este că
şablonul State se concentrează pe modelarea comportamentului în funcŃie de stări, pe
când folosirea tabelelor se bazează pe tranziŃiile dintre diferite stări. O alăturare a
acestor doua abordări combină dinamică modelului cu tabele cu şablonul State.
43

TranziŃiile se stochează într-un obiect HashMap. dar în loc de a avea un tabel pentru
fiecare stare, se creează un obiect HashMap pentru fiecare metodă din clasa State.
• Şabloane asociate
Printre şabloanele asociate se află:
- Flyweight - stările pot fi disponibile folosind acest şablon
- Singleton - multe şabloane State sunt şabloane Singleton. în special atunci
când sunt şi şabloane Flyweights
• Exemplu
Presupunem că utilizatorii se conectează la o bază de date pentru a efectua
anumite acŃiuni. Se folosesc astfel două subclase Management şi Sales. pentru a se
exemplifica şablonul State:
abstract class Connection {
public abstract void open(); public
abstract void close ( ) ; public abstract;
void log Ń ) ; }
class Sales extends Connection {
public void open() {
Systerr.. out. println ( "deseh: dere bază de date pentru
vânzări"); }
public void close() {
System.out.println("închidere bază de date"); }
public void log() {
System.out.println("iocare activităŃi";;
class Management extends Connection {
public void open Ń) {
System, out. println ( "deschidere bază de date pentru
management");
\
public void closet) {
System.out.println("închidere oază de date"); Ń
public veid log() {
System.out.println("logare activităŃi");
class Controller public sta public
static Management manage; private
static Connection current;
Controller() {
sales =• new Sales (); manage =
new Management(); }
public void makeSalesConnecticn() { current - sales; }
public void makeManagementConnection() { current -
manaae; }
44

public voia open ; ; { :.::: --•:/.. : :: n ; •
public void close{} { :.::,:_:.:::;;.•; ;
public void log ( ) { curr^r.~..l: ~ . ; }
lass Test {
Stririg con;
Controller controller;
Test (String con) {
controller = new Controller!);
ii Ń con . equalsIgnoreCa.se ; "management " ) )
controller . makeManagementConr.ection î )
i f { con.equaÎs IgnoreCase("sales") )
controller.makeSalesConnection();
controller.open(); controller.log();
ccntroller.closeO ;
lass Server {
public static Test test;
public static void main(String[] args) {
new Test(args[O]);
III.8. Strategy
• Cunoscut şi ca Policy
■ ProprietăŃi
• Scop
- Tip: comportamental
- Nivel: componentă
Să definească un grup de clase care să reprezinte un set de comportamente
posibile. Aceste comportamente pot fi apoi introduse uşor în aplicaŃie, schimbând
după caz funcŃionalitatea.
• Introducere
Se presupune că managerul personal de informaŃii conŃine o listă de contacte.
Pe măsură ce numărul acestora creşte, se doreşte existenŃa unei modalităŃi de sortare a
intrărilor şi de vizualizare a informaŃiilor despre un anumit contact. Pentru a face acest
lucru, se poate crea o clasă care să înregistreze contactele în memorie, să le sorteze şi
să afişeze informaŃiile despre ele. Această cale duce la apariŃia unor probleme în timp,
cea mai serioasă fiind aceea că soluŃia nu poate fi modificată şi extinsă uşor.
45

De fiecare dată când se vrea introducerea unei noi variante de sortare şi de
afişare a informaŃiilor, trebuie modificată clasa care execută aceste operaŃii. Mai mult.
o dată cu creşterea numărul de opŃiuni de sortare şi afişare, mărimea şi complexitatea
codului se măreşte, făcându-1 mai greu de testat şi menŃinut.
Dacă în schimb se dezvoltă o serie de clase, fiecare conŃinând o modalitate
specifică de sortare şi afişare a contactelor? Clasa principală predă sarcina respectivă
uneia dintre aceste clase, eliminându-se astfel codul complex al celeilalte soluŃii.
Şablonul Strategv se bazează pe obiecte care au o stare şi un comportament,
înlocuind un obiect cu un altul, are loc o schimbare a comportamentului, şi cu toate că
astfel apar mai multe clase, fiecare dintre acestea este uşor de menŃinut iar soluŃia
generală este foarte extensibilă.
• Utilizare
Şablonul Strategv se foloseşte când:
- există mai multe căi de a efectua o acŃiune
- nu se ştie cu exactitate ce cale să se folosească decât în momentul rulării
- se doreşte adăugarea uşoară a altor modalităŃi de efectuare a unei acŃiuni
- se vrea un cod uşor de întreŃinut pe măsură ce se adaugă noi comportamente
• Descriere
De multe ori există mai multe căi de a efectua aceeaşi acŃiune. Sortarea, de
exemplu, poate fi tăcută cu ajutorul unor algoritmi cum ar fi quick-sort şi sortarea prin
metoda bulelor, prin utilizarea câmpurilor multiple sau conform anumitor criterii.
Când un obiect îşi poate atinge scopul prin mai multe căi, el devine complex şi
greu de administrat. Pentru salvarea unui document în diferite formate, trebuie scris
un cod care să producă o clasă capabilă să reprezinte documentul respectiv şi să-1
salveze conform cerinŃelor. O dată cu creşterea numărului formatelor şi a
complexităŃii lor, administrarea codului într-o singură clasă devine greoaie.
în astfel de cazuri se poate şablonul Strategv pentru menŃinerea unui echilibru
între flexibilitate şi complexitate. Acest şablon separă comportamentele unui obiect,
reprezentându-le în câte o clasă separată. Obiectul foloseşte apoi comportamentul care
satisface cerinŃele de la un moment dat. De exemplu, pentru un document se poate
dezvolta câte o clasă care să-1 salveze în fiecare format, comportamentul acestor clase
fiind definit într-o supraclasă sau o interfaŃă.
Şablonul Strategy administrează seturi de algoritmi de bază. cum ar fi căutarea
şi sortarea. Poate fi folosit şi pentru interogarea bazelor de date. definirea diferitelor
modalităŃi de interogare sau organizarea rezultatelor. în spaŃiul afacerilor, el este
câteodată utilizat pentru a reprezenta diferite posibilităŃi de efectuare a tranzacŃiilor.
Comanda unei staŃii de lucru, de exemplu, poate fi implementată cu ajutorul
şablonului Strategy dacă se doreşte achiziŃionarea uneia diferită de modelul standard.
46

• Implementare
Diagrama de clase a şablonului Strateg} este următoarea:
Strateg} Client
-Strategv strategv
+void setStrategy(Strategy s)
+void performOperationQ
strategv. operationQ
ConcreteStrategyB
+void operationQ
interface Strateg}'
-void operalion()
Pentru implementarea şablonului Stratcgy este nevoie de:
ConcreteStrategyA
+void operation()
- StrategyClient - clasa care foloseşte diferite strategii pentru anumite sarcini.
Ea păstrează o referinŃă către instanŃa Strategy pe care o foloseşte şi conŃine o metodă
care înlocuieşte instanŃa Strategy curentă cu o altă implementare
- Strategy - interfaŃa ce defineşte toate metode ce pot fi folosite de clasa
StrategyClient
- ConcreteStrategy - clasa care implementează interfaŃa Strategy. utilizând un
set specific de reguli pentru fiecare metodă a interfeŃei
• Beneficii şi inconveniente
Fiecare comportament este definit în propria-i clasă, astfel că şablonul
Strategy conduce la un control mult mai uşor al comportamentelor. Totodată,
extinderea unui model care să includă noi comportamente este mai facilă.
Principala provocare în ceea ce priveşte acest şablon, este stabilirea modului
exact de reprezentare a unui comportament. Fiecare Strategy trebuie să aibă aceeaşi
interfaŃă pentru obiectul apelat. Trebuie identificat unul generic, care să poată fi
aplicat mai multor implementări, dar care în acelaşi timp să fie specific pentru
diferitele strategii concrete folosite.
■ Şabloane asociate
Printre şabloanele asociate se află:
- Singleton - de multe ori implementările şablonului Strategy sunt reprezentate
ca şabloane Singleton
47

- Flyweight - câteodată obiectele de tip Strategy sunt proiectate ca obiecte de
tip Flyweights pentru a le face mai puŃin costisitoare de creat
- Factory Method - şablonul Strateg) poate fi definit ca un şablon Factory
Method astfel încât clasa principală să utilizeze noi implementări ale şablonului iară a
recoda alte părŃi ale aplicaŃiei
Exemplu
Un exemplu simplu al şablonului Strateg}- este prezentat. Se aruncă un zar şi în
funcŃie de rezultat se afişează un mesaj:
interface Fortur.eCookies { public void prinŃ (); }
class Six implementa FortuneCookies { public void
prinŃ() {
System.out.prinŃIn("Perfect!");
class Five irrpl emerit s FortuneCookies {
public void prinŃ() {
Systera. out. println ( "Destul de bine!");
class t-our iniplements FortuneCookies {
public void prinŃ() {
System.out.crintln("Bine!");
lass Three implements FortuneCookies {
public void prinŃ() {
System.cut.printin("Se poate şi mai bine!")
class Two implements FortuneCookies {
public void prinŃ () {
lass One implements FortuneCookies {
public void prinŃ() {
System.out.println("Slab!")
lass Nuli impl emerit s FortuneCookies {
public void prinŃ {) {
Syst em. ou c . pr int ^n ( "N — mic ! "
cl ass D ice {
p u b l i c i n t t h r o w l t ( ) {
r e t u r n ( i nt ) ( Ma t h . r an d o m ( )" 6 ) +1 ;
class lest {
static void goodFortune() {
irit luckyNum = new Di ce ( ) . throwlt ( ) ;
FortuneCookies fc; s w i t c h (Iu c k y M u rr.) {
case 1: fc = new On e( ) ; b re a k;
case 2: Le = new Tw o( ) ; b re a k;
48

f c . p r i n t ( ) ; }
public static vcid iru
gocdFortune();
III.9. Visitor •
ProprietăŃi
• Scop
- Tip: comportamental
- Nivel: componentă
Ci^se ' : : i : -- :. . ■ ; _ : . : -^ - ; creak;
case ; : : : : : = : ^ : _.._ ; ivreak;
default: zz -- r ev :: J 1I . ; ;
Să pună la dispoziŃie o cale uşoară de a efectua acŃiuni pentru o familie de
clase. El centralizează comportamentele şi permite ca ele să fie modificate sau extinse
tară a modifica clasele care le folosesc.
• Introducere
Se doreşte ca managerul personal de informaŃii să conŃină capacităŃi de
planificare, iar planificatorul să fie folosit pentru lucruri ca licitaŃiile, analizele de risc
şi estimarea timpului. Următoarele reprezintă un proiect complex:
- Project - rădăcina ierarhiei proiectului, reprezentând proiectul în sine
- Task - o sarcină în cadrul proiectului
- DependentTask - o sarcină care depinde de alta
- Deliverable - un articol sau document ce reprezintă rezultatul proiectului
Pentru identificarea clară a acestor clase ca părŃi ale unui model, ele sunt
organizate în jurul unei interfeŃe numite Projectitem. Până aici totul este în regulă.
Dar cum se poate coda abilitatea de a estima costul total al proiectului? Acest calcul
va depinde probabil de tipul specific al interfeŃei Projectitem. în această interfaŃă se
defineşte o metoda getCost care trebuie să calculeze costul pentru o parte specifică a
proiectului. Acest lucru pennite calcului costului pentru fiecare articol din structura
proiectului. Se poate decide asupra unei modalităŃi de genul:
- Project - tară operaŃii, de vreme ce costul este egal cu costul tuturor
articolelor proiectului
- SimpleTask - costul este calculat pe baza orelor în care s-a lucrat
- DependentTask - la fel ca sarcina simplă, dar adăugându-se un factor
adiŃional care reprezintă dependenŃa unei sarcini de alta
- Deliverable - costul este o estimare de bază a materialelor plus costul de
producŃie
49

Totuşi, cum se poate calcula timpul necesar pentru rezolvarea proiectului,
precum şi riscul? Folosind aceeaşi metodă ca şi în cazul celorlalte costuri face codul
greu de întreŃinut. Trebuie scrise o grămadă de noi metode care vor fi împrăştiate prin
toate clasele proiectului. Cu fiecare nouă operaŃie, clasa devine din ce în ce mai largă,
mai complexă şi mai greu de înŃeles. De asemenea este dificil de a Ńine evidenŃa
informaŃiilor. Dacă se doreşte estimarea costului, a timpului sau a riscului folosind
astfel de metode, trebuie găsită o modalitate de păstrare a rezultatelor intermediare, de
vreme ce fiecare metodă aparŃine unui obiect specific al proiectului. Se ajunge astfel
la trimiterea informaŃiilor prin întreaga structură a proiectului.
Şablonul Visitor oferă o alternativă. Se defineşte o singură clasă denumită
CostProjectVisitor, care efectuează toate calculele legate de cost. în loc de a efectua
aceste calcule în cadrul fiecărui articol al proiectului, acestea se fac de către clasa
Visitor, care reŃine şi costul total. InterfaŃa Projectltem nu va mai conŃine metoda
getCost. în schimb, va avea o metodă acceptVisitor mult mai generică, care foloseşte
un obiect de tip ProjectVisitor pentru a apela o metodă specifică din clasa
ProjectVisitor. De exemplu, metoda acceptVisitor pentru o anumită sarcină apelează
metoda visitTask a interfeŃei Visitor. Dacă aceasta este de tipul CostProjectVisitor,
atunci metoda visitTask calculează costul asociat sarcinii respective.
Acest model oferă beneficii substanŃiale, cel mai important fiind acela că se
pot adăuga uşor noi operaŃii. Pentru calculul timpului trebuie doar scrisă o clasă
TimeProjectVisitor care să conŃină toate metodele necesare pentru a calcula timpul în
care s-a lucrat la proiect. Codul pentru obiectele proiectului rămâne neschimbat,
deoarece el conŃine deja apeluri către metodele generice definite în clasa
ProjectVisitor.
Mai mult. şablonul Visitor conŃine un loc pentru centralizarea situaŃiei. Pentru
clasa CostProjectVisitor se pot stoca rezultatele intermediare chiar în Visitor, în timp
ce se efectuează calculele costului. Codul pentru centralizarea estimării face uşoară
ajustarea calculelor de bază. Prin folosirea şablonul Visitor, se pot adaugă uşor
caracteristici cum ar fi factori adiŃionali, putându-se calcula de exemplu discount-ul.
• Utilizare
Şablonul Visitor se foloseşte atunci când sunt îndeplinite următoarele condiŃii:
- un sistem conŃine un grup de clase asociate
- câteva operaŃii netriviale trebuie efectuate de unele sau de toate clasele
asociate
- operaŃiile trebuie efectuate diferit pentru clasele variate
• Descriere
Şablonul Visitor implică preluarea unor operaŃii asociate dintr-un grup de clase
şi plasarea lor împreună într-o singură clasă. Motivul este întreŃinerea codului - în
unele situaŃii devine prea complicat de întreŃinut operaŃiile în cadrul fiecărei clase.
Şablonul Visitor este folositor în aceste cazuri, deoarece conŃine un suport generic
pentru susŃinerea operaŃiilor unui grup de clase.
El necesită ca toate clasele ce conŃin operaŃii sau Elemente, să aibă şi o metodă
de acceptare care să fie apelată atunci când Visitor-ul efectuează o operaŃie asupra
unui Element. Argumentul acestei metode de acceptare este o instanŃă a Visitor-ului.
50

Fiecare implementare a unui Element conŃine metoda de acceptare care
apelează metoda de vizitare din cadrul Yisitor-ului. Fiecare Visitor implementează o
metodă de vizitare specifică subtipului Element-ului.
• Implementare
Diagrama de clase a şablonului Visitor este următoarea:
interface Visitor
+void visit(ConcreteElementA cmElementA)
+void visitfConcreteElc'mcntB anElementB)
ConcreteVisitorA Concrete VisitorB
+void visit(ConcreteElementA anElementA)
+void visit(ConcreteElementB anElementB)
interface Element
+void accept (Visitor visitor)
+void visit(ConcreteElementA anElementA)
+void visit(ConcreteElementB anElementB)
ConcreteElementA ConcreteElementB
+void accept(Visitor visitor) +void accept(Visitor visitor)
visitor. visit(this) visitor.visit(this)
Pentru implementarea şablonului Visitor se folosesc următoarele:
- Visitor - clasa abstractă sau interfaŃa care defineşte o metodă de vizitare
pentru fiecare clasă ConcreteElement
- ConcreteVisitor - clasa ce reprezintă o operaŃie specifică ce trebuie efectuată
în cadrul sistemului. Implementează toate metodele definite în Visitor pentru o
operaŃie specifică sau un algoritm
- Element - clasa abstractă sau interfaŃa asupra căruia Visitor-ul operează.
Minim, ea defineşte o metodă de acceptare care primeşte un Visitor ca argument
- ConcreteElement - entitate specifică a sistemului. Implementează metoda de
acceptare definită în Element, apelând metoda de vizitare corespunzătoare definită în
Visitor
Un lucru care trebuie urmărit cu atenŃie atunci când se implementează şablonul
Visitor este supraîncărcarea metodelor. Şablonul foloseşte supraîncărcarea metodelor
pentru metoda de vizitare. InterfaŃa Visitor poate avea două metode de vizitare,
fiecare primind un alt argument.
51

■ Beneficii şi inconveniente
Datorita structurii sale. şablonul Visitor tace uşoară adăugarea de noi
comportamente sistemului. Când se implementează iniŃial şablonul, se dezvoltă un
cadru de suport pentru fiecare altă acŃiune a Visitor-ului ce se poate efectua în viitor.
Pentru a adaugă o nouă funcŃionalitate, se creează o nouă clasă care implementează
interfaŃa Visitor şi se scrie noul cod.
Şablonul Visitor este folositor deoarece permite centralizarea codului pentru o
operaŃie, acest lucru tăcând mai facilă întreŃinerea acestuia. Acelaşi obiect de Ńip
Visitor este utilizat în mod normal pentru vizitarea fiecărui Element din structură, prin
urmare el pune la dispoziŃie o locaŃie centrală pentru reŃinerea datelor colectate sau
pentru stocarea rezultatelor intermediare.
Partea rea a acestui şablon este aceea că flexibilitatea este scăzută în lanŃul
claselor Element. Orice adăugare sau modificare a ierarhiei acestor clase are o mare
şansă de a produce o rescrie a codului structurii Visitor. Orice clasă adiŃională
necesită că o nouă metodă să fie definită în interfaŃa Visitor şi fiecare ConcreŃeVisitor
trebuie să conŃină o implementare a acestei metode. Mai mult, şablonul poate încalcă
principiul încapsulării. Şablonul Visitor preia codul care se aplică unui obiect în afara
clasei obiectului şi îl mută într-o nouă locaŃie.
• Variante ale şablonului
Ca multe alte şabloane, Element-ul şi Visitor-ul se poŃ reprezenta în Java ca
interfeŃe sau clase abstracte. O altă decizie ce trebuie luată este cum să fie aplicat
Visitor-ul unei colecŃii de Elemente. Şablonul Visitor nu are nici o descriere privind
structura de Elemente asupra căreia operează. Se poate folosi un ConcreŃeVisitor la
fel de eficient pentru parcurgerea unei colecŃii simple, unei liste sau unui arbore.
Deşi unele implementări ale Visitor-ului conŃin codul de parcurgere în
interiorul ConcreteVisitor-ului, şablonul nu necesită acest lucru. Se poate folosi o
clasă externă, de exemplu un Iterator. pentru mişcarea într-o colecŃie. Se poŃ apoi uni
aceste două şabloane, Visitor şi Iterator, în funcŃie de cerinŃe.
• Şabloane asociate
Printre şabloanele asociate se află:
- Interpreter - se poate folosi şablonul Interpretei' pentru centralizarea
interpretărilor operaŃiilor
- IŃerator - se poate folosi şablonul Iterator pentru parcurgerea unei colecŃii
generice
- Composite - se poate combina şablonul Composite cu Visitor în vederea
parcurgerii unei structuri arborescente
de a
1
Exemplu • Exemplu
Următorul exemplu foloseşte şablonul Visitor pentru a
reprezenta modalităŃi comanda pizza de la diferite restaurante:
interface Visitor { public void visit (Pizza p)
interface Pizza { public Suring order(); }
52

class ropjohn implementa -i z z; ; ■
final String name - "Z :L "'::.:.'
public String order;; ■. L r i
\
class FizzaHut impiements Fizza •.
fina; String name --= "Fizz-Fu~
pubizc String craer() { zoru:
class GodFather impiements Fizza •;
final String name = "GodFather"; public
String order () { return nanie; }
class ByPickup impiements Visitcr {
private String name;
private fina] String methcd = "Ry pick uc"; public
void visit(Fizza p) { name = p.order(); } public
String toString() { return nair.e - " " + methoc
class ByDeiivery impiements Visitcr {
private String name;
private final String method = "Ey delivery"; public
void visit(Fizza p) { name = p.order(); } public
String roStringf) { return name + " " + methoc
class Dinner {
public Pizza getDinner() {
switch ((int)(Math.random(;*3)){
case 0: return new PopJohn(); break; case 1:
return new PizzaHut () ; break; case 2:
return new GodFather(); break; default:
return nuli; }
public Visitor howto() {
switch ( (int) (Math.random()*2) ) {
case 0: return new ByPickup(); break;
case 1: return new ByDeiivery(); break;
default: return nuli;
class Test {
public static void main(String[] args) { List
pizzaList = new ArrayList(); pizzaList.add(new
PopJohn () ) ; pizzaList.add(new PizzaHut () ) ; pi
z.zaList . add (new 7 GodFather () ) ; Iteratcr it =
pizzaList.iterator(); while (it.hasNext()) {
System.out.prinŃIn(((Fizza)it.next()).order());
Dinner d i; new Dinner () ;
Fizza pza = d.getDinner();
Visitor v = d.howtoŃ);
v.visit(pza);
System.out.prinŃin(v);
53

111.10. Template Method
• ProprietăŃi
• Scop
- Tip: comportamental
- Nivel: obiect
Să pună la dispoziŃie o metodă care să permită subclaselor să suprascrie părŃi
dintr-o metodă Iară a o rescrie.
■ Introducere
Când se lucrează cu proiecte, se doreşte frecvent estimarea costului pentru
efectuarea unei anumite sarcini sau pentru producerea rezultatului. Managerul
personal de informaŃii foloseşte un număr de clase pentru a reprezenta proiectele.
Minim, clasele Task şi Deliverable sunt utilizate pentru reprezentarea elementelor
proiectului. Pe măsură ce un proiect devine mai complex, trebuie create clase
adiŃionale cum ar fi Project sau DependentTask pentru a satisface nevoile mai
sofisticate. Cu toate că se poate crea o metoda getCostEstimate pentru fiecare clasă în
parte, o astfel de modalitate implică mult cod duplicat. Numărul claselor crescând,
devine din ce în ce mai dificil de întreŃinut codul din toate clasele proiectului.
O abordare mai bună este gruparea tuturor claselor asociate proiectului sub o
supraclasă şi definirea metodei getCostEstimate acolo. Dar ce se poate face atunci
când părŃi din metoda getCostEstimate depind de informaŃii specifice fiecărei clase a
proiectului? Daca obiectul de tip Task are o cale diferită de calculare o orelor faŃă de
obiectul de tip Deliverable?
în acest caz, metoda getCostEstimate trebuie definită astfel încât să apeleze o
metodă abstractă getTimeRequired şi să permită claselor Task şi Deliverable să
definească metoda cât mai convenabil. Această modalitate, numită Template Method.
aduce beneficii în ceea ce priveşte reutilizarea codului, permiŃând în acelaşi timp
claselor să modifice anumite părŃi ale comportamentului în funcŃie de necesitaŃi.
• Utilizare
Şablonul Template Method se foloseşte pentru:
- a pune la dispoziŃie o structură schelet pentru o metodă, permiŃând
subclaselor să redefinească părŃi specifice din metodă
- a centraliza părŃi ale unei metode care sunt definite în toate subtipurile unei
clase, dar care vor avea întotdeauna o mică diferenŃă în fiecare clasă
- a controla ce operaŃii subclasele au voie a suprascrie
• Descriere
Când se construieşte o ierarhie complexă de clase pentru aplicaŃie, codul este
de multe ori duplicat în anumite locuri. Acest lucru nu este de dorit, de vreme ce se
doreşte reutilizarea codului oricât de mult. Refacerea codului astfel încât metodele să
se alia în supraclasă este un pas în direcŃia bună.
54

Problema este că o operaŃie care a fost refăcută se bazează pe informaŃia
specifică care este valabilă doar în subclasă. Din această cauză, deseori se acceptă
codul duplicat în clase multiple.
Când multe metode din clase asociate au o structură similară, şablonul
Template Method este de folos. Mai întâi, se determină care părŃi ale metodelor sunt
similare. Aceste părŃi trebuie centralizate în supraclasă. în timp ce celelalte operaŃii
rămân în subclase. Metoda Template nou definită conŃine structura operaŃiei. Pentru
fiecare parte a operaŃiei care variază, o metodă abstractă este definită în supraclasă.
Subclasele suprascriu aceste metode punând la dispoziŃie propria lor implementare.
Când este apelată metoda template în subclasă, codul din supraclasă este executat.
Când metoda template din supraclasă este declarată final, subclasele sunt limitate în
ceea ce priveşte părŃile supraclasei pe care le pot suprascrie.
Acest şablon este denumit Template Method deoarece pune la dispoziŃie o
metodă ce conŃine structura operaŃiei, dar lasă unele uşi deschise prin apelarea de
metode abstracte. Este exact ca un template. deoarece subclasele umplu spaŃiile goale
conŃinând implementări pentru metodele abstracte.
• Implementare
Diagrama de clase a şablonului Template Method este următoarea:
AbstractClass
+void templateMethod()
+void subOperation 1 ()
+void sub()peration2()
i
ConcreteClass
+void subOperationl()
+void subOperation2()
//'cod schelet
subOperation 1() "mai
mult cod schelet
subOperation2() //si
mai mult cod
Pentru implementarea şablonului Template Method este nevoie de:
- AbstractClass - clasa abstractă ce conŃine metoda template şi defineşte una
sau mai multe metode abstracte. Metoda template conŃine codul schelet şi apelează
una sau mai multe metode abstracte. Pentru a preveni subclasele să suprascrie metoda
template. aceasta trebuie declarată final
- ConcreteClass - extinde clasa AbstractClass şi implementează metodele
abstracte ale acesteia. Se bazează pe clasa AbstractClass pentru a pune la dispoziŃie
structura operaŃiei conŃinută în metoda template

• Beneficii şi inconveniente
Principalul beneficiu al şablonului Template Method este acela că permite
reutilizarea codului. Fără acest şablon, codul este duplicat în mai multe subclase.
Acest beneficiu face şablonul Template Method esenŃial pentru cadre. Un cadru
conŃine mai multe metode care doar minimal se bazează pe implementările specifice
din subclasa. Folosind acest şablon înseamnă că întreaga structură poate fi pusă la
dispoziŃie de cadru.
Dacă metoda template apelează prea multe metode abstracte, după ceva timp
folosirea clasei AbstractClass că o supraclasă devine plictisitoare. Este mai bine ca
metoda template să apeleze un număr limitat de metode abstracte.
• Variante ale şablonului
O variantă este ca şablonul Template Method să apeleze metode concrete în
loc de metode abstracte. Clasa AbstractClass conŃine o implementare de bază pentru
fiecare din metodele apelate de Template Method. Aceste metode sunt denumite
metode cârlig.
RaŃiunea este că atunci când se foloseşte clasa AbstractClass, nu mai trebuie
suprascrise metodele pentru a putea folosi şablonul Template Method. AbstractClass
nici nu trebuie sa fie abstractă.
O responsabilitate a celui care implementează şablonul Template Method este
să se documenteze în privinŃa metodelor care sunt folosite în alte metode template. în
şablonul Template Method normal, este clar ce metode trebuie suprascrise, deoarece
toate aceste metode sunt abstracte. Dacă metodele cârlig nu sunt menŃionate în
documentaŃie, ele nu pot fi identificate.
• Şabloane asociate
Printre şabloanele asociate se află:
- Factory Method - metodele template apelează deseori metode factory pentru
a crea instanŃe iară a cunoaşte clasele exacte ce se creează
- Strategy - acest şablon foloseşte compunerea pentru a înlocui complet
comportamentul, în timp ce şablonul Template Method foloseşte moştenirea pentru a
înlocui părŃi ale comportamentului
- Intercepting Filter - foloseşte şablonul Template Method pentru a
implementa strategia Template Filter
Exemplu
Atunci când se face un împrumut, trebuie să se parcurgă o serie de paşi.
Şablonul Template Method se foloseşte pentru a menŃine împreună aceşti paşi. tară a
considera implementarea reală a subclaselor:
abstract class CheckBackgrcund {
public abstract; void checkBankŃ) ;
public abstract voia checkCredit();
public abstract void checkLoan{);
public abstract void checkStock();
public abstract void checklr.come Ń ) ;
56

public voia chec'-:..;
checkEar:.

IV. Şabloane structurale
Şabloanele structurale descriu căi efective atât de partiŃionare cât şi de
combinare a elementelor unei aplicaŃii. Modul în care aceste şabloane influenŃează
aplicaŃiile variază. De exemplu, şablonul Adapter poate realiza comunicarea între
doua sisteme incompatibile. în vreme ce Facade permite crearea unei interfeŃe simple
cu utilizatorul fără a elimina toate opŃiunile valabile din sistem.
IV. 1. Adapter
• Cunoscut şi ca Wrapper
• ProprietăŃi
■ Scop
- Tip: structural
- Nivel: componentă
Să acŃioneze ca un intermediar între dou clase, convertind interfaŃa unei clase
astfel încât să poată fi folosită şi de cealaltă.
• Introducere
Unul dintre marile avantaje ale programării orientate pe obiecte este acela că
permite reutilizarea codului. De vreme ce datele şi comportamentul sunt centralizate
într-o clasă, se poate - cel puŃin în principiu - muta clasa dintr-un proiect într-altul şi
reutiliza funcŃionalitatea tară prea mare efort. Din păcate, necunoscându-se cerinŃele
codului pentru viitoarele proiecte, nu se ştie mereu cum să se schiŃeze clasa pentru o
reutilizare optimă.
De exemplu, pentru a grăbi dezvoltarea managerului personal de informaŃii, se
decide cooperarea cu o altă persoană dintr-o altă Ńară. Această persoană lucrează la o
aplicaŃie similară şi poate pune la dispoziŃie o implementare a unor componente ale
aplicaŃiei. Dar atunci când se primesc fişierele, interfeŃele nu se potrivesc. Mai mult,
codul este în altă limbă. Apar două soluŃii, amândouă neatrăgătoare.
Prima opŃiune este aceea de a rescrie noua componentă astfel încât să poată
implementa toate cerinŃele interfeŃei. Rescrierea noii componente este o idee rea
deoarece trebuie făcut acest lucru de fiecare dată când se primeşte o versiune înnoită a
componentei respective.
A doua opŃiune ar fi rescrierea aplicaŃiei folosind interfaŃa primită.
Inconvenientul este că trebuie trecut prin tot codul pentru a modifica fiecare apariŃie a
vechii interfeŃe, codul devenind astfel greu de înŃeles deoarece nu se cunoaşte limba în
care este scrisă componenta primită.
Este nevoie aici de un translator. Aici intervine şablonul Adapter. El se
comportă similar unui adaptor de curent, convertind un tip în altul, altminteri
incompatibile. Folosind acest şablon, aplicaŃia poate folosi interfaŃa proprie,
permiŃând în acelaşi timp şi utilizarea noii componente. Când soseşte o versiune
înnoită, singurul lucru ce trebuie modificat este Adapter-ul.
58

:
■ Utilizare
Şablonul Adapter se foloseşte când:
- se doreşte utilizarea unui obiect într-un mediu care aşteaptă o interfaŃă care
este diferită de cea a obiectului
- trebuie să existe o traducere a interfeŃelor între mai multe surse
- un obiect trebuie să acŃioneze ca intermediar pentru un grup de clase,
necunoscându-se care clasa va fi folosită decât la rulare
• Descriere
Câteodată se doreşte folosirea unei clase într-un cadru nou fără a o recoda
încât să se potrivească noului mediu. în astfel de cazuri, se poate proiecta o clasă
Adaptee care să se comporte ca un translator. Această clasă primeşte apeluri de la
mediu şi modifică apelurile pentru ca acestea să fie compatibile cu clasa Adaptee.
Medii tipice în care un Adapter este folositor includ aplicaŃiile care suportă
comportament plug-in cum ar fi graficele, textele, editoarele media sau browser-ele
web. Un exemplu în lumea reală al şablonului Adapter o reprezintă un translator care
realizează traducerea expresiilor comune dintr-un limbaj în altul, permiŃând
comunicarea între doi indivizi altfel incompatibili.
• Implementare
Diagrama de clase a şablonului Adapter este următoarea:
Framework
-Adapter adapter
r-void performOperation()
Adapter
-Adaptee adaptee
+void operaŃi on()
Adaptee
+void adaptedOperationQ
Pentru implementarea şablonului Adapter este nevoie de:
adapter.operationQ
adaptee.adaptedOperationQ
- Framework - foloseşte interfaŃa Adapter. Această clasă fie construieşte clasa
ConcreteAdapter. fie este fixată în altă parte
- Adapter - interfaŃa care defineşte metodele pe care le foloseşte clasa
Framework
59

- ConcreteAdapter - clasa care implementează interfaŃa Adapter. Ea păstrează
o referinŃă către interfaŃa Adaptee şi traduce apelurile de metode de la clasa
Framework în apeluri de metode în interfaŃa Adaptee. Această traducere poate implica
şi ascunderea sau modificarea parametrilor şi tipurilor rcturnate
- Adaptee - interfaŃa care defineşte metodele tipului ce va fi adaptat
- ConcreteAdaptee - clasa ce implementează interfaŃa Adaptee. Ea trebuie
adaptată pentru a putea fi folosită de Framework
• Beneficii şi inconveniente
Şablonul Adapter oferă o reutilizare eficientă, permiŃând interacŃiunea dintre
două sau mai multe obiecte altfel incompatibile. Totuşi, este nevoie de multă
planificare în vederea dezvoltării unui cadru suficient de flexibil pentru a fi adaptat
convenabil. Această problemă are două aspecte: structura funcŃională şi traducerea
parametrilor.
Dacă există o nepotrivire funcŃională între apelul trimis către Framework şi
Adaptee, Adapter-ul trebuie să administreze necesităŃile de apel ale interfeŃei Adaptee.
invocând orice metode necesare înainte de a trimite apelul către Framework.
O altă provocare a Adapter-ului este aceea de transfer a parametrilor, de vreme
ce parametrii trimişi nu sunt întotdeauna compatibili între Framework şi Adaptee. In
astfel de cazuri, Adapter-ul fie creează un obiect apropiat atunci când nu există nici un
echivalent direct între cele doua medii, fie învăluie un obiect pentru a-1 face utilizabil
de către interfaŃa Adaptee.
• Variante ale şablonului
Adaptorii sunt dinamici şi foarte rar se pot vedea doi care să fie identici. Există
însă unele variante:
- MulŃi-Adaptee Adapters - în funcŃie de proiectarea sistemului, poate fi foarte
avantajos ca un Adapter să fie o parte a Framework-ului apelat. Un astfel de Adapter
se comportă de obicei ca un intermediar între sistem şi mai multe interfeŃe Adaptee
- Non-lnterface-based Adapters - folosirea interfeŃelor în Java face posibilă
dezvoltarea unor adaptori flexibili. Dar nu este mereu posibilă utilizarea interfeŃelor.
De exemplu, nu este posibilă atunci când se lucrează cu componente complete care nu
implementează nici o interfaŃă. In aceste situaŃii, şablonul Adapter este folosit Iară
interfeŃe. Aceste implementări sunt însă mult mai puŃin flexibile
- o interfaŃă între apelant şi Adapter şi una între Adapter şi Adaptee - interfaŃa
între apelant şi Adapter permite noilor adaptori să fie mai uşor adăugaŃi în sistem pe
parcursul rulării. InterfaŃa între Adapter şi Adaptee permite interfeŃelor Adaptee să fie
încărcate dinamic în momentul rulării
• Şabloane asociate
Printre şabloanele asociate se află:
- Bridge - cu toate că şabloanele Bridge şi Adapter sunt similare, intenŃia lor
este diferită. Şablonul Bridge separă partea abstractă a unei componente de
implementarea acesteia, permiŃând fiecăreia să fie schimbate independent. Şablonul
Adapter permite utilizarea unui obiect altfel incompatibil
60

- Decorator - şablonul Adapter este folosit pentru a schimba interfaŃa unui
obiect, păstrând aceeaşi funcŃionalitate. Şablonul Decorator lasă interfaŃa obiectului
neschimbată, dar îi intensifică funcŃionalitatea
- Proxy - atât şablonul Adapter cât şi Proxy pun la dispoziŃie o interfaŃă
principală unui obiect. DiferenŃa este că interfaŃa şablonului Adapter este schimbată,
în timp ce interfaŃa şablonului Proxy este aceea cu cea a obiectului
- Business Delegate - acest şablon pot fi folosit ca un Proxy. El poate opera ca
un Adapter pentru sisteme altfel incompatibile
■ Exemplu
Considerându-se un sistem curat deja creat, se doreşte adăugarea de noi
elemente. Pentru aceasta se foloseşte şablonul Adapter:
interf ace Clean { public voie! makeClean ( ) ; }
elass Office irr.plements Clean { public veid
makeClean() {
Systern. out .println ( "Oficiu curat") ;
lass Workshcp implements Clean{
public voie! makeClean () {
System.out.printlnŃ"3irou curat");
nterface Extra exteno.s Clean; public void takeCare ( i ;
lass Facility implements Extra{ public void
makeCleanŃ) {
System.out.println("SpaŃiu de muncă curat"
public void takeCare ( ) {
System.out.println("S-a realizat treaba!")
class Cest {
static void Jobs (Extra job) {
if (job insrancecf Clean) ((Clean)job).makeClean
if ((Extra) job instar.ceof Extra) Ń (Extra)j ob)
.takeCare ( ) ;
public static void main(Scring[] args) {
Extra e =■■- nevi Facility(); Jobs (e) ;
Clean ci = new Office ( ) ;
Clean c.2 =■- new Worksnop ( ) ;
cl.m.akeCleanO ;
c2.makeClean();
e.makeClean() ;

IV.2. Bridge
• Cunoscut şi ca Handle / Body
• ProprietăŃi
• Scop
- Tip: structural
- Nivel: componentă
Să împartă o componentă complexă în două succesiuni ierarhice separate dar
asociate: funcŃionarea abstractă şi implementarea internă. Acest lucru uşurează
modificarea oricărui aspect al componentei.
• Introducere
Pentru dezvoltarea unei liste cu lucruri ce trebuie făcute. în managerul
personal de informaŃii se doreşte flexibilitate în privinŃa felului în care este
reprezentată această listă utilizatorului. în plus, se vrea o posibilitate de modificare a
funcŃionalităŃii de bază a listei, lăsând utilizatorilor capacitatea de a alege între o listă
neordonată, o listă secvenŃială sau o listă prioritară. Pentru a introduce această
caracteristică în aplicaŃie, se dezvoltă un grup de clase, fiecare conŃinând o cale
specifică de afişare a listei şi de organizare a informaŃiilor. Această soluŃie devine
repede impracticabilă, deoarece există multe modalităŃi de afişare a listei şi căi de
stocare a informaŃiilor listei.
Este mai bine să se separe lista cu lucrurile ce trebuie făcute. Şablonul Bridge
face acest lucru prin definirea a două clase sau interfeŃe care lucrează împreună.
Pentru managerul de informaŃii, acestea sunt List şi Listlmpl. Clasa List reprezintă
funcŃionalitatea de afişare, ea delegând stocarea informaŃiilor articolelor listei către
implementarea ei de baza, clasa Listlmpl. Beneficiul acestei soluŃii este că se pot mixa
şi potrivi clasele încât să producă o mai mare funcŃionalitate.
• Utilizare
Şablonul Bridge se foloseşte când:
- se doreşte flexibilitate între partea abstractă şi implementarea unei
componente, evitându-se o relaŃie statică între cele două
- orice schimbare a implementării trebuie să fie invizibilă clienŃilor
- se pot crea subclase, dar se doreşte administrarea separată a celor două
aspecte ale sistemului
• Descriere
Elementele complexe dintr-un sistem pot uneori varia atât în ceea ce priveşte
funcŃionalitatea lor externă, cât şi în privinŃa implementării lor de bază. In astfel de
cazuri, moştenirea este o soluŃie nedorită, de vreme ce numărul claselor ce trebuie
create creşte. Două reprezentări şi implementări duc la patru clase ce trebuie
dezvoltate. în timp ce trei conduc la nouă clase.
62

în plus. moştenirea leagă o componentă într-un model static, făcând-o dificil
de modificat în viitor. Schimbarea unei componente reprezintă o provocare deoarece
ea tinde să varieze pe măsură ce sistemul esie dez\oltat şi utilizat. Este de preferat să
se găsească o cale dinamică pentru a varia ambele aspecte ale componentei.
Aici intervine şablonul Bridge. El rezolvă problema prim descompunerea
componentei în cele doua aspecte. Cu două lanŃuri de moştenire separate - unul se
ocupă cu funcŃionalitatea, iar celălalt cu implementarea - este mult mai uşor să se
combine elementele fiecărei părŃi. Mai mult. cerinŃele de codare a şablonului Bridge
fiind scăzute, rezultă un număr mic de clase ce trebuie scrise pe măsură ce numărul
variaŃiilor creşte.
• Implementare
Diagrama de clase a şablonului Bridge este următoarea:
Abstraction
-Implementation implementation
+void operationQ _____
implementation.operalionlmpl()
RefineAbstraction
interface Implementation
+void operationlmpl'()
ConeretelmplementationA ConeretelmplementationB
+void operationlmplQ +void operationlmplC
Pentru implementarea şablonului Bridge se folosesc următoarele:
- Abstraction - clasa ce defineşte funcŃionarea abstractă pentru Bridge, punând
la dispoziŃie comportamentul şi structura standard. ConŃine o referinŃă către o instanŃă
a interfeŃei Implementation
- RefineAbstraction - clasa ce extinde clasa Abstraction. conŃinând
comportamente adiŃionale sau modificate
- Implementation - interfaŃa ce reprezintă funcŃionalitatea de bază folosită de
instanŃele Abstraction
- Concretelmplementation - clasa ce implementează interfaŃa Implementation.
ConŃine comportamentul şi structura claselor Implementation
63

• Beneficii şi inconveniente
Şablonul Bridge oferă posibilitatea de a distribui obiecte cu implementare de
bază între multiple obiecte abstracte. Are o mare flexibilitate în ceea ce priveşte
modificarea implementărilor, schimbările putând surveni iară acŃiuni necesare din
partea clientului.
Când se proiectează o aplicaŃie care foloseşte şablonul Bridge, este important
să se cunoască exact ce responsabilităŃi aparŃin funcŃionării abstracte şi care aparŃin
implementării interne. De asemenea, trebuie observat clar care este modelul de bază al
implementării şablonului Bridge. O problemă care poate apărea în timpul utilizării
şablonului Bridge este dezvoltarea implementării şablonului în jurul uneia sau mai
multe variaŃii.
• Variante ale şablonului
Printre variantele şablonului Bridge se numără:
- Automatic Bridges - unele implementări ale şablonului Bridge sunt construite
astfel încât să varieze fără o acŃiune din partea utilizatorului, bazându-se în schimb pe
informaŃia dată de aplicaŃie sau de platforma de operare pentru a se modifica
- Shared Implementations - unele clase implementate în special cele tară stări -
clase ce nu au o stare internă - pot fi distribuite între mai multe obiecte ale aplicaŃiei.
In funcŃie de cât de larg sunt distribuite aceste clase pot fi implementate ca o interfaŃă
- Single Implementation - uneori există doar o singură clasă implementată care
serveşte mai multe clase abstracte. In acest caz, nu este necesar să se definească o
clasă de bază pentru partea de implementare a şablonului Bridge
• Şabloane asociate
Printre şabloanele asociate se află:
- Adapter - şabloanele Bridge şi Adapter sunt similare ca structură, dar diferă
ca intenŃie. Şablonul Bridge separă partea abstractă şi implementarea pentru a le
permite să se modifice separat. Şablonul Adapter permite utilizarea unui obiect a cărui
interfaŃă ar fi altminteri incompatibilă
- Singleton - se foloseşte când implementarea claselor poate fi distribuită
- Flyweight - când structura arborescentă devine largă, aplicarea şablonului
Flyweight poate ajuta la reducerea numărului de obiecte administrate de arbore
• Exemplu
Dacă se doreşte afişarea unei baze de date ce conŃine întrebări, în funcŃie de
dorinŃele utilizatorului, se poate utiliza şablonul Bridge:
interface Question {
public void nextQuest i ori ( ) ; public
void newQuesrion(String q); public
void displayQuesti.cn (); public voi.d
displayAHQuestions ( ) ;
64

class QuestionManager -.
prctccred Ques:i:;:i qu-sdi;
public String catilv,:;
public Quest ionManager ; S ■; .-"in z ?-~do:i) {
this. catalog = cazaLz::;
}
public voia next() { quesuii.nexLQuestion ( ) ; ■
pudic void newOnc (5~ring ques~; •
questDB.newQuestion'queso ; ;
public void display() { questDB.displayQuestion(); }
pudic void displayAll() {
System.ou:.println("Question Catalog: " + catalog);
questDB.displayAllQuestions() ;
}
i j
class Quest-ioriFormat extends QuestionManager {
pudic QuesrionForma~ ( String catalog) { super ( catalog) ; }
pudic veid displayAllŃ) { super. displayAll (); }
class JavaQuestions inplements Question {
private List questions = new ArrayList();
private int current = C; public JavaQuestions
( ) {
questions.add("Ce e Java?");
questions.add("Ce e o interfaŃă?");
questions.add("Ce e un fir de execuŃie?");
public void nextQuestion() {
if (current

■ Introducere
Se doreşte modificarea managerului personal de informaŃii astfel încât el să
permită utilizatorilor să administreze un proiect complex. Noile caracteristici includ
definirea proiectului ca un grup de sarcini şi subsarcini asociate, precum şi asocierea
rezultatelor cu sarcinile. O cale naturală pentru îndeplinirea acestui lucru este
definirea unei structuri arborescente, unde din sarcina rădăcină - care reprezintă
proiectul în sine - se ramifică subproiecte. şi aşa mai departe. Prin urmare, se
defineşte o clasa Task ce reŃine o colecŃie de alte obiecte de tip Task şi Deliverable
(rezultat). De vreme ce acestea sunt legate de proiect, se defineşte un părinte comun
pentru ele - clasa Projectltem.
Totuşi, ce se întâmplă dacă utilizatorii trebuie să execute o acŃiune care
depinde de tot arborele? De exemplu, un manager de proiect doreşte o estimare a
timpului pentru realizarea sarcinilor şi livrarea rezultatelor pentru un anumit proiect.
Pentru aceasta, trebuie scris cod pentru parcurgerea arborelui şi apelarea metodelor
potrivite la fiecare ramură. Este mult de muncă, implicând scrierea unui cod separat
pentru parcurgerea arborelui, apelarea metodelor şi colectarea rezultatelor. Având
clase diferite - Task şi Deliverable - la fiecare ramură a arborelui, acestea trebuie
manipulate diferit în vederea obŃinerii estimării timpului. Pentru un număr mare de
clase şi un arbore complex, codul devine dificil de administrat.
Există însă o cale mai bună de rezolvare a acestei probleme. Cu ajutorul
şablonului Composite se poate folosi polimorfismul şi recursia pentru a pune la
dispoziŃie o soluŃie eficientă şi simplă. Se începe prin definirea unei metode standard
pentru toate clasele ce conŃin estimarea timpului, denumită getTimeRequired. Această
metodă se defineşte pentru interfaŃa Projectltem şi se implementează acel
comportament în toate clasele care sunt tipuri ale interfeŃei Projectltem. Pentru
obiectele Deliverable, metoda getTimeRequired se defineşte astfel încât să returneze 0
deoarece timpul nu este direct asociat cu un rezultat. Pentru clasa Task, se returnează
un timp ce constă din timpul în care s-a efectuat sarcina plus suma apelurilor metodei
getTimeRequired pentru toate obiectele-fiu de tip Task.
Folosind acest şablon, metoda getTimeRequired se defineşte încât să calculeze
automat timpul estimat fiecărei părŃi a arborelui. Se apelează metoda
getTimeRequired doar pentru partea dorită a sarcinii şi codul metodei indeplineşte
funcŃia de parcurgere a arborelui şi de calcul a rezultatelor.
• Utilizare
Şablonul Composite se foloseşte când:
- există o componentă model cu o structură arborescentă
- structura poate avea orice nivel de complexitate şi este dinamică
- se doreşte tratarea uniformă a structuri componentelor, utilizând operaŃii
comune în toată ierarhia
• Descriere
De multe ori se vrea dezvoltarea componentelor care urmează un model parteîntreag.
Acesta este un model care permite tratarea unei colecŃii de obiecte identice ca
o entitate. Aceste structuri sunt flexibile şi uşor de folosit. Utilizatorii pot modifica
structura pe măsură ce aplicaŃia rulează, adăugând sau eliminând anumite părŃi.
66

Şablonul Composite suportă aceste caracteristici prin definirea unei structuri
de clase ce poate fi extinsă. Această structură este compusă dintr-o componentă de
bază. clase frunză şi clasa Composite. Componenta de bază conŃine modelul central,
definind metodele standard sau variabilele ce vor fi folosite de toate obiectele de tip
Composite. Clasele frunză conŃin comportamentul terminal. Hle reprezintă părŃi ale
clasei Composite. fără a conŃine alte componente. Clasei Composite i se pot adăuga
alte componente, permiŃând extinderea structurii.
Un desen creat cu ajutorul unui instrument de editare grafică este un exemplu
de şablon Composite. într-un desen, un număr de forme elementare pot fi asociate şi
tratate ca un întreg; se pot defini de asemenea desene care să conŃină alte desene, sau
o combinaŃie de desene şi forme.
• Implementare
Diagrama de clase a şablonului Composite este următoarea:
Component 0..*
+void operation()
i i.
<
Node
Composite
-Component[] components
+void addComponent(Component[] c)
+void operationQ +void removeComponent(Component[] c)
+void operation()
Şablonul Composite are trei elemente:
pentru flecare copil d i n componente c.operationQ
- Component - interfaŃa care defineşte metodele disponibile pentru toate părŃile
structurii arborescente. Ea poate fi implementată ca o clasă abstractă atunci când
trebuie pus la dispoziŃie un comportament standard pentru toate subtipurile. în mod
normal, această interfaŃă nu poate fi instanŃiată; subclasele ei sau clasele care o
implementează, numite şi noduri, pot fi instanŃiate şi folosite la crearea unei colecŃii
sau structuri arborescente
- Composite - clasa definită de componentele pe care le conŃine. Ea susŃine un
grup dinamic de obiecte Component, prin urmare are metode pentru adăugarea şi
eliminarea instanŃelor Component din colecŃia sa. Metodele definite în interfaŃa
Component sunt implementate încât să exercite comportamentul specific pentru tipul
respectiv de Composite şi să apeleze aceeaşi metodă în fiecare din nodurile sale
- Leaf - clasa care implementează interfaŃa Component, conŃinând o
implementare pentru fiecare din metodele acesteia. DiferenŃa dintre o clasa Leaf şi o
clasa Composite este aceea că prima nu conŃine nici o referinŃă către alte interfeŃe
Component
67

Beneficii şi inconveniente
Şablonul Composite pune la dispoziŃie o combinaŃie puternică: flexibilitate
considerabilă a structurii şi o interfaŃă uşor de administrat. Structura poate fi
schimbată în orice moment prin apelarea metodei potrivite pentru adăugarea sau
eliminarea unei componente. Deoarece componentele unui Composite pot fi
schimbate înseamnă că este posibilă şi modificarea comportamentului acestuia.
Utilizarea interfeŃelor creşte şi mai mult flexibilitatea. Acestea permit
construcŃia cadrelor folosind şablonul Composite şi introducerea de noi tipuri la
rulare. în acelaşi timp. utilizarea interfeŃelor poate fi un inconvenient atunci când se
doreşte definirea unor atribute şi a unei implementări de bază încât fiecare nod să
poată moşteni comportamentul. în aceste cazuri, interfaŃa Component trebuie definită
ca o clasă abstractă.
Un alt inconvenient vine chiar din flexibilitatea şablonului - deoarece acesta
este atât de dinamic, devine uneori dificil de testat. El necesită în mod normal o
strategie de testare/validare mai sofisticată, construită în jurul conceptului de ierarhie
de obiecte parte-întreg. Dacă testarea devine o problemă, cea mai bună rezolvare este
introducerea testării în cadrul clasei Composite.
• Variante ale şablonului
Unele variante ale şablonului Composite includ:
- The Root Node - pentru creşterea administrării în cadrul sistemului, unele
implementări ale şablonului Composite definesc un obiect distinct care se comportă
ca o bază pentru întreaga ierarhie de obiecte. Dacă obiectul-rădăcină este reprezentat
printr-o clasă separată, el poate fi implementat ca un Singleton. sau accesul către el se
poate face cu ajutorul unui Singleton
- Rule-based Branching - pentru structuri Composite mai complexe, în special
pentru cele cu multiple tipuri de noduri şi ramuri, este uneori necesară impunerea de
reguli privind cum şi când anumite tipuri de noduri pot fi unite cu anumite tipuri de
ramuri
• Şabloane asociate
Printre şabloanele asociate se află:
- Chain of Responsibility - este utilizat împreună cu şablonul Composite atunci
când metodele trebuie propagate în arbore de la frunze către ramuri
- Flyweight - când structura arborescentă devine largă, prin aplicarea acestui
şablon se poate reduce numărul de obiecte administrate de arbore
- Iterator - este folosit împreună cu şablonul Composite pentru a încapsula
parcurgerea arborelui, care altfel ar putea deveni complicată
- Visitor - folosit împreună cu şablonul Composite pentru centralizarea
comportamentului care altfel ar trebui împărŃit între clasele frunză şi ramuri
- Composite View - acest şablon descrie cum o vedere poate fi compusă din
mai multe vederi, şi aşa mai departe
68

• Exemplu
Putem considera o structură arborescentă de forma următoare: un manager
general are un număr de angajaŃi şi unii dintre aceştia sunt la rândul lor manageri care
au un număr de angajaŃi:
class Enployee {
St ring nane;
doucle salary;
Emp]oyee(String n, double s){
nane - r:;
salary = s;
}
String getName() { return name; }
double getSalary() { return salary; }
public String toString() { return "Emplcyee " + name; } }
class Manager (
Manager mgr;
Enployee[] ely;
String dept;
Manager(Manager mgr,Enployee[] e, String d ) {
this(e, d);
this.ngr = mgr; }
Manager(Employee[] e, String d) {
ely = e;
dept —a;
String getDeptŃ) { return dept; }
Manager getManager() { return mgr; }
Employee[] getEmployee() { return ely; }
public String toString() { return dept + " manager"; }
IV.4. Decorator
• Cunoscut şi ca Wrapper
• ProprietăŃi
Scop
- Tip: structural
- Nivel: componentă
Să pună la dispoziŃie o cale flexibilă de adăugare şi eliminare a funcŃionalităŃii
componentelor fără a le schimba infăŃişarea externă sau funcŃia.
69

Introducere
Şablonul Composite descris anterior adaugă managerului personal de
informaŃii funcŃionalitate, prin intermediul unei ierarhii de obiecte Task şi
Deliverable. Toate clasele implementau interfaŃa Projectltem. care le identifica ca
aparŃinând unui proiect. Dacă însă se doreşte extinderea capacităŃilor de bază ale
claselor Task şi Deliverable, adăugând caracteristici în plus, cum ar fi următoarele?
- articole dependente - o interfaŃă Projectltem care depinde de un alt obiect
Task sau Deliverable pentru se realiza
- suport de documente - un obiect Task sau Deliverable care face referinŃe
către documentaŃii adiŃionale
Dacă se adaugă aceste caracteristici folosind subclase, trebuie să se codifice o
multitudine de clase. De exemplu, pentru a face doar obiectele Deliverable să suporte
aceste caracteristici, trebuie scrise patru clase: Deliverable, DependentDeliverable,
SupportedDeliverable şi SupportedDependentDeliverable. în faŃa acestui
inconvenient, compunerea obiectelor poate fi considerată în vederea adăugării noilor
funcŃionalităŃi. însă se poate ajunge la cod duplicat în mai multe locaŃii. în cel mai
bun caz, se creşte doar complexitatea codului.
Dacă, în schimb, se scriu clase care să aibă capacităŃi plug-in? Se creează clase
dependente care pot fi ataşate oricărei interfeŃe Projectltem pentru a se extinde
funcŃionalitatea de bază. De exemplu, se definesc clasele DependentProjectltem şi
SupportedProjectltem. Fiecare clasă conŃine doar codul necesar capacităŃii sale
opŃionale, precum şi o referinŃă către interfaŃa Projectltem reală pe care o extinde.
Acest lucru înseamnă mai puŃin cod de întreŃinut şi libertatea de a folosi orice
combinaŃie a acestor clase dependente pentru a adăuga noi grupuri de capacităŃi.
• Utilizare
Şablonul Decorator se foloseşte când:
- se doreşte efectuarea de schimbări dinamice care să fie transparente
utilizatorilor, fără restricŃiile impuse de subclasare
- capacităŃile componentelor pot fi adăugate sau eliminate pe măsură ce
sistemul rulează
- există un număr de caracteristici independente care trebuie aplicate dinamic
şi care pot fi folosite în orice combinaŃie
• Descriere
Unele obiecte au o funcŃionalitate complexă şi/sau o structură care poate fi
adăugată sau eliminată. Şablonul Decorator funcŃionează permiŃând straturilor să fie
adăugate sau eliminate dintr-un obiect de bază. Fiecare strat poate conŃine
comportament (metode) şi stare (variabile).
Şablonul Decorator este potrivit pentru aplicaŃii care implică supraîncărcarea
ce poate fi construită dinamic. Produsele Groupware ce permit echipelor ce lucrează
în reŃea să combine munca de editare a unui unic document de bază. este un exemplu.
De asemenea, şablonul Decorator este potrivit pentru editoarele de imagini, precum şi
pentru majoritatea aplicaŃiilor ce implică texte sau formatare de documente.
70

• Implementare
Diagrama de clase a şablonului Decorator este următoarea:
ConcreteComponent
+void operationQ
interface Component
+void operation(')
component.operationQ
Decorator
-Component component
+void setComponent(Component c)
+void operationQ
Pentru implementarea şablonului Decorator este nevoie de:
ConcreteDecorator
-int newAttribute
+void operation()
+void newOperation()
- Component - reprezintă comportamentul generic al unei componente. Poate
fi o clasă abstractă sau o interfaŃă
- Decorator - defineşte comportamentul standard care se aşteaptă din partea
tuturor Decorator-ilor. Poate fi o clasă abstractă sau o interfaŃă. ConŃine o referinŃă
către un obiect Component, care poate fi un obiect ConcreteComponent sau un alt
Decorator
- ConcreteDecorator - fiecare subclasă a Decorator-ului trebuie să suporte
înlănŃuirea (referinŃa către o componentă, plus abilitatea de a adăuga şi elimina
această referinŃă)
• Beneficii şi inconveniente
Şablonul Decorator oferă oportunitatea de a ajusta uşor comportamentul unui
obiect în timpul rulării. In plus. codarea poate deveni mult mai uşoară, de vreme ce
trebuie scrise o serie de clase, fiecare Ńintind o funcŃionalitate specifică, în loc de a
coda toate comportamentele în cadrul componentei însăşi. Acest lucru face
componenta mult mai uşor de extins în viitor deoarece modificările pot fi introduse
codând noi clase.
în funcŃie de comportamentul lor, unele straturi ale şablonului Decorator pot fi
distribuite între multiple obiecte ale componentei. Astfel se reduce memoria
consumată de sistem.
Folosit până la extrem, şablonul Decorator produce de regulă un număr mare
de straturi, adică între utilizator şi obiectul real există mai multe obiecte mici. Acest
lucru are un număr de consecinŃe. Testarea codului devine mai dificilă iar viteza de
operare a unui sistem se reduce daca Decorator-ul este proiectat impropriu.
71

Trebuie asigurată tratarea în mod egal a obiectelor. Aceasta este importantă
pentru şablonul Decorator, de vreme ce straturile obiectului stau fiecare "în faŃa"
celuilalt. Dacă egalitatea este testată în cadrul aplicaŃiei, atunci trebuie scrisă o
operaŃie care să identifice obiectul de bază sau combinaŃia dintre acesta şi ordinul şi
valorile fiecărui strat.
■ Variante ale şablonului
De multe ori este de dorit dezvoltarea claselor şablonului Decorator cu o
referinŃă înainte şi una înapoi pentru a le face mai uşor de înlăturat în timpul rulării
sistemului.
Unele implementări ale şablonului nu folosesc un Decorator abstract. In mod
normal, această variantă este folosita atunci când există doar o singură variaŃie
posibilă a componentei.
Se pot crea Decoratori suprascrişi care vor redefmi unele părŃi ale
comportamentului componentei. Acest lucru trebuie să se facă însă cu grijă deoarece
componentele care se bazează pe şablonul Decorator pot manifesta comportamente
imprevizibile.
• Şabloane asociate
Printre şabloanele asociate se află:
- Adapter - acest şablon este folosit pentru schimbarea interfeŃei asupra
aceleiaşi funcŃionalităŃi. în timp ce şablonul Decorator lasă interfaŃa la fel dar schimbă
funcŃionalitatea
- Composite - şablonul Decorator poate fi văzut ca o versiune mai simplă a
şablonului Composite; în loc de avea o colecŃie de componente, Decorator-ul
păstrează o singură referinŃă către o altă componentă. Cealaltă diferenŃăă este că
Decorator-ul măreşte funcŃionalitatea
- Strategy - şablonul Decorator este utilizat pentru a modifica sau extinde
funcŃionalitatea externă a unui obiect, în timp ce şablonul Strategy modifică
comportamentul intern al obiectului
■ Exemplu
Considerăm o clasă care afişează un număr şi utilizăm şablonul Decorator care
să adauge un text numărului respectiv:
class Nuir.ber {
public void prinŃ() {
System, out. println (r.ew Ranaom ( ) . nextlnt Ń ) ) ;
class Decorator {
public Decorator() {
System.out.prinŃ{"Număr aleator: " ) ;
new Number() .prinŃ(} ;
72

ciass Sub'\uinber exter.ds Nuiiberi
public SubNumber{) {
super();
Systen.ont.prinŃŃ"Număr aleator: ");
prinŃ();
IV,5. Facade •
ProprietăŃi
• Scop
- Tip: structural
- Nivel: componentă
Să pună la dispoziŃie o interfaŃă simplificată unui grup de subsisteme sau unui
subsistem complex.
• Introducere
Utilizatorii doresc să poată modifica o interfaŃă grafică pentru a o face mai
atractivă sau mai uşor de utilizat. De exemplu, unii utilizatori pot avea o slăbiciune
vizuală sau nu pot citi un font mic, deci trebuie să mărească dimensiunea font-ului.
ForŃând utilizatorul să treacă prin toŃi paşii setup-ului, interfaŃă grafică afişând
detaliile în font-ul mic, nu este un lucru prea favorabil. Un wizard care să-i ajute pe
cei cu deficienŃe vizuale să treacă prin etapele setup-ului, este mult mai bun.
Acest ajutor nu trebuie să limiteze opŃiunile de utilizare şi modificare a
aplicaŃiei. Se doreşte punerea la dispoziŃie a unei modalităŃi de vizualizare specializată
a sistemului, în acelaşi timp menŃinându-se toate caracteristicile. Acesta este şablonul
Facade - un wizard al sistemului.
• Utilizare
Şablonul Facade se foloseşte pentru:
- a face sistemele complexe mai uşor de utilizat prin intermediul unei interfeŃe
simple, fără a elimina opŃiunile avansate
- a reduce cuplarea dintre clienŃi şi subsisteme
- a stratifica subsistemele
• Descriere
Multe din sistemele software moderne sunt foarte complexe. Şabloanele ajută
la structurarea aplicaŃiilor şi la o mai bună tratare a complexităŃii. De multe ori se
realizează acest lucru prin împărŃirea funcŃionalităŃii între o serie de clase mai mici.
Clasele adiŃionale pot fi de asemenea produse ca rezultat al partiŃionării sistemului.
Divizarea unui sistem în mai multe subsisteme ajută la tratarea mai uşoară a
complexităŃii sistemului şi pune la dispoziŃie oportunitatea de împărŃire a muncii.

Separând un sistem într-un număr de clase specializate este o practică hună de
proiectare orientată pe obiecte. Totuşi, faptul că există un număr mare de clase în
sistem, poate fi un inconvenient.
ClienŃii care folosesc sistemul trebuie să lucreze cu mai multe obiecte.
Utilizatorii tind să devină confuzi când au sute de opŃiuni de configurare. Prin urmare,
majoritatea opŃiunilor trebuie presetate. clientul urmând să aibă doar câteva opŃiuni de
bază de configurat. Şablonul Facade pune la dispoziŃie aceste opŃiuni şi poate
determina ce subsisteme trebuie apelate.
în mod normal. Facade va delega majoritatea muncii către subsisteme, dar
poate îndeplini anumite atribuŃiuni el însuşi. IntenŃia lui este de realiza o interfaŃă
simplă cu un set de sisteme, dar clienŃii care doresc opŃiunile mai avansate pot
interacŃiona cu subsistemele.
• Implementare
Diagrama de obiecte a şablonului Facade este următoarea:
:Subsystem
:Facade :Facade
:Subsystem :Subsvstem :Subsystem
:Subsystem
Pentru implementarea şablonului Facade se folosesc următoarele:
- Facade - clasa pe care o folosesc clienŃii. Cunoaşte subsistemele pe care le
utilizează şi responsabilităŃile acestora. în mod normal, toate cerinŃele clientului vor fi
trimise către subsistemul cel mai potrivit
- Subsystem - set de clase care poate fi folosit direct de clienŃi sau care poate
îndeplini munca trimisă către el de Facade. Pentru subsistem. Facade reprezintă un
simplu client
74

■ Beneficii şi inconveniente
Beneficiul şablonul Facade este acela că el realizează o interfaŃă simplă cu un
sistem complex tară a reduce opŃiunile puse la dispoziŃie de sistem. Această interfaŃă
protejează clientul de o abundenŃă de opŃiuni.
Şablonul Facade trimite cerinŃele clientului către subsistemele care le pot
rezolva. De regulă, o cerinŃă va fi trimisă către mai multe subsisteme. Deoarece
clientul interacŃionează doar cu Facade. activitatea internă a sistemului se poate
schimbă. în timp ce clientul rămâne neschimbat pentru Facade.
Şablonul Facade poate fi folosit pentru a reduce cuplarea între subsisteme.
Fiecare subsistem poate avea propriul său Facade iar alte părŃi ale sistemului folosesc
Facade pentru a comunica cu subsistemele.
■ Variante ale şablonului
Şablonul Facade se poate implementa ca o interfaŃă sau o clasă abstractă. Se
lasă astfel detaliile privind implementarea pe mai târziu.
Mai multe şabloane Facade pot pune la dispoziŃie diferite şabloane pentru
acelaşi set de subsisteme.
Şablonul Facade este uneori variat pentru a ascunde subsistemele. Când este
folosit ca o legătură între subsistemele arhitecturii, unul din scopurile sale este să
reducă complexitatea interacŃiunii sistem-sistem. De exemplu, un sistem unde
apelurile trec printr-un Facade central este mai uşor de administrat decât unul cu un
număr mare de clase cuplate.
• Şabloane asociate
Printre şabloanele asociate se află:
- Abstract Factory - acest şablon creează familii de obiecte asociate. Pentru a
simplifica accesul la diferite obiecte care se creează, se poate crea de asemenea un
obiect Facade
- Mediator - şabloanele Mediator şi Facade par foarte similare. DiferenŃa este
în intenŃia şi implementarea lor. Mediator-ul ajută la uşurarea comunicării între
componente şi a adăugării de comportamente. Facade este doar o abstractizare a
interfeŃei unuia sau mai multor subsisteme
- Singleton - Facade foloseşte şablonul Singleton pentru a garanta un singur
punct de acces global la un subsistem
- Session Facade - acest şablon este un Facade care încapsulează
complexitatea lui Enterprise JavaBeans, pentru a simplifica interfaŃa acesteia cu
clienŃii
• Exemplu
Un bun exemplu al şablonului Facade este JDBC care este folosit pentru
conexiunea la o bază de date şi pentru a manipula datele tară a expune detalii
clienŃiilor:
interface General { public void accessGenerai ( ) ; }
interface Scecial extends General { publi.c void
accessSpecial ( ) ; }
75

interiace Private exLencis Genera] {
r)ub] ic void accsssPnva:e ; j ;
}
class Generai.Tnfo inplements General
cu'clic void accessGeneral() {
class Soecrailnfo irnplements Speciali
public void accessSpecial() { /
public void accessGeneral;) {}
lass Privatelnfo implements Private, Special {
public voia aecessPrivate() { //... }
public voia accessSpecial() { //... }
public void accessGeneral() { //... }
i
ciass Connection {
.
user is unauthorized) tnrcw new Exceptiom
if {user is general) return new Generallnfo();
if (user is special) return new Speciallnfo();
if (user is executive) return new Privatelnfoi
IV.6. Flyweight
• ProprietăŃi
• Scop
- Tip: structural
- Nivel: componentă
Să reducă numărul de obiecte de nivel scăzut dintr-un sistem prin intennediul
distribuirii de obiecte.
• Introducere
Programarea orientată pe obiecte permite mai multor obiecte să existe pe
perioada executării, în special dacă sunt obiecte de nivel scăzut. Se plasează astfel o
incărcatură mare în memoria maşinii virtuale Java.
Multe obiecte din managerul personal de informaŃii pot fi editate, deci folosesc
şablonul State pentru a determina dacă conŃinutul articolelor va fi salvat. Fiecare din
aceste articole poate avea propria sa colecŃie de obiecte State.
O cale de a uşura problema de a avea mai multe obiecte, este distribuirea
acestora. Multe din aceste obiecte de nivel scăzut diferă foarte puŃin. în vreme ce
starea şi comportamentul lor sunt în cele mai multe cazuri identice. Distribuirea
instanŃelor reduce considerabil numărul lor, tară a se pierde ceva din funcŃionalitate.
Pentru un set de obiecte, şablonul Flyweight separă acele părŃi ale obiectelor care sunt
la fel, de părŃile care sunt diferite.
76

• Utilizare
Şablonul Flyweight se foloseşte atunci când:
- aplicaŃia foloseşte mai multe obiecte identice sau aproape identice
- pentru fiecare din obiectele aproape identice, părŃile care diferă pot fi
separate, permiŃând părŃii identice să fie distribuită
- grupuri de obiecte aproape identice pot fi înlocuite de un obiect distribuit, o
data ce părŃile diferite ale stării au fost eliminate
- aplicaŃia trebuie să distingă între obiectele aproape identice aflate în starea
lor originală
■ Descriere
Şablonul Flyweight intenŃionează să reducă numărul obiectelor dintr-o
aplicaŃie şi face aceasta prin distribuirea obiectelor. Obiectele conŃin date interne, dar
datele privind contextul în care ele operează, sunt furnizate de o sursă externă. Fiecare
obiect distribuit trebuie să fie pe cât de generic posibil şi independent de context.
Distribuind obiecte, şablonul Flyweight reduce semnificativ numărul acestora.
Obiectul distribuit e folosit de mai mulŃi clienŃi şi se distinge clar de un obiect care nu
este distribuit.
Un exemplu de utilizare a şablonului Flyweight este un manager de plan.
Atunci când se construieşte o interfaŃă grafică cu utilizatorul, se folosesc mai multe
componente. Se utilizează prin urmare managerele de plan. în general, acestea sunt
aproape identice. Ele diferă doar în ceea ce priveşte componentele specifice pe care le
administrează şi un anumit set de atribute. Daca se înlătură aceste componente şi
atribute, fiecare instanŃă a acestor managere este identică. Având un obiect distribuit
pentru fiecare manager de plan. se reduce numărul total de obiecte.
ClienŃii care folosesc obiectul distribuit au responsabilitatea de a pune la
dispoziŃie şi/sau a calcula contextul informaŃional. InformaŃia este trimisă către
obiectul distribuit atunci când este nevoie. Un Flyweight este distribuit, deci un client
nu trebuie să creeze un Flyweight direct. Insă nu toate obiectele Flyweight trebuie
distribuite. Acest şablon permite distribuirea obiectelor, dar nu cere în mod expres
acest lucru. El se foloseşte doar atunci când se pot identifica şi extrage uşor datele
externe din obiecte şi când numărul diferitelor stări este limitat.
Implementare
Diagrama de clase a şablonului Flyweight este următoarea:
FlyweightFactory 0.. *
►
interface Flyweight
+Flyweight getFlyweight(Object Key) +void someOperation(Object externalState)
i
i
Client
ConcreteFIyweight
+void someOperation(Object externai State)
77

Pentru implementarea şablonului Flyweight este nevoie de:
- Flyweight - interfaŃa care defineşte metodele pe care clienŃii le pot folosi
pentru trimiterea stării interne către obiectele flyweight
- ConcretcFlyweight - clasa ce implementează interfaŃa Flyweight şi abilitatea
de a stoca datele interne. Datele interne trebuie să fie reprezentative pentru toate
instanŃele unde este necesar Flyweight
- FlyweightFactory - clasa responsabilă pentru crearea şi administrarea
obiectelor Flyweight. Ea poate crea aceste obiecte la începutul aplicaŃiei sau atunci
când este nevoie de ele
- Client - clasa responsabilă pentru crearea şi punerea la dispoziŃie a
contextului pentru obiectele flyweight. Singura cale de a obŃine o referinŃă către un
obiect flyweight este prin intermediul clasei FlyweightFactory
• Beneficii şi inconveniente
Beneficiul evident al acestui şablon este acela că reduce numărul de obiecte ce
trebuie administrate. Se salvează astfel spaŃiu, atât în memorie cât şi pe dispozitivul
de stocare. Cel mai mult spaŃiu se va salva atunci când contextul informaŃional pentru
flyweight este compilat în loc de a fi stocat. Totuşi, acest lucru conduce şi la
inconvenientul acestui şablon: rulare costisitoare.
în loc de a stoca multe obiecte, clienŃii trebuie acum să calculeze contextul şi
să pună rezultatul la dispoziŃia flyweight-ului. Acesta foloseşte apoi informaŃia pentru
a compila funcŃii. Administrarea unui număr mai mic de obiecte duce la creşterea
performanŃelor rulării dacă implementarea s-a făcut corect.
• Şabloane asociate
Printre şabloanele asociate se află:
- Abstract Factory - acest şablon este folosit pentru a se asigura o distribuire
corectă a instanŃelor Flyweight
- Composite - este de regulă folosit pentru a pune la dispoziŃie structura
- State - este implementat de regulă folosind şablonul Flyweight
- Strategy - este un alt şablon care poate beneficia de pe urma implementării
lui ca un Flyweight
• Exemplu
Un exemplu al şablonului Flyweight este crearea a 1000 de cercuri folosind 6
culori, ce conŃine obiectul Circle care poate fi reutilizat:
class Circle {
private Color color; public
Circle(Color color) {
this.color = color;
public void draw (Graphics g, inc x, irit y, irit r) {
g.setColor(color); g.drawOva1(x, y, r, r);
78

dss lest extends JFra.te;
private static final Coicr ^ -_■". !■ r .■= L J = i Celor, red,
Color.blue, Color . ye-llcv:, Color . orange , Color.black,
Color.whice i; private s':ati.c final int WIDTH = 400,
HEIGHT = 400,
NUMRER_OF_CIRCLES = 1000;
public Tes;() {
Container contentPane = gotConteniPane();
JButton button = new J But tor: ( "Draw Circle"!;
final JPane.l panel = nev; JPanel ( ) ;
contentPane.add(panel, Borderlayout.CENTER);
contentFane.add(button, BorderLayout.SOUTH);
setSize(WIDTH ,HEIGHT);
ser Defau.1 tClcseOperation ( JFrane . EXIT _ON_CLOSE ) ;
setVisibie(true);
button.addActionListener(nev; ActionLisrener() {
public veid act ionPerf or.T.ed (ActionEvent event) {
Graphics g = panel.getGraphics(); for (int i = 0;
i < NUM3ER_OF_CIRCLES; + + i) { Circle circle = new
Circle(getRandomCclor());
circle . draw ( g, getRandorr.X ( ) ,
ge~RandomY(), getRandomR());
i /
private int getRandonX{; {
return (irit) (Math . random Ń ) *WIDTH ) ; }
private int getRandomY() {
return (int)(Math.random()*HEIGKT); }
private int getRandomR() {
return (int) (Math. random () "" (HEIGHT/10) ) ;
private Color getRandomCo]or() {
return colors[ ( int) (Math.random()*colors.length) }
public static void main(String[] args) {
Test test = new Test();
IV.7. Half-Object Plus Protocol (HOPP)
• ProprietăŃi
• Scop
- Tip: structural
- Nivel: componentă
Să pună la dispoziŃie o singură entitate care să trăiască în doua sau mai multe
spaŃii de adresă.
79

• Introducere
O aplicaŃie Java poate împrăştia obiecte către diferite spaŃii de adresă - maşini
virtuale Java multiple. Pentru unele tehnologii cum ar fi RMI. obiectele la distanŃă pot
apela metode în legătură cu obiecte care se află într-o altă maşină virtuală Java.
permiŃând distribuirea stării şi comportamentului. Indiferent de tehnologia folosită,
obiectele din diferitele maşini virtuale Java trebuie să comunice între ele pentru ca o
aplicaŃie distribuită să poată funcŃiona. Dacă nu se realizează acest lucru, apare un
eşec în comunicare.
Presupunem că există maşinile A şi B, fiecare cu o maşină virtuală Java care
rulează. Un obiect din maşina A are nevoie ca un obiect din maşina B să apeleze
metode asupra unui obiect din maşina virtuală Java B. Acest lucru se poate realiza
prin mai multe mijloace. Maşina A poate apela metode ale căror apeluri vor fi trimise
către maşina B
Dezavantajul este că toate apelurile de metode vor fi trimise de-a lungul
reŃelei, lucru nedorit. De multe ori se doreşte ca unele metode invocate să se execute
local, fără a se merge la obiectul de la distanŃă.
Proxy-ul - reprezentarea locală a unui obiect la distanŃă - este considerat ca
tăcând parte din obiectul la distanŃă. Executând metodele local şi în cadrul maşinii
virtuale Java la distanŃă, un obiect exercită comportament în multiple spaŃii de adresă.
Şablonul HOPP realizează acest lucru.
• Utilizare
Şablonul HOPP se foloseşte când:
- un obiect trebuie să fie în două spaŃii de adresă diferite şi nu poate fi împărŃit
- o parte a funcŃionalităŃii trebuie executată la distanŃă dar unele metode sunt
apelate local
- optimizări trebuie efectuate printr-o modalitate transparentă apelantului
• Descriere
AplicaŃiile distribuite sunt greu de scris. Una din problemele întâlnite este
aceea că o singură entitate (obiect) trebuie să se afle în mai multe spaŃii de adresă, fie
pentru că trebuie să acceseze multiple dispozitive fizice aflate pe maşini diferite, fie
pentru că un obiect nu poate fi împărŃit logic.
Pentru a diviza un obiect în două părŃi care să comunice apoi la distanŃă, se
execută rmic împreună cu opŃiunea keepgenerated. Astfel se salvează codul sursă.
Apoi. se editează sursa încât anumite metode să nu fie trimise către obiectul la
distanŃă. Din păcate, se limitează folosirea ulterioara a rmic-ului, deoarece de fiecare
dată când acesta se utilizează asupra obiectului la distanŃă, trebuie făcută şi editarea
manuală.
SoluŃia este de a împărŃi obiectul în două şi a pune la dispoziŃie o cale de
comunicare între cele două jumătăŃi. Se implementează fiecare parte astfel încât să
interacŃioneze cu obiectul aflat în spaŃiul său de adresă. Protocolul este responsabil
pentru sincronizarea celor două jumătăŃi şi trimiterea informaŃiilor înainte şi înapoi.
Aceasta se realizează prin intermediul şablonului HOPP - se creează un obiect
care implementează interfaŃa necesară şi care conŃine o referinŃă către obiectul la
distantă.
80

Client
■ Implementare
Diagrama de clase a şablonului MOPP este următoarea:
interfacc HOPP
+void remo1eMelhod()
+void local MethodQ
LocalHOPP
+void remoteMethodQ
+void localMethodQ
RemoteObjeetProxy
+void remoteMethod()
+void localMethod()
RemoteObjeet
+void remoteMethod()
+void localMethod()
Acest obiect există
într-un spaŃiu de
adresă diferit
Pentru implementarea şablonului HOPP este nevoie de:
- HOBB - interfaŃa care defineşte metodele valabile clientului. Ambele părŃi
ale obiectului HOPP implementează această interfaŃă
- LocalHOPP - clasa care implementează interfaŃa HOPP. Unele metode sunt
executate local. în timp ce altele sunt trimise către RemoteObjeetProxy
- RemoteObjeetProxy - această clasă este un Proxy la distanŃă care trimite
toate cererile către cealaltă parte a obiectului aflat în celălalt spaŃiu de adresă. Acest
proxy încapsulează protocolul care leagă cele două jumătăŃi ale obiectului
- RemoteObjeet - această jumătate a obiectului HOPP conŃine toate metodele
ce vor fi executate la distanŃă
- Client - clasa care apelează metodele interfeŃei HOPP. Aceste apeluri ale
metodelor sunt transparente clientului, indiferent dacă se foloseşte un Proxy la
distanŃă, un HOPP sau un obiect local
• Beneficii şi inconveniente
Beneficiul acestui şablon este acela că permite ca un obiect să ocupe două
spaŃii de adresă. Pentru clienŃii care folosesc o parte a obiectului HOPP. el este
transparent. ClienŃilor nu le pasă dacă un obiect se află în unul sau mai multe spaŃii de
adresă.
Este posibilă şi ascunderea completă a diferenŃelor. încât un client să creadă că
foloseşte un obiect local, în timp ce părŃi ale acestuia se află la distanŃă. Se poate
implementa şi partea opusă astfel încât un client să creadă că foloseşte un Proxy la
distanŃă, când de fapt foloseşte un HOPP care conŃine un Proxy la distantă.
81

Un alt mare avantaj este că acest şablon permite optimizări. Fiecare parte a
obiectului HOPP poate determina când şi cum doreşte să comunice cu cealaltă parte.
Aceste strategii de comunicare duc la creşterea performanŃei prin scăderea numărului
de apeluri de-a lungul reŃelei, tară a afecta codul clientului.
Inconvenientul acestui şablon este acela că o parte a funcŃionalităŃii trebuie
duplicată. Acest lucru este necesar deoarece fiecare jumătate a obiectului trebuie să
aibă suficientă funcŃionalitate ca să poată administra obiectele locale.
• Variante ale şablonului
Ambele jumătăŃi păstrează o referinŃă una către cealaltă şi trimit mesaje înainte
şi înapoi. în forma clasică, doar jumătatea aflată de parte clientului are o referinŃă
către cealaltă. ConsecinŃa este că se poate iniŃia comunicarea doar de către jumătatea
aflată de partea clientului prin apelarea unei metode a jumătăŃii aflate la distanŃă.
Aceasta din urmă poate răspunde doar o dată la fiecare apel prin intermediul valorii pe
care o returnează. Atunci când este necesar ca ambele părŃi să iniŃieze comunicarea,
fiecare trebuie să conŃine o referinŃă către cealaltă.
O altă varianta este SHOPP - Smart HOPP. In cadrul acestei implementări,
partea locală a obiectului HOPP îşi poate alege duplicatul pe baza unor strategii de
conectare. Aceasta este de ajutor când. de exemplu, aplicaŃia este distribuită de-a
lungul unei reŃele flexibile unde maşinile vin şi pleacă.
In versiunea Asymmetric HOPP, cele doua jumătăŃi nu trebuie să
implementeze neapărat aceeaşi interfaŃă. Partea la distanŃă poate pune la dispoziŃie un
nou proxy pe care cealaltă parte să-1 folosească. Noul proxy poate conŃine optimizări
sau poate fi un proxy pentru un obiect la distanŃă diferit.
• Şabloane asociate
Printre şabloanele asociate se află:
- Mediator - obiectele ce trebuie mediate sunt distribuite către multiple spaŃii
de adresă. Mediator-ul poate folosi şablonul HOPP pentru a uşura comunicarea
- Proxy - şablonul HOPP foloseşte şablonul Proxy pentru comunicarea
transparentă între cele două jumătăŃi
• Exemplu
Considerându-se un calendar, acesta se păstrează într-un singur loc dar trebuie
să fie disponibil oriunde. Pentru aceasta este nevoie de o interfaŃă Calendar care să
descrie metodele disponibile la distanŃă, de o clasă Calendarlmpl ce conŃine
implementările metodelor la distanŃă şi de o clasă CalendarHopp care să poată rula
local ceea ce în mod normal ar fi metode la distanŃă:
public class CalendarHO?? implements Calendar, java.io.Serializable {
private static final String PROTOCOL = "rmi://"; private static
final String REMOTE_SERVICE = "/calenaarimpl"; private staric
final String HOPP_SERVICE = "calendar"; private static final
Striric private Calendar calendar; private String host; public
CalendarHOPP() {
t h i s(DE FAULT HOS L) ;
82

public CalendarHOPF(String host) {
t r v {
this.host - nost;
String uri = PROTOCOL ^ host I REMOTE SERVICE;
calendar = (Calendar)Naming.lookup(uri);
Kaming.rebind(HOPP_SERVICE, triis);
catcn (Exception exc) {
System.err.println("Erroare !" - exc);
}
oublic String getHost() { return host; ;
pudic ArrayList getAppointrrients (Date date) throws
RemoteException { Return
calendar.getAppointnents(date);
public void addAppcintment(Appointment appointment, Date date
throws Rem.oteException {
calendar.addAppointment(appointment, date);
IV.8. Proxy
• Cunoscut şi ca Surrogate
• ProprietăŃi
• Scop
- Tip: structural
- Nivel: componentă
Să pună la dispoziŃie o reprezentare a unui alt obiect, pe motive de acces,
viteză sau securitate.
• Introducere
Pe măsură ce managerul personal de informaŃii se dezvoltă, el trebuie să
administreze din ce în ce mai multe date. El conŃine adresele a numeroase persoane,
inclusiv informaŃii despre familiile acestora, hobby-uri. etc. La început numărul
contactelor a fost mic, dar acum a ajuns de ordinul miilor.
De multe ori. managerul de informaŃii este folosit doar pentru a schimba
detaliile unei întâlniri sau pentru introducerea unei note. Prin urmare, vizualizarea
cărŃii de adrese de fiecare dată când se utilizează managerul, devine inutilă şi
enervantă. Doar deschiderea acesteia este o operaŃie costisitoare care duce la
amânarea activităŃilor care nu necesită utilizarea ei.
Pe un utilizator însă nu îl interesează acest fapt - el vrea doar să aibă la
dispoziŃie cartea de adrese atunci când are nevoie de ea. Dar atunci când o foloseşte,
nu are mereu nevoie de toate informaŃiile din ea. De exemplu, se doreşte doar
cunoaşterea numărului total de contacte sau adăugarea unuia nou, fără a fi necesară
observarea sau editarea întregii cărŃi de adrese.
83

SoluŃia este un obiect placeholder care să pună la dispoziŃie o interfaŃă cu
cartea de adrese sau cu o parte a acesteia. Acest obiect arată asemănător cu cartea de
adrese, dar nu implică şi rularea acesteia. Totuşi, când este nevoie ca întreaga carte de
adrese să efectueze o sarcină cum ar fi modificarea adresei unui coleg, obiectul
placeholder creează adevărata carte de adrese pentru a efectua sarcina respectivă.
Acest obiect placeholder este un Proxy.
■ Utilizare
- Remote Proxy (proxy la distanŃă) - se foloseşte atunci când se doreşte o
reprezentare locală pentru un obiect într-un alt spaŃiu de adresă
- Virtual Proxy (proxy virtual) - amână crearea obiectelor costisitoare
- Protection Proxy (proxy de protecŃie) - determină drepturile de acces la
obiectul real
• Descriere
Un proxy este o reprezentare pentru un alt obiect. Pentru a putea face capabil
proxy-ul să reprezinte obiectul real, el trebuie să implementeze aceeaşi interfaŃă ca şi
obiectul real. Mai mult. proxy-ul păstrează o referinŃă către obiectul real. referinŃă de
care are nevoie pentru a apela metode asupra obiectului real atunci când este necesar.
ClienŃii vor interacŃiona cu proxy-ul. dar acesta poate delega executarea către obiectul
real. Cu toate că implementează aceeaşi interfaŃă ca şi obiectul real, proxy-ul poate
efectua sarcini pe care obiectul real nu le poate face. cum ar fi comunicarea la distanŃă
sau securitatea.
Proxy-ul este un fel de suplinitor pentru obiectul real. El poate fi comparat cu
sistemul de filmare a cascadoriilor periculoase pentru un film. Proxy-ul este dublura
obiectului real - starul filmului. în timpul cascadoriei periculoase, proxy-ul este cel
care sare din avion în locul obiectului real. Deoarece implementează aceeaşi interfaŃa
ca şi obiectul real. audienŃa nu poate face diferenŃa şi crede ca obiectul real este cel
care a sărit. Dar atunci când camera se apropie, proxy-ul apelează obiectul real care
preia efectuarea acŃiunii.
• Implementare
Diagrama de clase a şablonului Proxy este următoarea:
interface Service
ServiceProxv Servicelmpl
84

Pentru implementarea şablonului Proxy se folosesc următoarele:
- Service - interfaŃa folosită atât de proxy. cât şi de obiectul real
- ServiceProxy - clasa ce implementează interfaŃa Service şi trimite apelurile
metodelor către obiectul real - Servicelmpl - atunci când este cazul
- Servicelmpl - implementarea completă şi reală a interfeŃei. Acesta este
obiectul reprezentat de proxy.
• Beneficii şi inconveniente
ConsecinŃele acestui şablon variază considerabil în funcŃie de tipul specific de
proxy folosit. Beneficiul proxy-ul la distanŃă este acela că se poate ascunde reŃeaua de
client. Clientul va crede că un obiect local efectuează munca, când de fapt acesta
trimite o cerere prin reŃea pentru a se efectua acŃiunea respectivă. Inconvenientul ar fi
timpul mai lung de realizare a cerinŃelor, având în vedere comportamentul reŃelei.
Marele beneficiu al proxy-ul virtual este acela că se interacŃionează cu el, fără
a crea obiectul real înainte de a avea nevoie de el. In plus, el poate efectua unele
optimizări în ceea ce priveşte când şi cum să creeze obiectul real.
Beneficiul proxy-ul de protecŃie este acela că permite controlul accesului.
• Variante ale şablonului
O variantă a acestui şablon este atunci când proxy-ul nu trebuie să cunoască
obiectul real decât prin intermediul interfeŃei. Creşte astfel flexibilitatea, dar acest
lucru funcŃionează doar dacă proxy-ul nu este responsabil pentru crearea şi/sau
distrugerea obiectului real.
• Şabloane asociate
Printre şabloanele asociate se află:
- Adapter - pune la dispoziŃie o interfaŃă către un obiect specific, aşa cum face
şi şablonul Proxy. Totuşi, Proxy-ul are aceeaşi interfaŃă ca şi obiectul. în timp ce
Adapter-ul are o interfaŃă diferită
- HOPP - poate folosi şablonul Proxy pentru comunicarea între două jumătăŃi
distribuite ale lui
- Business Delegate - acest şablon poate fi folosit ca un proxy
• Exemplu
Atunci când se încarcă o imagine mare, se doreşte crearea unor obiecte
luminoase până când imaginea a fost încărcată complet. Pentru aceasta se poate utiliza
şablonul Proxy:
abstract class Graphic {
public abstract voia load();
public abstract void draw();
85

la.ss Jmage extends Graphic{
public voici l o a d ( ) ■ /
public void draw() { /,
lass InaFroxy extends Graphic {
public void ]oadŃ) {
if (irr.age -- nuli) {
irr.age = r:cw Image ( f iî ename
puoli.c void draw() { //...
86

V. Concluzii
Şabloanele ajută la dezvoltarea proiectelor software complexe, recurgându-se
de foarte multe ori la soluŃii aplicate în trecut. Fiecare şablon se ocupă cu o problemă
de design sau o implementare a unui sistem software specifică. Şabloanele pot fi
folosite pentru construirea de arhitecturi software având anumite proprietăŃi.
Programarea orientată pe obiecte este grea; programarea pe obiecte folosind cod
reutilizabil este şi mai grea. Utilizatorii experimentaŃi realizează totuşi un design
foarte bun şi asta pentru că ştiu faptul că nu mereu trebuie rezolvate problemele de la
început. Ei reutilizează soluŃii obŃiinute anterior, şabloanele ajutând astfel la crearea
unui design de software flexibil, uşor de întreŃinut şi de reutilizat.
90

Bibliografie
1. Stelting Stephen, Maassen Olav - Applied Java Patterns
2. Cooper James W. - The Design Patterns Java Companion
3. www.javacamp.org
4. www.dofactory.com
5. www.wikipedia.org
91