Sabloane.
Cea mai bună metodă de creare Metoda Factory: o clasă simplă pentru
de obiecte, astfel încât programul să nu
depindă de modul în care acestea sunt
create
Abstractizarea procesului de creaţie, într-o
clasă specială “creator”- pentru mai multă
flexibilitate
Factory Method, Prototype,
Abstract Factory, Singleton, Composite,
Command, Observer, Mediator
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
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
Consecinte
- Decuplează Invoker de Receiver
- Comenzile sunt obiecte ale unor clase
--pot fi manevrate şi extinse
--Comenzi compuse (Composite Commands)
- Uşor de adăugat comenzi noi
--invoker nu se modifică
--cod stabil- Principiul Deschis-Închis
- Potenţial pentru un exces de clase de tip
command
Observer
Scop
Defineşte o dependenţă de tipul unul-la-
mai-mulţi între obiecte astfel încât atunci
când un obiect îşi schimbă starea, toate
dependenţele sale sunt anunţate şi
actualizate automat
Aplicabilitate
Când o abstracţiune are două aspecte, una
dependentă de cealaltă; încapsularea
acestor aspecte în obiecte diferite permite
varierea şi refolosirea lor independentă;
Când modificarea unui obiect solicită
modificarea altora, şi nu ştim exact câte
obiecte trebuie modificate (modificări
dinamice, la execuţie);
Când un obiect trebuie să poată notifica alte
obiecte fără să presupună cine sunt acestea
Consecinte
Cuplaj minimal si abstract intre subiect si
obsevatori
Suport pentru comunicare de tip difuzare
(“broadcast”)
Modificări neaşteptate Întrucât observerii
nu ştiu unul de existenţa celuilalt, pot apare
modificări incorecte, în cascadă
Abstract Factory: o interfaţă pentru crearea
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
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
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 ;
Clienţii ar trebui să deriveze din Creator
doar pentru a crea un anumit obiect
ConcreteProduct.
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
Leaf
--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ă
Prototype: începe cu o clasă instanţiată şi
iniţializată ş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ă
Creati 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
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
Memento
şi returnarea uneia dintre mai multe familii
de obiecte relaţionate
Scop Oferă o interfaţă pentru crearea de
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
Trebuie forţat ca o familie de obiecte
produs să fie folosite împreună
Consecinte
1 Izolarea claselor concrete: apar în
ConcreteFactories nu în codul clientului
2 Facilitează schimbul de familii de
produse:un ConcreteFactory apare într-un
singur loc
3 uşor de modificat: Promovează
consistenţa între produse; toate produsele
unei familii se modifică împreună, în acelaşi
timp
4 Este dificilă susţinerea de tipuri noi de
produse: necesită o modificare în interfaţa
AbstractFactory şi a tuturor subclaselor sale,
în consecinţă
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
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
Mediator
Scop
Defineşte un obiect ce încapsulează cum
interacţionează o mulţime de obiecte
Promovează cuplajul redus prin faptul că
obiectele nu mai fac referinţă direct unele la
altele, permiţând varierea independentă a
interacţiunii lor
Aplicabilitate Folosiţi Mediator când:
O mulţime de obiecte comunică într-un mod
bine definit dar complex;
-Interdependenţele sunt nestructurate şi
dificil de înţeles;
Refolosirea unui obiect este dificila
deoarece comunica prea multe obiecte
Un comportament distribuit între mai multe
clase ar trebui să fie readaptabil fără
derivare
Consecinte
Limitează derivarea
Decuplează colegii
Simplifică protocoalele obiectelor
Abstractizează cooperarea obiectelor
Centralizează controlul: mediatorul se poate
transforma într-un monolit dificil de
întreţinut
Scop: capteaza si externalizeaza starea
interna a unui obiect astfe; incat obiectul
poate fi restaurant in aceasta stare mai
tarziu, fara a sparge incapsularea
Aplicabilitate:
Cand (o parte din) starea unui obiect trebuie
salvata pentru a readuce mai tarziu obiectul
in aceasta stare
Cand o interfata directa pentru obtinerea
starii ar expune detalii de implementare si
ar sparge incapsularea obiectului
Consecinte:
Protejeaza granitele incapsularii
Simplifica Originatorul: acesta nu e nevoit sa
retina stari anterioare la care ar fi necesar sa
revina
Uneori folosirea este costisitoare: daca este
multa informative de copiat sau atunci cand
clientii creaza des memento-uri
Costuri ascunse in manevrarea memento-
urilor: un caretaker nu stie exact cat sa aloce
pentru stocarea unui memento
Strategy
Scop:- defineste o familie de algoritmi,
incapsuleaza fiecare algoritm, ii face
interschimbabili.
- permite algoritmului sa varieze
independent de clientii ce il folosesc
Aplicabilitatea:- sunt necesare variante
diferite al unui algoritm
-un algoritm foloseste date despre care
clientii nu trebuie sa stie: evita expunerea
structurilor de date complexe, specifice
algoritmului
-multe clase rationate difera doar prin
comportament: configureaza o clasa cu un
comportament particulat
Consecinte pozitive
Familii de algoritmi înrudiţi
Alternativă la derivare
Elimină instrucţiunile condiţionale
Consecinte negative
1.Exces de comunicare între Strategy şi
Context 2. Clienţii trebuie să fie conştienţi
de diferitele strategii 3.Număr sporit de
obiecte
Flyweight
Scop: foloseste partajarea pentru a sustine
implementarea eficienta a unui numar mare de
obiecte cu granulatie fina
Aplicabiliatate: Cand toate conditiile de mai jos sunt
indeplinite simultan:
-o aplicatie foloseste un numar mare de obiecte
-costurile de stocare sunt ridicate din cauza
numarului mare de obiecte
-cea mai mare parte din starea unui obiect poate fi
facuta extrinseca
-multe grupuri de obiecte se pot inlocui de un numar
relativ mic de obiecte partajate, odata ce am
ilaturata starea extrinseca
-aplicatia nu depinde de identitatea obiectelor,
intrucat obiectele flyweight pot fi partajate, testele
de identitate vor fi intoase true pentru obiecte
conceptual distincte
Consecinte
Flyweight-urile adaugă costuri la momentul execuţiei
Cantitatea de spaţiu economisit depinde de mai mulţi
factori:1Reducerea numărului total de instanţe prin
partajare 2Cantitatea de stare intrinsecă pentru
fiecare obiect 3Dacă starea extrinsecă e calculată sau
stocată
Cel mai mult spaţiu se economiseşte dacă obiectele
folosesc cantităţi susbstanţiale de stare intrinsecă şi
extrinsecă, şi dacă starea extrinsecă se poate calcula-
în loc să fie stocată
Builder
Scop: separa contruirea unui obiect complex
de reprezentarea sa, astfel incat acelasi
process de constructie poate genera
reprezentari diferite
Aplicabilitate:
Cand algoritmul pentru cearea obiectului
complex trebuie sa fie independent de
partile ce compun obiectul si de modul lor
de asamblare
Cand procesul de contructie trebuie sa
permita reprezentari diferite pentru
obiectul construit.
Consecinte:
-permite varierea reprezentarii interne a
unui produs
-izoleaza codul pentru contructie si
reprezentare
-rafineaza controlul asupra procesului de
construire
Iterator
Scop: furnizeaza o modalitate de accesare
secventiala a elementelor unui agregat, fara
a expune reprezentarea care sta la baza
acestora
Aplicabilitatea:
Pentru a accesa continutul uni obiect
agregat fara sa ii expun reprezentarea
interna
Pentru a sustine traversari multiple ale
obiectelor agregat
Pentru a furniza o interfata uniforma de
traversare a diferitelor structuri agregat
Consecinte:
-sprijina variatiunile in traversarea unui
agregat
- iteratorii simplifica interfata agregatului
- pot exista mai multe traversari simultan:
fiecare iterator tine evidenta starii propriei
iteratii
Principiul Abstractiunilor Stabile (PAS)
Abstractizarea unui pachet trebuie să fie
proporţională cu stabilitatea sa!
Pachetele maximal stabile trebuie să fie
maximal abstracte.
Pachetele instabile trebuie să fie concrete.
Acest princpiu realizeaza o relatie intre
stabilitate si abstractizare. Un pachet stabil
ar trebui sa fie abstract incat propria-i
stabilitate sa nu-l previna impotriva
extinderii. Pe de alta parte PAS spune ca
pachetele instabile trebuie sa fie concrete,
deoarece instabilitatea permite codului sa
fie schimbat cu usurinta. Daca un pachet
devine stabil ar trebui sa contina clase
abstracte, astfel poate fi extins. Pachetele
stabile care pot fi extinse sunt flexibile si nu
constrang design-ul.
Masurarea abstractizarii
Metrica A este o masura a abstractizarii unui
pachet. Valoarea ei este raportul dintre
clasele abstracte dintr-un pachet si numarul
total de clase din pachet.
Metrica A ia valori intre 0 si 1. Zero
inseamna ca pachetul nu are deloc clase
abstracte. Unu inseamna ca pachetul
contine doar clase abstracte.
Secventa principala
Se poate defini o relatie intre instabilitatea I
si abstractizarea A
Zona Critica (Pain)
-foarte stabil si concret => rigid
-exemple: schemele bazelor de date,
librariile de utilitati concrete
Zona de inutilitate
-instabil si abstract=>nefolositor
nu depinde nimani de clasele respective
Secventa principala
-maximizeaza distanta intre zonele de evitat
-un echilibru intre abstractiune si stabilitate
Distante de la secventa principala
Distanta =|A+I-1|/√2 , in domeniul [0,
~0.707]
Distanta normalizata D=|A+I-1|, in
domeniul [0,1]; 0=pachet pe secventa
principala, 1=pachet departe de secventa
principala.
State
Scop: permite unui obiect sa isi modifice
comportamentul cand i se modifica starea
interna:obiectul va parea ca-si schimba clasa
Aplicabilitate:-comportamentul obiectului
depinde de starea sa
- trebuie sa isi modifice comportamentul la
executie in functie de stare
- operatii cu instructiuni contionale multiple,
depinzand de starea obiectului
Consecinte:- localizeaza comportamentul
specific starilor si particularizeaza
comportamentul pentru stari diferite
- - comportament imprastiat intre mai multe
subclase alea State:1numarul de clase
creste, mai putin compact decat o singura
clasa 2util daca sunt multe stari
-face explizita tranzitia intre stati
Proxy
Scop:furnizeaza un surogat pentru alt obiect
pentru a controla accesul la el
Aplicabilitate:-oricand este nevoie de o
referinta catre obiect mai flexibila sau mai
sofisticata decat un simplu pointer
-proxy la distanta;- proxy virtual
-proxy de protectie; -proxy accesorii: previn
stergerea accidentala a obiectelor
Consecinte:-proxy-urile introduc un nivel de
indirectare
- copiaza in timp ce scrii:
- -copierea obiectelor mari si complicate e
costisitoare;
- -copiem numai cand obiectul nou esre
modificat
Principiul Echivalentei Refolosire/Folosire
(PER)
Granularitatea de refolosire e granularitatea
de distribuţie (release).
Doar componentele ce pot fi uşor urmărite
(în cod, în versiunile ulterioare), pot fi
refolosite eficient.
Adică?
– Un element software
reutilizabil nu poate fi refolosit cu adevărat
în practică dacă nu este gestionat de un
sistem de distribuţie (release system) de un
anumit tip
• ex. Numere sau nume
asociate elementului refolosit
– Nu există ”clasă reutilizabilă”
• fără garanţia notificării,
siguranţei şi asistenţei
• trebuie integrat întregul
modul (nu se poate reutiliza mai puţin)
Fie toate clasele unui pachet sunt
reutilizabile, fie nici una nu este!
Chain of Responsability
Scop:-decupleaza transmitatorul cererii de primitor:
oferind mai multor obiecte sansa de a trata cererea;
-pune primitorii intr-un lant si transmite cererea de-a
lungul lantului pana ce un obiect o trateaza
Aplicabilitate -mai mult decât un obiect poate trata o
cerere şi nu cunoaştem apriori cine o va trata
-mulţimea de obiecte ce pot trata cererea trebuie să
fie specificabilă dinamic
-trimitem o cerere la mai multe obiecte fără să
specificăm primitorul
Consecinte: -Cuplaj redus 1clientul (trimiţătorul) nu
trebuie să ştie cine îi va trata cererea 2trimiţătorul şi
primitorul nu se cunosc unul pe celălalt 3în loc ca
trimiţătorul să cunoască toţi potenţialii primitori, se
păstrează doar o referinţă la următorul handler din
lanţ.
-Flexibilitate în asignarea responsabilităţilor către
obiecte
-Cererile pot rămâne netratate
Bridge
Scrop:- decupleaza o abstractiune de
implementarea sa
-permite implementarii sa varieze
independent de abstractiunea sa
-abstractiunea defineste si implementeaza
interfata
Aplicabilitate:Evita legarea permanenta
intre o abstractiune si implementarea sa
Abstractiunile si implementarile lor trebuie
sa fie independent extensibile prin derivare
Ascunde implementarea unei abstractiuni
complet de clienti
Partajeaza o implementare intre mai multe
obiecte.
Consecinte
Decupleaza interfata si implementarea
Extensibilitate imbunatatita
Ascunderea detaliilor de implementare de
clienti
Principiu Reutilizarii Comune (PRC)
Toate clasele unui package [library] trebuie
refolosite împreună. Dacă refolosim o clasă
din pachet, le refolosim pe toate. Principiul
ne ajuta sa decidem ce clase ar trebui puse-
n pachet. PRC se aplica claselor ce tind sa fie
refolosite impreuna. In general clasele
reutilizabile colaboreaza cu alte clase ce fac
parte din abstractizari reutilizabile.
Un simplu exemplu ar putea fi clasa
Container cu iteratori asociati. Aceste clase
sunt refolosite impreuna deoarece sunt
strans cuplate intre ele. Astfel ele trebuie sa
fie in acelasi pachet. Se spune ca atunci cand
depinzi de un pachet, depinzi de clasele din
acel pachet. Altfel vom depinde de clase ce
nu au legatura cu aplicatia noastra si va
trebui sa recompilam aplicatia la fiecare
noua versiune a pachetului de care
depindem (chiar daca versiunea modifica
doar acele clase de care noi nu avem
nevoie)
Decorator
Scop:adauga responsabilitati unui obiect
particular, mai degraba decat clasei sale. O
alternativa flexibila la derivare
Aplicabilitate:-adauga responsabilitati
obiectelor transparent si dinamic fara sa
efectueze alte obiecte
-extinderea prin derivare nu e practica
Consecinte
Mai flexibil decât moştenirea statică
-permite amestecarea şi potrivirea
responsabilităţilor: -permite aplicarea unei
proprietăţi de două ori
Evită clasele încărcate de prea multe
cracteristici specifice în partea de sus a
ierarhiei: -abordarea "plăteşte-pe-măsură-
ce-consumi"; -uşor de definit noi tipuri de
decoraţiuni
O mulţime de obiecte mici uşor de adaptat,
dar dificil de învăţat şi depanat
Adapter
Scop: Converteste interfata unei clase intr-o
alta interfata asteptata de client
Permite unor clase cu interfete diferita sa
lucreze impreuna
Aplicabilitate:-cand dorim sa folosim o clasa
preexistenta si interfata acestuia nu se
potriveste cu interfata de care avem nevoie
-vrem sa creem o clasa reutilizabila ce
coopereaza cu clase nerelationate si
neprevazute
-cand avem nevoie sa folosim mai multe
sublase existente, dar nu e practic sa
derivam din fiecare pentru a le adapta
interfata
Consecinţe adaptor obiect
-Permite unui singur Adapter să lucreze cu
mai multe clase Adaptee- i.e. clasa Adaptee
şi toate subclesele sale, dacă acestea există;
Adapter poate adăuga funcţionalităţi la
toate clasele Adaptee odată
-Este mai dificil de suprascris
comportamentul lui Adaptee; pentru
aceasta va fi necesar să derivăm Adaptee şi
să facem Adapter să se refere la subclasă
direct, nu la Adaptee
Consecinţe adaptor clasă
-Adaptează Adaptee la Target ţinând cont
de o clasă Adapter concretă
-Permite clasei Adapter să suprascrie o
parte din comportamentul Adaptee, întrucât
Adapter e o subclasă a lui Adaptee
-Introduce doar un singur obiect, şi nu este
nevoie de indirectare suplimentară cu
pointeri pentru a obţine obiectul adaptat
Principiul Deschis Inchis (PDI)
Entitatile software (clase, module, functii…)
trebuie sa fie deschise la extinderi, dar
inchise la modificari.
Atunci cand o singura schimbare determina
in program o cascada de schimbari in
module dependente, se spune despre acel
program ca nu e bine proiectat, devenind
astfel fragil, rigid, nepredictibil, de
nereutilizat. Principiul deschis-inchis se
ocupa de aceasta problema. PDI impune
proiectarea de module care sa nu fie
modificate. Atunci cand se impun schimbari,
se schimba comportamentul modulelor prin
adaugarea unui cod nou, nu prin schimbarea
vechiului cod care deja e functional.
Modulele ce respecta PDI au doua principale
proprietati:
-Sunt deschise extinderii
Comportamentul modulelor poate fi extins.
Putem face ca un modul sa se comporte
in diferite moduri, in functie de schimabrile
cerintelor aplicatiei, sau sa respecte
cerintele unei noi aplicatii
-Sunt inchise modificarii
Codul sursa al unui astfel de
modul nu are voie sa fie modificat
Desi aceste proprietati par a fi
contradictorii, deoarece metoda prin care se
poate extinde un modul e modificarea
acestuia. Felul in care aceste proprietati
“lucreaza” e abstractizarea.
Inchidere strategica:
-“Nici un program semnificativ nu poate fi
100% inchis”
-Inchiderea se obtine prin utilizarea
abstractizarii
Construiti metode ce pot fi
invocate dinamic
Pentru a determina deciziile strategiei
generale (ex: desenare de patrate inainte de
cercuri)
-Utilizati o abordare “condusa de date”
pentru a obtine inchiderea
Plasati deciziile strategiei particulare intr-o
locatie separata (ex: fisier sau obiect
separat)
Minimizeaza localizarile schimbarilor
viitoare
Euristici PDI:
Toate datele membru sunt private. Nu
exista variabile globale.
Modificarile datelor publice aduc un risc de
“deschidere” a modulului.
~Pot provoca un efect de modificari in
casacada, in mai multe locatii neasteptate
~Erorile pot fi dificil de corectat/de gasit in
totalitate (corecturile pot introduce erori in
alte parti)
Membrii non-privati sunt modificabili
~Pot schimba starea clasei.
Principiul Substitutiei (Liskov)-PSL
Functiile care utilizeaza pointeri sau
referinte catre clasele de baza trebuie sa
poata folosi obiecte din clasa derivata fara
sa stie. Importanta acestui principiu devine
evidenta atunci cand iei in calcul
consecintele incalcarii acestuia. Daca o
functie nu respecta PSL, atunci acea functie
foloseste un pointer sau o referinta catre
clasa de baza, insa trebuie sa cunoasca toate
derivatele clasei de baza. O astfel de functie
incalca PDI deoarece ea trebuie modificata
oricand o nou clasa derivata este creata
Comportamentul anuntat al unui obiect:
-Necesitatile anuntate (Preconditii)
-Promisiunile anuntate (Postconditii)
Când redefinim o metodă într-o clasă
derivată, putem înlocui precondiţia sa doar
cu o precondiţie mai slabă, şi postcondiţia sa
doar cu o precondiţie mai tare.
Serviviile claselor derivate: sa nu ceara mai
mult, sa nu promita mai putin.
PSL: Semantica si Inlocuire
-Semantica si scopul fiecarei metode si clase
trebuie clar documentat.
-Lipsa intelegerii utilizatorului va duce la
incalcarea PSL
-Oriunde se face referire la o clasa in cod,
orice subclase existente sau viitoare ale sale
trebuie sa fie 100% substituibile
-Orice cod ce poate chema legal metodele
altei metode trebuie sa poata substitui
orice subclasa a clasei respective, fara
modificari
Euristici PSL:
Nu este permis ca o clasa derivate sa
suprascrie o metoda a clasei de baza printr-
o metoda NOP (no-operation; metoda ce nu
face nimic)
Solutii:
1.Relatie de derivare inversa
-daca in clasa de baza initiala exista doar
comportament additional
2. Extragerea unei clase de baza commune
-daca atat clasa initiala cat si clasele derivate
au comportament diferit
Principiul Inversarii Dependentelor (PID)
1.Modulele de nivel-înalt nu trebuie să
depindă de modulele de nivel scăzut.
Ambele trebuie să depindă de abstracţiuni.
2.Abstracţiunile nu trebuie să depindă de
detalii. Detaliile trebuie să depindă de
abstracţiuni.
Intr-o ierarhie de clase clasa de baza nu
trebuie sa isi stie subclasele. Modulele cu
implementari detaliate depend de
abstractiuni si nimic nu depinde de ele.
PID poate fi aplicat oricand o clasa trimite
mesaje altei clase.
De exemplu, daca consideram doua obiecte,
unul de tip Button si alte de tip Lamp.
Obiectul de tip Button detecteaza daca
cineva a activat sau nu butonul. Obiectul de
tip Lamp afecteaza mediul exterior. Daca
Lamp primeste un mesaj de tipul
TurnOn/TurnOff, atunci lumina se va
aprinde/stinge
PID este incalcat deoarece metodele de
nivel inalt ale aplicatiei nu au fost separate
de modulele de nivel scazut. Abstractizarile
nu au fost separate de detalii.
Pentru ca PID sa nu fie incalcat trebuie sa
izolam abstractizarea de detaliile problemei.
Apoi trebuie sa rezolvam dependentele
proiectarii, adica detaliile trebuie sa depinda
de abstractizari.
PID se foloseste in aplicatii in care poate fi
reutilizat, insa sa aiba rezistenta la
schimbari. Din moement ce abstractizarile si
detaliile sunt separate unele de celaltele,
codul este mult mai usor de “intretinut” .
-----------------------------------------------------------
Principiul Închiderii Comune (PÎC)
Clasele unui pachet trebuie să fie închise
faţă de acealeaşi tipuri de modificări.
O modificare ce afectează pachetul,
afectează toate clasele acelui pachet.
Mai important decat reuzabilitatea este
mentenabilitatea. Daca codul intr-o aplicatie
trebuie schimbat, aceste schimbari vor
aparea intr-un pachet sau in mai multe
pachete? Mai degraba schimabarile ar
trebuie sa fie focusate intr-un pachet decat
imprastiate in mai multe pachete. PÎC e o
incercare de a aduna intr-un singur loc
clasele ce sunt predispuse schimbarilor din
varii motive. Acest principiu e puternic
asociat cu PDI . PÎC presupune: clasele ar
trebui sa fie inchise modificarii, dar deschise
extinderii. Din PDI se stie ca nu exista 100%
inchidere. Inchiderea trebuie sa fie
strategica. PÎC grupeaza in acelasi pachet
clase care nu pot fi inchise impotriva unor
tipuri de schimbari. Astfel atunci cand vine
o schimbare a cerintelor, acea schimbare
este cel mai probabil limitata la un numar
minim de pachete.
Principiul Dependentelor Aciclice (PDA)
Structura de dependenţe a componentei
distribuite trebuie să fie un Graf Direcţionat
Aciclic (GDA). Nu trebuie să existe cicluri.
O “Dependenţă Bună” este o dependenţă
de o ţintă cu volatilitate redusă
Principiul Dependentelor Stabile (PDS)
Dependenţele între componente trebuie să
fie în direcţia stabilităţii.
O componentă trebuie să depindă de
componente mai stabile decât ea.
Prin folosirea acestui principiu cream
pachete ce sunt senzitive la anumite tipuri
de schimbari. Aceste pachete sunt
proiectate sa fie volatile. Orice pachet ce se
vrea a fi volatil nu ar trebui sa depinda de un
pachet greu de modificat. Altfel pachetul
volatil va fi greu de modificat. Conform PDS
modulele ce sunt proiectate sa fie instabile
(predispuse la schimbare) nu depind de
modulele ce sunt mai stabile (mai greu de
modificat). Cum poate fi calculat stabilitatea
unui pachet? O madalitate este numararea
dependentelor care intra si ies in / din
pachet. Aceste numaratori ne vor permite
sa calculam stabilitatea pozitionala a
pachetului.
*Ca:cuplaj afferent-nr. de clase din afara
pachetului ce depind de clasele din pachet
*Ce:cuplaj efferent-nr de clase din pachet ce
depind de clasele din afara pachetului
*I:instabilitatea: I ia valori de la 0 la 1;
0=stabilitate maxima a pchetului;
1=instabilitate maxima a pachetului
Valorile Ca si Ce se calculeaza prin
numararea claselor din afara pachetului in
cauza, care au dependente cu clasele din
pachetul in cauza.
Plasarea proiectarii de nivel inalt
Anumite programe in sistem nu ar trebui sa
se modifice foarte des. Acest program
repezinta arhitectura de nivel inalt si
deciziile de design. Nu se doreste ca acestea
sa fie volatile. Asadar programul care
incapsuleaza modelul design-ului de nivel
inalt ar trebui sa fie plasat in pachete
stabile. Pachetele instabile trebuie sa
contina programul ce e predispus la
modificari. Cum un pachet cu stabilitate
maxima (I=0) poate fi destul de flexibil
pentru a rezista la schimbari? Raspunsul:
PDI. Principiul deschis-inchis ne spune ca e
posibil si chiar de dorit sa cream clase ce
sunt destul de flexibile sa fie extinse fara a
nevesita modificare. Clasele ce respecta
acest principiu sunt clasele abstracte.
-----------------------------------------------------------
Principiul Segregarii Interfetelor (PSI)
Clienţii nu trebuie forţaţi să depindă de
interfeţe pe care nu le folosesc.
Atunci cand un client depinde de o clasa ce
contine interfete pe care clientul nu le
foloseste, dar alt client le foloseste, atunci
acel client va fi afectat de schimbarile pe
care ceilalti clienti le fac asupra clasei. Mai
multe interfeţe specializate pe fiecare client
sunt mai bune decât o interfaţă de interes
general.