Principii ale proiectrii software-ului orientat pe obiecte

Object Oriented Design OOD

Object Oriented Design - OOD

Proiectarea orientat pe obiecte este o metod de descompunere a arhitecturii unui sistem software cu scopul obinerii modularizrii acestuia. OOD se bazeaz pe programarea orientat pe obiect, implicit pe obiectele pe care orice sistem sau subsistem le manipuleaz. Se poate spune c OOD este relativ independent fa de limbajul de programare folosit (Java, C++). Pentru construirea unui proiect bun al sistemelor software, trebuie respectate mai multe principii de baza ale OOD, respectarea acestora putnd fi privit ca o modalitate de rezolvare a acestor probleme.
2

Object Oriented Design - OOD

1.
2. 3. 4.

Principiul Deschis-nchis Principiul substituiei Liskov Principiul inversrii dependenelor Principiul dependenelor stabile

Principiul Deschis nchis

OCP- Open Close Principle- B. Meyer

"Orice entitate software (clasa, modul, funcie, etc.) ar trebui s fie deschis pentru extindere, i nchis pentru modificare."

Un modul software care respect principiul Deschis nchis are dou caracteristici principale:

"deschis pentru extindere": comportamentul modulului poate fi extins. Se poate obine astfel un comportament nou n conformitate cu noile cerine ale aplicaiei. "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.
5

Principiul Deschis nchis

n limbajele de programare OO, se pot crea abstractizri care sunt fixe din punct de vedere al codului, dar care totui reprezint un grup nelimitat de posibile comportamente. Abstractizrile sunt clasele de baz abstracte, iar grupul nelimitat de comportamente este dat de toate clasele ce se pot deriva din acestea.

n Figura 1 se prezint un exemplu foarte des utilizat de proiectare a unei aplicaii simple, n care att clasa Client ct i clasa Server sunt dou clase concrete. Clasa Client utilizeaz clasa Server. Dac se dorete ca un obiect Client s utilizeze un alt obiect Server, atunci clasa Client trebuie modificat pentru a indica numele noii clase server, deci aceasta proiectare nu respect OCP.

Figura 1

Proiectare greit Client-Server

Figura 2 prezint design-ul pentru aplicaia Server Client astfel nct s respecte principiul deschis nchis. n acest caz, se utilizeaz o clas abstract AbstractServer , din care se deriveaz clasa concreta Server iar clasa Client depinde de aceast clasa abstract. Obiectele Client vor folosi obiecte ale unei clasei derivate ServerA. Dac se dorete ca obiectele Client s foloseasc obiecte ale unei alte clase Server, atunci se creeaz, prin derivare, din clasa abstract o nou clas concret ServerB. n acest mod, codul clasei Client rmne nemodificat.
9

Figura 2- Proiectare corect Client-Server

Pentru obinerea unor noi comportamente necesare extinderii aplicaiei, trebuie doar s se deriveze din clasa abstract, clase concrete Server care implementeaz noi comportamente.

10

nchidere strategic
Nici un program nu poate fi nchis 100%.
Avnd n vedere c, nchiderea unui modul fa de modificri nu poate fi complet, ea trebuie s fie strategic. nchiderea strategic presupune ca designer ul arhitecturii sistemului s abstractizeze partea care este cea mai susceptibil a fi extins. nchiderea explicit a sistemului la modificri se obine utiliznd abstractizarea. Clasa abstract va furniza metode care pot fi invocate dinamic i n cadrul crora se stabilesc politicile de decizie la nivel general.

11

nchidere strategic

O alt metod care ajut la nchiderea sistemului se bazeaz pe abordare data-driven, care presupune plasarea codului care se refer la deciziile de politic volatil ntr-o locaie separat, fie ntr-un alt fiier, fie ntr-un alt obiect, astfel c pe viitor modificrile se vor face ntr-un numr minim de locaii.
12

Principiul Deschis nchis este sursa unor reguli de proiectare folosite n OOD.

Toate variabilele s fie private Privit din prisma OCP, motivaia acestei convenii este urmtoarea: Cnd variabilele dintr-o clas se modific, fiecare dintre clasele care depind de acestea ar trebui modificate. Deci, nici o funcie care depinde de o variabil, nu poate fi nchis fa de aceasta. Datele constante (declarate const n C++ sau final n Java) pot fi publice sau protejate, fr a nclca principiul nchiderii.
13

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.
14

