• Sablonul Factory: o clasă simplă pentru luarea unei decizii-

întoarce una din mai multe subclase posibile ale unei clase, în
funcţie de datele pe care le primeşte.

Scop
• Defineşte o interfaţă pentru crearea unui obiect, dar lasă
subclasele să decidă ce clasă să instanţieze.
• Metoda Factory permite unei clase să defere instanţierea
subclaselor. Mai este cunoscut şi ca Constructor Virtual

• Aplicabilitate
• O clasă nu poate anticipa clasa obiectelor pe care trebuie
să le creeze
• O clasă doreşte ca subclasele sale să specifice obiectele
pe care le creează
• Clasele delegă responsibilitatea uneia sau mai multor
subclase ajutătoare

1 edited by gl 53 ban
 Structura

Consecinte
• Elimină legarea între clasele specifice aplicaţiei din cod
• codul de creare foloseşte doar interfaţa clasei Product
• Facilitează derivarea
• subclasele pot astfel modifica produsul creat
• Poate conecta ierarhii paralele de clase
• lasă clienţii să apeleze FM
Sablonul Abstract Factory: o interfaţă pentru crearea şi
returnarea uneia dintre mai multe familii de obiecte relaţionate
Scop
• Oferă o interfaţă pentru crearea de familii de obiecte
familii de obiecte înrudite sau dependente fără
specificarea claselor lor concrete
Aplicabilitate
• Sistemul trebuie să fie independent de cum sunt create,
compuse şi reprezentate produsele sale
• Sistemul trebuie configurat de una din mai multe familii de
produse

2 edited by gl 53 ban
 • Trebuie forţat ca o familie de obiecte produs să fie
folosite împreună
Structura

Consecinte
• Izolarea claselor concrete
 apar în ConcreteFactories nu în codul clientului
 Facilitează schimbul de familii de produse
 un ConcreteFactory apare într-un singur loc
• uşor de modificat
 Promovează consistenţa între produse
 toate produsele unei familii se modifică împreună, în
acelaşi timp
• Este dificilă susţinerea de tipuri noi de produse
 necesită o modificare în interfaţa AbstractFactory

3 edited by gl 53 ban
  ... şi a tuturor subclaselor sale, în consecinţă
Exemplu
abstract class WidgetFactory {
public Window createWindow();
public Menu createMenu();
public Button createButton();
}
class MacWidgetFactory extends WidgetFactory
{
public Window createWindow()
{ return new MacWidow() }
public Menu createMenu()
{ return new MacMenu() }
public Button createButton()
{ return new MacButton() }
}

Sablonul Prototype: începe cu o clasă instanţiată şi alizată şi

o copiază/ clonează pentru a crea instanţe noi (în loc să creeze
efectiv alte instanţe)
Scop
• Specificaţi tipul obiectelor care se creează folosind o
instanţă prototipică
• Creaţi obiecte noi copiind acest prototip
Aplicabilitate
• când un sistem trebuie să fie independent de cum sunt
create, compuse şi reprezentate produsele sale şi
• când clasele de instanţiat sunt specificate la execuţie
• evitaţi construirea unei ierarhii de clase-factory paralelă cu
ierarhia claselor de produse

4 edited by gl 53 ban
Consecinte
• Adăugarea şi ştergerea produselor la execuţie
• Mai puţină derivare
 evită ierarhia paralelă pentru creatori
• Specificarea de obiecte noi prin varierea valorilor
prototipurilor
 clientul se comportă diferit prin delegarea către
prototip
• Specificarea de obiecte noi prin varierea structurii
prototipurilor
 produse compuse
• Fiecare subclasă a Prototype trebuie să implementeze
clone
 dificil când clasele există deja sau
 obiectele interne nu permit copierea sau au referinţe
