1.3.

Principiile ce stau la baza programării orientate obiect

Fiecare model de programare impune un anumit stil de programare aflat in strânsă

legătura cu conceptele fundamentale ce caracterizează respectivul model. Principalele concepte
ce stau la baza programării orientate pe obiecte sunt:
A) Abstractizarea.
Abstractizarea este una din căile fundamentale prin care noi, oamenii, ajungem sa
înţelegem si sa cuprindem complexitatea, oferind posibilitatea ca un program să ignore unele
aspecte ale informaţiei pe care o manipulează, adică posibilitatea de a se concentra asupra
esenţialului. Fiecare obiect în sistem are rolul unui “actor” abstract, care poate executa acţiuni, îşi
poate modifica şi comunica starea şi poate comunica cu alte obiecte din sistem fără a dezvălui
cum au fost implementate acele facilitaţi. Procesele, funcţiile sau metodele pot fi de asemenea
abstracte, si atunci când sunt, sunt necesare o varietate de tehnici pentru a extinde abstractizarea:
O abstracţiune buna este cea care scoate in evidenta toate detaliile semnificative pentru
perspectiva din care este analizat un obiect, suprimând sau estompând toate celelalte caracteristici
ale obiectului. In contextul programării orientate pe obiecte, Booch ne oferă următoarea definiţie
a abstracţiunii:
“O abstracţiune exprima toate caracteristicile esenţiale ale unui obiect, care fac ca acesta sa se
distingă de alte obiecte; abstracţiunea oferă o definire precisa a graniţelor conceptuale ale
obiectului,din perspectiva unui privitor extern”.
Comportament vs. Implementare.
Aşadar in procesul de abstractizare atenţia este îndreptata exclusiv spre aspectul exterior
al obiectului, adică spre comportarea lui, ignorând implementarea acestei comportări. Cu alte
cuvinte abstractizarea ne ajuta sa delimitam ferm "CE face obiectul" de "CUM face obiectul
ceea ce face".
Modelul Client-Server. Responsabilităţi. Protocol.
Comportarea unui obiect se caracterizează printr-o suma de servicii sau resurse pe care el
le pune la dispoziţia altor obiecte. Un asemenea comportament, in care un obiect, numit server,
oferă servicii altor obiecte, numite clienţi, este descris de aşa-numitul model client-server.
Totalitatea serviciilor oferite de un obiect server constituie un contract sau o
responsabilitate a obiectului fata de alte obiecte. Responsabilităţile sunt îndeplinite prin
intermediul unor operaţii (alte denumiri folosite: metode, funcţii membru). Fiecare operaţie a
unui obiect se caracterizează printr-o semnătura unica, formata din: nume, o lista de parametri
formali si un tip returnat. Mulţimea operaţiilor unui obiect, împreuna cu regulile lor de apelare
constituie protocolul obiectului.

B) Încapsularea.
Încapsularea este conceptul complementar abstractizării. Daca rezultatul operaţiei de
abstractizare pentru un anumit obiect este identificarea protocolului sau, atunci încapsularea are
de a face cu selectarea unei implementări si tratarea acesteia ca pe un secret al respectivei
abstracţiuni. Încapsularea – numită şi ascunderea de informaţii, asigură faptul că obiectele nu
pot schimba starea internă a altor obiecte în mod direct (ci doar prin metode puse la dispoziţie de
obiectul respectiv); doar metodele proprii ale obiectului pot accesa starea acestuia. Fiecare tip de
obiect expune o interfaţă pentru celelalte obiecte care specifică modul cum acele obiecte pot
interacţiona cu el.
 Prin urmare, încapsularea este procesul in care are loc ascunderea implementării fata de
majoritatea obiectelor-client. Determinarea protocolului pentru un obiect trebuie sa preceadă
decizia privind implementarea sa. Sintetizând putem defini încapsularea astfel: Încapsularea este
procesul de compartimentare a elementelor care formează structura si comportamentul unei
abstracţiuni ; încapsularea serveşte la separarea interfeţei "contractuale" de implementarea
acesteia.
Interfaţa vs. Implementare
Din definiţia de mai sus rezulta ca un obiect este format din doua părţi distincte: interfaţa
(protocolul) si respectiv implementarea acestei interfeţe. Abstractizarea este procesul prin care
este definita interfaţa obiectului, in timp ce încapsularea defineşte reprezentarea (structura)
obiectului împreuna cu implementarea interfeţei. Ascunderea structurii obiectului si a
implementării metodelor sale este ceea ce se înţelege prin noţiunea de ascundere a informaţiei.
Beneficiile încapsulării
 Separarea interfeţei de reprezentarea unui obiect permite modificarea reprezentării