Fr variabile globale
Nici un modul care utilizeaz o variabil global nu poate fi nchis fa de celelalte module care modific respectiva variabil. Este posibil ca un modul s utilizeze variabila global ntr-un mod neateptat pentru celelalte module care o mai folosesc. Designerul trebuie s evalueze ct din nchiderea aplicaie este "sacrificat" n favoarea variabilelor globale i s determine dac avantajele oferite de utilizarea variabilelor globale compenseaz dezavantajele date de utilizarea lor.

15

Concluzii- OCP
n multe privine acest principiu este considerat esena proiectrii orientate pe obiecte. Avantajele care se obin de pe urma folosirii acestuia sunt reutilizarea codului i mentenabilitatea software-ului. OCP afirm ca un design bine gndit poate fi extins fr modificri, noile caracteristici ale sistemului adugndu-se prin completarea de cod nou, i nu prin modificarea celui existent.

16

Concluzii- OCP
Mecanismele pe care se sprijin acest principiu sunt abstractizarea i polimorfismul. Faptul ca se programeaz ntr-un limbaj orientat pe obiecte nu duce automat la concordan / conformitate cu OCP, ci este necesar ca designerul s aplice abstractizarea pe acele pri ale programului care sunt susceptibile de a fi modificate.

17

Principiul substituiei Liskov-LSP

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. LSP poate fi interpretat ca un mijloc de verificare a codului, din punctul de vedere al obinerii unui design n acord cu OCP.

18

LSP
Acest principiu creeaz ierarhii de clase care se conformeaz OCP. S presupunem c exist o metod care nu se conformeaz LSP, atunci acea metod utilizeaz un pointer sau o referin ctre clasa de baz, i n acelai timp "tie", conform presupunerii de mai sus, despre toate clasele derivate din clasa de baz. O astfel de metod ncalc OCP deoarece trebuie modificat ori de cate ori o nou clas derivat din clasa de baz este creat.

19

LSP
Att n C++ ct i n Java, motenirea se bazeaz pe modelul relaional ISA. Modelul relaional ISA descrie o relaie strict ntre clase, n care membrii unei clase formeaz o submulime a unei alte clase. Modelul ISA (is a) pune n eviden c un obiect (RombA din Fig.3) care aparine unei subclase (clasa Romb din Fig.3), aparine simultan tuturor super-claselor (deci RombA este o instan a lui Romb, dar este n acelai timp instan i a claselor Patrulater i Poligon)

20

Figura 3

21

Utilizarea modelului ISA este considera-t ca fiind o tehnic de baz n Analiza Orientat pe Obiect. S presupunem c la un moment dat, n decursul dezvoltrii unor noi aplicaii, proiectantul are nevoie s utilizeze i ptrate. Deoarece un ptrat este un dreptunghi cu toate laturile egale, putem modela clasa Ptrat prin derivare din clasa Dreptunghi, n conformitate cu modelul ISA relationship. Dar acest mod de a gndi, poate duce la anumite probleme pe care le vom ntmpina cnd trecem efectiv la scrierea codului.
22

Prima problem, i cea mai important, este legat de variabilele Lime i Lungime; pentru a defini un ptrat nu avem nevoie i de amndou, dar clasa Ptrat le va moteni pe amndou. O problem secundar este legat de folosirea eficient a memoriei, mai ales dac se utilizeaz sute de obiecte ale clasei Ptrat (Square).

23

Dar dac pentru a deriva, trebuie modificat clasa de baz, nseamn ca aceasta are o problem de proiectare. Mai mult, acest lucru reprezint o nclcare a OCP, deoarece programul ar trebui s fie nchis pentru modificri.

24

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 autoconsistent i corect. Aceast concluzie ar fi o eroare deoarece un model care este auto-consistent nu este n mod necesar consistent i cu toi utilizatorii si.
25

S considerm urmtoarea funcie:

void g(Rectangle r) { r.setWidth(5); r.setHeight(4); assert ((r.getWidth() * r.getHeight()) == 20) ; }
26