circulare
Exemplu:
class Prototype {
public Prototype clone() {
// code to make a copy of current
Prototype object
return clone;
}
// add what ever else you want the class
to do
}
class ProtoExtension extends Prototype {
public Prototype clone() {
// code to make a copy of current
Protoplasm object
return clone;
} // add more other stuff }

5 edited by gl 53 ban
 ClientCodeMethod( Prototype example ) {
Prototype myCopy = example.clone();
// do some work using myCopy
}
Sablonul Singleton:
Este o clasă din care nu poate exista mai mult de o instanţă;
furnizează un punct de acces global la această instanţă
Scop
• Asigură ca o clasă să aibă doar o singură instanţă şi
furnizează un punct de acces global la ea
Aplicabilitate
• dorim exact o instanţă a unei clase
• accesibilitate pentru clienţi dintr-un singur punct
• dorim ca instanţa să fie extensibilă
 poate permite deasemenea şi un set numărabil de instanţe
• optimizare faţă de vizibilitatea globală
• mai bine decât o clasă statică:
• nu se poate răzgândi
• metode niciodată virtuale
Structura

6 edited by gl 53 ban
 Consecinte
• Acces controlat la instanţa unică
• Permite rafinarea operaţiilor şi reprezentării
• Permite un număr variabil (dar precis) de instanţe
• Reducerea vizibilităţii globale

Sablonul Command
Scop
 Încapsulează cereri ca obiecte, şi permite:
• parametrizarea clienţilor cu diferite cereri
• înlănţuirea sau log-area cererilor
• suport pentru operaţii anulabile (UNDO)
Aplicabilitate
 Parametrizarea obiectelor
 Specificarea, înlănţuirea, şi executarea cererilor la diferite
momente
 Suport undo
 Modelarea tranzacţiilor
• structurarea sistemelor construite pe operaţii
primitive, în jurul operaţiilor de nivel înalt
interfaţa comună  invocarea identică a tuturor tranzacţiilor
Sablonul
public interface Command {
public void Execute();
}
• Scop- reducerea actionPerformed la:
public void actionPerformed(ActionEvent e) {
Command cmd = (Command)e.getSource();
cmd.Execute();
}

7 edited by gl 53 ban
Exwmplu
abstract class Command {
abstract public void execute();
}
class OpenCommand extends Command {
private Application opener;
public OpenCommand(Application theOpener) {
opener = theOpener;
}
public void execute() {
String documentName = AskUserSomeHow();
if(name != null) {
Document toOpen = new Document(
documentName );
opener.add( toOpen );
opener.open();
}
}
}
class Menu {
private Hashtable menuActions = new
Hashtable();
public void addMenuItem( String displayString,
Command itemAction )
{
menuActions.put (displayString, itemAction);
}
public void handleEvent( String itemSelected )
{
Command runMe;
runMe = (Command) menuActions.get(
itemSelected );
runMe.execute();
}
}

8 edited by gl 53 ban
Sablonul Composite
Scop
 Tratează obiectele individuale şi compunerile acestor
obiecte uniform
 Compune obiectele în structuri arborescente pentru a
reprezenta agregări recursive

Aplicabilitate
 reprezentarea ierarhiilor de obiecte de tip parte-întreg
 abilitatea de a ignora diferenţa dintre compuneri de
obiecte şi obiecte individuale

Consecinte
• Defineşte ierarhii uniforme de clase
 compunere recursivă de obiecte
• Face clienţii simpli
 nu trebuie să ştie dacă este o frunză sau un compus
 simplifică codul deoarece evită tratarea diferită a fiecărei
clase
 Mai uşor de extins
 uşor de adăugat noi clase Composite sau Leave
 aplicaţie fericită a Principiului Deschis-Închis
• Design prea general
 sunt necesare verificări de tip pentru a restricţiona tipurile
admise într-o anumită structură compusă

9 edited by gl 53 ban
Exemplu
class Window {
GUIWidgets[] myWidgets;
WidgetContainer[] myContainers;

public void update() {

if(myWidgets != null)
for (int k = 0; k < myWidgets.length();
k++)
myWidgets[k].update();
if(myContainers != null)
for (int k = 0; k <
myContainers.length(); k++)
myContainers[k].updateElements();
// .. .. etc.
}
}

Sablonul Strategy
Scop
 Defineşte o familie de algoritmi, încapsulează fiecare
algoritm, îi face interschimbabili
 Permite algoritmului să varieze independent de clienţii
ce îl folosesc
Aplicabilitate
 Sunt necesare variante diferite ale unui algoritm
 Un algoritm foloseşte date despre care clienţii nu
trebuie să ştie
 evită expunerea structurilor de date complexe,
specifice algoritmului
 Multe clase relaţionate diferă doar prin comportament
 configurează o clasă cu un comportament
particular
10 edited by gl 53 ban
Structura

Participanti
 Strategy
 declară o interfaţă comună tuturor algoritmilor.
 Context foloseşte această interfaţă pentru a apela
algoritmul definit de o clasă ConcreteStrategy
 ConcreteStrategy
 implementează algoritmul folosind interfaţa Strategy
 Context
 configurat cu un obiect ConcreteStrategy
 poate defini o interfaţă ce permite obiectelor Strategy
să îi acceseze datele
Sablonul State
Scop
 permite unui obiect să îşi modifice comportamentul
când i se modifică starea internă
 obiectul va părea că îşi schimbă clasa
Aplicabilitate
 comportamentul obiectului depinde de starea sa

11 edited by gl 53 ban
  trebuie să îşi modifice comportamentul la execuţie în
funcţie de stare
 operaţii cu instrucţiuni condiţionale multiple, depinzând
de starea obiectului
- starea reprezentată de una sau mai multe constante enumerate
- mai multe operaţii cu aceeaşi structură condiţională
Structura

Decorator
• Modificarea comportamentului obiectelor individuale fără să
creeze o clasă derivată nouă
• Acesta este un alt caz în care este favorizată relaţia de
conţinere asupra moştenirii
• Decoratorul este un obiect grafic, dar conţine obiectul pe
care îl decorează
– Poate apela metode grafice, poate executa calcule
adiţionale, şi le poate trimite către obiectul conţinut şi
decorat
public Decorator(JComponent c) {
setLayout(new BorderLayout());
//adaugă componenta la container
add("Center", c);}
}