fără a afecta in vreun fel pe nici unul din clienţii săi, întrucât aceştia depind de
interfaţa si nu de reprezentarea obiectului-server.
 Încapsularea permite modificarea programelor intr-o maniera eficienta, cu un efort
limitat si bine localizat.
Încapsularea aplică principiul abstracţiei: un obiect nu este accesibil pentru operaţiile
vizibile (interfaţa sa externă) şi implementarea sa (structurile datelor asociate) este ascunsă.
Astfel, modificările datelor rămân locale, la obiecte, fără să afecteze programele utilizatorilor
(fig.1.4).

Aplicaţia 1 Aplicaţia 2

Program Program

Operaţii
Date Operaţii Operaţii
Date Date

Fig.14. Orientarea spre obiecte

Această încapsulare conferă independenţă între programe, operaţii şi date. Un avantaj

imediat este acela că diferitele programe de aplicaţii pot fi partajate pe aceleaşi obiecte fără a
cunoaşte mecanismul de intrare-ieşire (import/export). Principiul încapsulării poate fi uneori
temporar lăsând un acces mai mult sau mai puţin liber datelor dintr-un obiect, făcând posibilă
stabilitatea în timp a alegerii implementării datelor.
Accesul direct al datelor la obiecte este un plus de eficienţă care apelează procedura
impusă de încapsulare. Între timp când implementarea datelor este modificată (de exemplu se
schimbă tipul lor), se va face modificarea în toate programele utilizatoare ale datelor, în mod
direct prin programarea structurată. Decizia de încapsulare se va lua făcându-se un compromis
între performanţă şi flexibilitate. Putem spune că cele două tipuri de orientări permit răspunsul
parţial la problema proiectării structurate.
 C) Modularitatea
"Scopul descompunerii in module este reducerea costurilor prin posibilitatea de a proiecta
si revizui modulele in mod independent" (Parnas & Britton) Clasele si obiectele obţinute in urma
abstractizării si încapsulării trebuie grupate si apoi stocate intr-o forma fizica, denumita modul.
Modulele pot fi privite ca si containere fizice in care declaram clasele si obiectele
rezultate in urma proiectării la nivel logic. Modulele formează aşadar arhitectura fizica a
programului.
Modularizarea consta in divizarea programului intr-un număr de module care pot fi
compilate separat, dar care sunt conectate (cuplate) intre ele. Limbajele care suporta conceptul de
modul fac in acelaşi timp distincţia intre interfaţa modulului si implementarea sa. Putem spune ca
încapsularea si modularizarea merg mana in mana.
Concret, in C++ modulele nu sunt altceva decât fişiere ce pot fi compilate separat.
Practica uzuala este ca interfaţa modulului sa fie plasata intr-un fişier heder (extensii uzuale sunt:
".h" , ".hpp", ".hh"), in timp ce implementarea acestuia se va regăsi intr-un fişier sursa (extensii
uzuale sunt: ".cc", ".cpp", ".c"). Dependentele intre module vor fi exprimate utilizând directivele
"#include".
Reguli Generale de Modularizare
1. Structura fiecărui modul trebuie sa fie suficient de simpla pentru a putea fi complet înţeleasa.
2. Implementarea unui modul trebuie sa depindă doar de interfeţele altor module. Cu alte cuvinte
trebuie sa fie posibila modificarea implementării unui modul fără a avea cunoştinţe despre
implementarea altor module si fără a afecta comportarea celorlalte module.
3. Detaliile sistemului care se presupune ca se vor modifica independent vor fi plasate in module
diferite.
4. Singurele legături intre module vor fi acelea a căror modificare este improbabila.
5. Orice structura de date este încapsulata intr-un modul; ea poate fi accesata direct din interiorul
modulului dar nu poate fi accesata din afara modului decât prin intermediul obiectelor si claselor
conţinute in acel modul.
Din aceasta perspectiva putem înţelege definiţia lui Booch asupra modularităţii [Boo94]:
“Modularitatea este proprietatea unui sistem care a fost descompus intr-un set de module
coezive si slab cuplate”.

