Principii de proiectare orientate pe obiect

5.1. Principiul Deschis nchis - OCP (Open Close

Principle)
Proiectarea orientat pe obiecte (OOD : Object Oriented Design) este o metod
de descompunere a arhitecturii unui sistem software cu scopul obinerii
modularizrii acestuia.
"Orice entitate software (clase, module, funcii, etc) ar trebui sa fie deschis
pentru extindere, i nchis pentru modificare."
n proiectarea sistemului de folosete abstractizarea i polimorfismul.
Un modul software care respect principiul deschis nchis are dou caracteristici
principale:
1. "deschis pentru extindere": comportamentul modulului poate fi extins. Se poate obine
astfel un comportament nou n conformitate cu noile cerine ale aplicaiei.
2. "nchis pentru modificri": codul surs al modulului este "inviolabil", nimnui nu i se
permite s fac schimbri n cod.
Dei la o prima vedere cele dou cerine par contradictorii, totui ele pot fi
simultan satisfcute prin utilizarea abstractizrii.

nchidere strategic
Nici un program nu poate fi nchis 100%. .
Nici un program nu poate fi nchis pentru modificri n mod total, deoarece,
orict de nchis ar fi un modul, ntotdeauna pot aprea situaii pentru care nu a
fost nchis. Avnd n vedere c, nchiderea unui modul fa de modificri nu
poate fi complet, ea trebuie s fie strategic.

Reguli de proiectare folosite n OOD

Toate variabilele s fie private
n OOD, nchiderea celorlalte clase, inclusiv a claselor derivate, fa de modificarea
variabilelor dintr-o clas, poart numele de ncapsulare datelor. Avantaje ale ncapsulrii
datelor:
- securitatea datelor: acestea nu pot fi modificate din exteriorul clasei n care sunt vizibile;
- consisten: prin modificarea variabilelor din alte clase, de ctre diferii utilizatori pot
aprea situaii de inconsisten, datorate unor modificri care nu sunt atomice.
Fr variabile globale

Argumentele mpotriva variabilelor globale sunt similare celor mpotriva variabilelor publice.
Nici un modul care utilizeaz o variabil global nu poate fi nchis fa de celelalte module
care modific respectiva variabil.

Principiul substituiei Liskov !!!

Funciile care utilizeaz pointeri sau referine ctre clasele de baz, trebuie s poat utiliza
obiecte ale claselor derivate din clasa de baz n mod transparent [Riel 1996].

Consistena unui model

n acest moment, exist dou clase, care n aparen funcioneaz corespunztor: Ptrat i
Dreptunghi, fiecare modeleaz corespunztor obiectele matematice ale cror nume le
poart (ptrat i dreptunghi). n aparen, se poate spune c sistemul are un comportament
consistent. Se poate trage concluzia c modelul este auto-consistent i corect. Dar aceast
concluzie ar fi o eroare deoarece un model care este auto-consistent nu este n mod
necesar consistent i cu toi utilizatorii si.

Validitatea nu este intrinsec

Cazul expus mai sus impune o concluzie important: validitatea unui model nu poate fi
considerat semnificativ dect ntr-un anumit context. Un model izolat nu poate fi apreciat
din punct de vedere al validitii lui.
toate clasele derivate trebuie s respecte comportamentul pe care clienii l ateapt
de la clasa de baz pe care o utilizeaz.

Design prin contract

Exist o strns relaie ntre Principiul substituiei al lui Liskov i conceptul de Design by
contract, aa cum a fost definit de Bertrand Meyer. Utiliznd aceast schem, metodele
claselor declar precondiii i postcondiii. O metod se execut dac precondiiile sunt
adevrate. La terminarea metodei, aceasta garanteaz c postcondiiile vor fi adevrate.
!!! Cnd se redefinete o metod n clasa derivat, precondiia se nlocuiete prin una
mai "slab", iar postcondiia prin una mai "puternic".

Principiul Inversrii Dependenelor DIP

A. Modulele de pe nivelele superioare nu trebuie s depind de modulele de pe
nivelele inferioare. Modulele de pe cele dou nivele ar trebuie s depind de
nite abstractizri.
B. Abstractizrile nu trebuie s depind de detalii. Detaliile trebuie s depind
de abstractizri.
Astfel, DIP impune ca, pe de o parte, ntr-o ierarhie de clase, clasa din
care se deriveaz s nu cunoasc nici una dintre subclasele sale, iar pe
de alta parte, modulele care implementeaz detaliile depind de
abstractizri, i nu invers

Organizarea pe nivele

Conform lui Booch [Booch, 1996]: "[] Toate arhitecturile orientate pe obiect,
bine structurate au nivele clar definite, fiecare nivel oferind un set de servicii
prin intermediul interfeei sale."
Nivelul Deciziilor depinde de Nivelul Mecanismelor, care depinde de
Nivelul Serviciilor, deci Nivelul Deciziilor depinde de Nivelul Serviciilor
(tranzitivitatea dependenelor).
Interfaa reprezint totalitatea serviciilor pe care nivelul inferior le ofer
nivelului superior.
Cu alte cuvinte, conform acestui model, Nivelul Deciziilor este complet
independent de nivelele inferioare, putnd fi reutilizat n orice alt context n care
se definete un nivel inferior bazat pe interfaa Nivelului Mecanismelor.

Reguli de proiectare folosite n OOD

Prin utilizarea Principiului Inversrii Dependenelor, s-a ajuns la cteva rezultate practice.
Utilizarea interfeelor (claselor abstracte) pentru a evita legturile directe ntre clasele
concrete (Fig.5.10)
Utilizarea interfeelor contribuie la obinerea unui cod stabil pentru clasa
concret Client.
Regul de baz - Evitarea dependenelor tranzitive prin utilizarea
interfeelor!
Privit din perspectiva principiilor prezentate n seciunile anterioare, se poate
spune c OCP este scopul, DIP (Principiului Inversrii Dependenelor) asigur
mecanismul de ndeplinire a scopului, iar LSP (Principiul substituiei al lui
Liskov) este modalitatea de verificare a mecanismului.
Care este scopul unui design conform OCP ? Obinerea unor entiti
software care s fie deschise pentru extindere dar nchise la modificri, n acest
timp pstrndu-se calitile unui bun design: flexibilitate, mobilitate i
reutilizabilitate. DIP specific modalitatea de atingerea acestui scop: - ntr-o
ierarhie de clase, clasa din care se deriveaz nu cunoate nici una dintre
subclasele sale - modulele care implementeaz detaliile depind de abstractizri,
i nu invers. * Iar prin LSP se asigur o msura a calitii motenirii, verificnduse ca prin motenire s se obin subclase care au aceleai proprieti ca i
superclasa. Aceste trei principii sunt strns legate ntre ele: dac este nclcat
unul dintre principiile LSP sau DIP, atunci implicit este nclcat OCP.

Stabilitate. Principiul dependenelor stabile

Aa cum s-a artat n cadrul subcapitolului 1.2. Probleme ale software-ului,
interdependena reprezint una dintre cauzele pentru care un design este
rigid, imobil i dificil de reutilizat. Totui, interdependena este necesar dac

modulele implicate n design "colaboreaz". Ca urmare exist tipuri de

dependen utile i tipuri de dependen indezirabile.
Aceti indicatori msoar stabilitatea software-ului. Stabilitatea este nsi
esena designului software.