Creational Patterns sunt pattern-uri ce implementeaza mecanisme de creare a obiectelor.

In aceasta
categorie se incadreaza pattern-urile Singleton si Factory.
Structural Patterns sunt pattern-uri ce simplifica design-ul aplicatiei prin gasirea unei metode de a defini
relatiile dintre entitati. In aceasta categorie se incadreaza pattern-ul Decorator.
Behavioral Patterns sunt pattern-uri ce definesc modul in care obiectele comunica intre ele. In aceasta
categorie se incadreaza pattern-urile Command, Visitor si Observer.

1. Design Pattern-ul Command:

incapsuleaz o cerere sub forma unui obiect;

permite parametrizarea clienilor cu cereri diferite;

permite memorarea cererilor intr-o coada;

suporta operatii reversibile (undoable operations)

acesta este Behavioral pentru ca modific interaciunea dintre componente, mai exact felul n care
se efectueaz apelurile.
Structura

Ideea principala este de a crea un obiect de tip Command care va retine parametrii pentru comanda.
Comandantul retine o referinta la comanda si nu la comandat. Comanda propriu-zisa este anuntata
obiectului comanda (de catre comandant) prin executia unei metode specificate asupra lui.
Obiectul Command este apoi responsabil de trimiterea (dispatch) a comenzii la obiectele care o
indeplinesc (comandati).
Tipuri de componente (roluri):

Invoker - comandantul

apeleaz aciuni pe comenzi

poate menine, dac e cazul, o list a tutoror comenzilor aplicate pe obiectul (obiectele)
comandate. Este necesar reinerea acestei liste de comenzi atunci cnd implementm un
comportament de undo/redo al comenzilor.

primete clase Command pe care s le invoce

Receiver - comandatul

este clasa asupra creia se face apelul

conine implementarea efectiv a ceea ce se dore te executat

Command - obiectele pentru reprezentarea comenzilor implementeaz aceast interfa /o extind
dac este clas abstract

concrete command - ne referim la implementri/subclasele acesteia

de obicei conin metode cu nume sugestiv pentru executarea ac iunii comenzii

(e.g. execute()). Implementrile acestora conin apelul ctre clasa \textit{Receiver}.

n cazul implementrii unor aciuni undoable adugm metode pentru undo i/sau redo.

in referine ctre comandai (receivers) pentru a aplica/invoca ac iunea ce reprezint acea

comand
n Java, se pot folosi att interfee ct i clase abstracte, pentru Command, depinznd de situa ie (e.g.
clas abstract dac tim sigur ca obiectele de tip Command nu mai extind i alte clase).

2. Design Pattern-ul Singleton:

Pattern-ul Singleton este utilizat pentru a restrictiona numarul de instantieri ale unei clase la un
singur obiect, deci reprezint o metod de a folosi o singur instan a unui obiect n aplica ie.

Pattern-ul Singleton este in general utilizat in urmatoarele cazuri:

subansamblu al altor pattern-uri:

impreun cu pattern-urile Abstract Factory, Builder, Prototype etc.

obiectele care reprezint stri

n locul variabilelor globale. Singleton este preferat variabilelor globale deoarece, printre
altele, nu polueaz namespace-ul global cu variabile care nu sunt necesare.
Din punct de vedere al design-ului i testarii unei aplicaii de multe ori se evit folosirea acestui
pattern. De exemplu dac avem nevoie sa meninem o referin ctre un obiect n mai multe clase,
putem sa l facem Singleton i s obinem acel obiect n fiecare component n care avem nevoie de
el sau ca sa facem codul mai curat i cu un flow mai uor de urmrit, s l instaniem doar ntr-un
singur loc i s l transmitem ca argument.

Implementare
Aplicarea pattern-ului Singleton const n aplicarea unei metode ce permite crearea unei noi instan e
a clasei dac aceasta nu exista deja. Daca instana exist deja, atunci ntoarce o referin ctre acel
obiect. Pentru a asigura o singur instaniere a clasei, constructorul trebuie s fie private, iar instana
s fie oferit printr-o metod static, public.