D) Ierarhizarea.
Abstractizarea este un lucru bun, dar in majoritatea aplicaţiilor - excepţie făcând doar
aplicaţiile banale - vom descoperi mai multe abstracţiuni decât putem cuprinde la un moment dat.
Încapsularea ne ajuta sa tratam aceasta complexitate prin ascunderea interiorului
abstracţiunilor noastre. Modularitatea ne ajuta si ea, oferindu-ne o modalitate de a grupa
abstracţiuni legate logic intre ele. Toate acestea deşi utile, nu sunt suficiente. Adesea un grup de
abstracţiuni formează o ierarhie, iar prin identificarea acestor ierarhii, putem simplifica
substanţial înţelegerea problemei.
Ierarhizarea reprezintă o ordonare a abstracţiunilor. Cele mai importante ierarhii de clase
in paradigma obiectuala sunt:
o Ierarhia de clase (relaţie de tip "is a")
o Ierarhia de obiecte (relaţie de tip "part of")
 Polimorfismul
Este abilitatea de a procesa obiectele diferit în funcţie de tipul lor sau de clasa lor. Mai
exact, este abilitatea de a redefini metode pentru clasele derivate. De exemplu pentru o clasă
Figura putem defini o metodă arie. Dacă Cerc, Dreptunghi, etc. vor extinde clasa Figura, acestea
pot redefini metoda arie.
 Moştenirea (ierarhia de clase)
Moştenirea – organizează şi facilitează polimorfismul şi încapsularea permiţând definirea
si crearea unor clase specializate plecând de la clase (generale) care sunt deja definite - acestea
pot împărtăşi (şi extinde) comportamentul lor fără a fi nevoie de redefinirea aceluiaşi
comportament. Aceasta se face de obicei prin gruparea obiectelor în clase şi prin definirea de
clase ca extinderi ale unor clase existente. Conceptul de moştenire permite construirea unor clase
noi, care păstrează caracteristicile şi comportarea, deci datele şi funcţiile membru, de la una sau
mai multe clase definite anterior, numite clase de bază, fiind posibilă redefinirea sau adăugarea
unor date şi funcţii noi. Se utilizează ideea: ”Anumite obiecte sunt similare, dar in acelaşi timp
diferite”. O clasă moştenitoare a uneia sau mai multor clase de bază se numeşte clasă derivată.
Esenţa moştenirii constă în posibilitatea refolosirii lucrurilor care funcţionează.
Moştenirea defineşte o relaţie intre clase in care o clasa împărtăşeşte structura si
comportarea definita in una sau mai multe clase (după caz vorbim de moştenire simpla sau
multipla). Aşa cum aminteam mai sus, relaţia de moştenire este cea care face diferenţa intre
programarea orientata pe obiecte si cea bazata pe obiecte.
Semantic, moştenirea indica o relaţie de tip "is a" ("este un/o"). De exemplu un urs "este
un" mamifer si deci intre clasa urşilor si cea a mamiferelor exista o relaţie de moştenire. Si in
cazul programării acesta este cel mai bun test pentru a detecta o relaţie de moştenire intre doua
clase A si B: A moşteneşte pe B daca si numai daca putem spune ca "A este un fel de B". Daca A
"nu este un" B atunci A nu ar trebui sa moşteneasca pe B. Prin urmare, moştenirea implica o
ierarhie de tip generalizare/specializare, in care clasa derivata specializează structura si
comportamentul mai general al clasei din care a fost derivata.
 Agregarea (ierarhia de obiecte)
Agregarea este relaţia intre doua obiecte in care unul dintre obiecte aparţine celuilalt obiect.
Agregarea reda apartenenţa unui obiect la un alt obiect. Semantic, agregarea indica o relaţie de tip
"part of" ("parte din"). De exemplu intre o roata si un automobil exista o astfel de relaţie, întrucât
putem spune ca "o roata este o parte din automobil".