n mod evident aceasta metod funcioneaz corespunztor pentru Rectangle, dar pentru Square genereaz o aseriune fals. Aceasta este o problem grav. Desigur, programatorul care a scris aceast metod a fcut o presupunere ndreptit i anume c modificarea lungimii unui dreptunghi las limea acestuia neschimbat. Funcia g(Rectangle) este un exemplu de funcie care accept referine ctre Rectangle dar care nu funcioneaz corespunztor pentru obiectele din clasa Square. Acest tip de funcii ncalc principiul substituiei al lui Liskov.
27

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. Validitatea unui model se exprim n termenii clienilor si.

28

Validitatea nu este intrinsec

Spre exemplu, n cazul de mai sus cnd s-a examinat versiunea final a claselor Ptrat i Dreptunghi, n mod izolat, s-a ajuns la concluzia c sunt consistente i valide. Totui, examinndu-le din punctul de vedere al unui programator care a fcut respectiva presupunere n legtur cu clasa de baz, s-a ajuns la concluzia c modelul este greit.
29

Deci, pentru aprecierea unui proiect, analiza trebuie s fie fcut ntr-un context i nu n mod izolat. Design-ul trebuie vzut din perspectiva utilizatorilor acestuia; ei lucreaz pe baza unor presupuneri rezonabile asupra modului de funcionare al modelului.

30

Trebuie analizat de ce modelul claselor Square i Rectangle, care prea corect, nu a funcionat. Nu este ptratul un dreptunghi? Nu a funcionat relaia modelului ISA, orice obiect al clasei Square aparine sau nu i clasei Rectangle?

31

Un ptrat poate fi un dreptunghi, dar din punct de vedere strict matematic. Un ptrat ca obiect al clasei Square nu este un obiect Rectangle, deoarece comportamentul unui obiect Square nu este consistent cu comportamentul unui obiect Rectangle, iar clasele tocmai acest aspect trebuie sa-l modeleze: comportamentul.

32

LSP accentueaz faptul c n OOD, modelul relaional ISA se ocup de comportament. Prin comportament se nelege comportamentul public, extrinsec, cel pe care se bazeaz clienii, i nu comportamentul privat, intrinsec al obiectului. Spre exemplu, autorul funciei g(), de mai sus, s-a bazat pe faptul c pentru un obiect al clasei Rectangle, lungimea i limea variaz independent. Aceast independen a celor dou variabile este un comportament public extrinsec pe care, probabil, conteaz i ali programatori.

33

Pentru ca LSP s fie valabil, implicit OCP, toate clasele derivate trebuie s respecte comportamentul pe care clienii l ateapt de la clasa de baz pe care o utilizeaz.

34

Design prin contract

Exist o strns relaie ntre LSP 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.

35

Design prin contract

Regula care se aplic precondiiilor i postcondiiilor la derivare, aa cum a formulat-o B. Meyer este urmtoarea: Cnd se redefinete o metod n clasa derivat, precondiia se nlocuiete prin una mai "slab", iar postcondiia prin una mai "puternic". Cu alte cuvinte, utilizarea unui obiect se face prin intermediul interfeei clasei de baz i utilizatorul cunoate doar precondiiile i postcondiiile acestei clase. Deci, obiectele claselor derivate nu trebuie s impun precondiii mai puternice dect ale clasei de baz, ele trebuie s accepte orice precondiie pe care clasa de baz o accept.

36

De asemenea, clasele derivate trebuie s se conformeze tuturor postcondiiilor clasei de baz, comportamentul i ieirile lor nu trebuie s ncalce nici una din constrngerile impuse de superclas.

37

Concluzii
Respectarea OCP are ca efect obinerea unor aplicaii mai robuste, cu o mai bun mentenabilitate i reutilizabilitate a codului. Principiul substituiei este o caracteristic important a acelor programe/aplicaii care respect OCP, deoarece tipurile derivate pot nlocui tipurile de baz astfel nct codul claselor de baz poate fi oricnd reutilizat i codul claselor derivate oricnd modificat.

38

Concluzii

Substituia claselor de baz cu obiecte ale claselor derivate este posibil, deoarece clasele derivate respect comportamentul extrinsec al superclaselor. Obiectele subclaselor, conform LSP, se comport ntro manier consistent cu promisiunile fcute de superclas. Astfel, claselor client li se furnizeaz un comportament stabil, pe care se pot baza. Mecanismul prin care se implementeaz o structur ierarhic conform cu OCP i LSP este prezentat n Principiul Inversrii Dependenelor.

39