12 edited by gl 53 ban
Principiul deschis-închis (PDI)
“Entităţile software trebuie să fie deschise la extinderi, dar
închise la modificări”, citat de R.Martin
- Deschidere la extinderi
 Comportamentul modulului poate fi extins
- Închidere la modificări
 Codul sursă al modulului nu trebuie modificat
- Modulele trebuie scrise astfel încât să poată să fie extinse fără
să fie modificate
“Nici un program semnificativ nu poate fi 100% închis. R.
Martin, “Principiul Deschis- Inchis”, 1996
- Închidere strategică, nu completă
- Închiderea se obţine prin utilizarea abstractizării
- Construiţi metode ce pot fi invocate dinamic
• Pentru a determina deciziile strategiei generale
• Ex. Desenare de pătrate înainte de cercuri
- Utilizaţi o abordare “condusă de date” pentru a obţine închiderea
- Plasaţi deciziile strategiei particulare într-o locaţie separată
• Ex. Fişier sau obiect separat
- Minimizează localizările schimbărilor viitoare

Euristici PDI
• Modificările datelor publice aduc un risc de “deschidere” a
modulului
– Pot provoca un efect de modificări în cascadă, în mai
multe locaţii neaşteptate;
– Erorile pot fi dificil de corectat/ de găsit în totalitate
• Corecturile pot introduce erori în alte părţi
• Membrii non-privaţi sunt modificabili
– Pot schimba starea clasei

13 edited by gl 53 ban
Principiul Substituţiei (Liskov)- PSL
Prin moştenire, orice proprietate adevărată despre obiectele
supertipului trebuie să rămână adevărată despre obiectele
subtipului. B.Liskov, 1987
Funcţiile ce folosesc pointeri/ referinţe la clasele de bază
trebuie să poată folosi obiecte ale claselor derivate fără să
ştie aceasta. R.Martin, 1996

PSL- Euristici
Este ilegal ca o clasă derivată să suprascrie o metodă a clasei
de bază printr-o metodă NOP
• NOP (no-operation): o metodă care nu face nimic
• Soluţia 1: relaţie de derivare inversă
– Dacă în clasa de bază iniţială există doar
comportament adiţional
• Ex. Căţel- căţel_care_nu_se_mişcă
• Soluţia 2: extragerea unei clase de bază comune
– Dacă atât clasa iniţială cât şi clasele derivate au
comportamente diferite
– Pentru Pinguini: Păsări, PăsăriZburătoare, Pinguini
• Clase cu o stare defectă:
– Ex. Căţei stupizi sau paralizaţi

Principiul Inversării Dependenţelor (PID)

I. Modulele de nivel-înalt nu trebuie să depindă de modulele
de nivel scăzut. Ambele trebuie să depindă de
abstracţiuni.
II. Abstracţiunile nu trebuie să depindă de detalii. Detaliile
trebuie să depindă de abstracţiuni.

14 edited by gl 53 ban
 III. O clasă de bază într-o ierarhie nu trebuie să îşi ştie
subclasele
IV. Modulele cu implementări detaliate depind de abstracţiuni,
şi nimic nu depinde de ele
V. PDI= Scopul, PID= mecanismul
VI. PSL= asigurarea pentru PID

Euristici PID
Proiectaţi centrat pe interfeţe,nu pe implementare
Utilizaţi moştenirea pentru a evita legarea directă de clase:

Principii fundamentale
• Cele trei principii sunt strâns relaţionate
• Încălcarea PSL sau PID duce inevitabil la încălcarea PDI
• Principiile sunt esenţiale pentru a profita de avantajele
dezvoltării OO

15 edited by gl 53 ban
 Sablonul Factory…………………………………….….1
Sablonul Abstract Factory…………………………….2
Sablonul Prototype……………………………………..4
Sablonul Singleton……………………………………..6
Sablonul Command……………………………………..7
Sablonul Composite………………………….…………9
Sablonul Strategy………………………………………..10
Sablonul State..............................................................11
Decorator……………………………………………………..12
Principiul deschis-închis (PDI)…………………………13
Principiul Inversării Dependenţelor (PID)…………….14

16 edited by gl 53 ban