3. Design Pattern-ul Adapter:

Scop
convertete interfata unei clase la interfata pe care clientii acesteia o ateapt.
permite inter-operabilitatea claselor care altfel
nu ar fi compatibile
Motivatie
O clasdintr-o bibliotec, proiectat s fie reutilizabil , nu este reutilizabil din simplul motiv c
interfata acesteia nu se
potrivete cu una specific domeniului n care se dorete utilizat.
Aplicabilitate

 Se dorete utilizarea unei clase cu o interfata incompatibil

Se dorete crearea unei clase reutilizabile ce colaboreaz cu clase neprevzute
(adaptor de obiecte) Se dorete folosirea a ctorva subclase, dar adaptarea prin derivare este
nepractic.

4. Design Pattern-ul Composite:

La asta nu am gasit nimic

5. Design Pattern-ul Factory:

Patternul Factory face parte din categoria Creational Patterns si ca atare rezolva problema crearii
unui obiect fara a specifica exact clasa obiectului ce urmeaza a fi creat. Acest lucru este implementat prin
definirea unei metode al carei scop este crearea obiectelor. Metoda va avea specificat ca parametru de
intors in antet un obiect de tip parinte, urmand ca, in functie de alegerea programatorului, aceasta sa
creeze si sa intoarca obiecte noi de tip copil.

Factory Method Pattern

Folosind pattern-ul Factory Method se poate defini o interfa pentru crearea unui obiect, ns ce
obiecte este instaiat este dat de ctre subclase.
Spre deosebire de Abstract Factory, Factory Method ascunde construc ia unui obiect, nu a unei
familii de obiecte inrudite, care extind un anumit tip. Clasele care implementeaz Abstract Factory
conin de obicei mai multe metode factory.

6. Design Pattern-ul Obeserver:

Design Pattern-ul Observer definete o relaie de dependen 1..* ntre obiecte astfel nct cnd un
obiect i schimb starea, toi dependenii lui sunt notificai i actualizai automat. Folosirea acestui
pattern implic existena unui obiect cu rolul de subiect, care are asociat o list de obiecte
dependente, cu rolul deobservatori, pe care le apeleaz automat de fiecare dat cnd se ntmpl o
aciune.
Acest pattern este de tip Behavioral (comportamental), deorece faciliteaz o organizare mai bun a
comunicaiei dintre clase n funcie de rolurile/comportamentul acestora.
Observer se folosete n cazul n care mai multe clase(observatori) depind de comportamentul unei
alte clase(subiect), n situaii de tipul:

o clas implementeaz/reprezint logica, componenta de baz, iar alte clase doar folosesc
rezultate ale acesteia (monitorizare).

o clas efectueaz aciuni care apoi pot fi reprezentate n mai multe feluri de ctre alte clase

(view-uri ca n figur de mai jos).

Practic n toate aceste situaii clasele Observer observ modificrile/aciunile clasei Subject.
Observarea se implementeaz prin notificri iniiate din metodele clasei Subject.

7. Design Pattern-ul Proxy:

Scop
Ofer un surogat sau nlocuitor pentru un obiect, prin care se controleaz accesul la acel obiect.
Motivatie
Creare/initializare la cerere a obiectelor
Aplicabilitate
Substitut pentru deprtat, ambasador
Substitut virtual
Substitut protector
Referint deteapt
Indicator detept
ncrcarea unui obiect persistent la prima accesare
Asigurearea exculderii mutual
Tipuri de obiecte proxy:
Cache Proxy: salveaz resurse memornd
rezultate temporare
Count Proxy: face i alte operatii nainte/dup apelarea subiectului real
Protection Proxy: controleaz accesul la obiectul

real
Remote Proxy: reprezentant local al unui obiect
aflat la o alt adres
Virtual Proxy: creeaz obiecte la cerere (cnd
este nevoie de ele)