Programare Orientata Pe Obiecte II Bocu

8/10/2019 Programare Orientata Pe Obiecte II Bocu

1/65

Universitatea TRANSILVANIA din BraovFacultatea de Matematic i InformaticCatedra de Informatic Aplicat

Iniiere nprogramarea orientat pe

obiecte din perspectiv Java

Dorin Bocu

REPROGRAFIA UNIVERSITII TRANSILVANIA DIN BRAOV


2/65


3/65

...O parte din eforturile tiinei calculatoarelor sunt dedicate mbuntirii

permanente a paradigmelor de modelare. Prin istoric i prin realizrile de ult im

or, ingineria softului nu face dect s confirme aceast aseriune. Modelarea

orientat pe obiecte este un exemplu remarcabil de instrument, gndit pentru afi utilizat n realizarea de sistem e soft, competitive din punct de vedere alpreului i al calit ii. Programarea orientat pe obiecte ngduie fanilor ei sverifice, n practic, fora unui stil de a modela, a crui capacitate de a mapa

domeniul problemei peste domeniul soluiei este cu mult superioar altor

parad igm e.


4/65

Cuvnt nainte al autorului

Au trecut ani buni de cnd lumea a nceput s ntrebuineze, n vorbire i n alte contexte, sintagmaprogramare obiect orientat sau, ceva mai aproape de spiritul limbii romne, programare orientat peobiecte. Pregtit i anunat de numeroasele controverse pe marginea preamultelor slbiciuni ale vechilor

parad igme de programare, orientarea pe obiecte s-a instala t confortabil de-a lungul ntregului proces dedezvoltare a unui sistem soft, devenind n zilele noastre religia care guverneaz att etapa de modelare aunui sistem soft ct i etapa de implementare. Au aprut limbaje, precum i medii de programare idezvoltare a sistemelor soft, a cror arhitectur este esenial tributar ideii de orientare pe obiecte (Java, C++,C#, Object Pascal cteva exemple mai cunoscute de limbaje, Delphi, C-Builder, Visual C++ - cteva exemplemai cunoscute de medii de programare, Rational Rose, ObjectiF dou dintre mediile de dezvoltare cu bunrspndire n lumea ingineriei softului).

Este clar, orientarea pe obiecte nu este doar o mod n programare, ci o modalitate, fr rival,pentru moment, de a dezvolta sisteme soft.

Pentru informaticienii a cror practic se reduce la apropierea ct mai rapid de tastatur pentru arezolva o problem, orientarea pe obiecte este o ncercare care tulbur minile i ntrzie rezolvareaproblemei. Seriile de studeni care mi-au trecut prin mn mi-au ntrit convingerea c nsuirea spirituluiorientrii pe obiecte este o problem destul de dificil, deoarece, aproape tot ceea ce este reclamat de

obnuinele omului n materie de nvare, este dificil de operaionalizat cnd este vorba de nsuirea acestuispirit. Mult mai apsat dect n alte paradigme, n orientarea pe obiecte, specialistul trebuie s acorde ateniacuvenit elaborrii soluiei nainte de a o implementa . Metodele cele mai rspndite de nvare a limbajelorde programare se bazeaz pe formula:

Prin aplicaii, spre descoperirea subtilitilor sintactice, semantice i pragmatice ale unui limbajde programare.

Cititorul atent a neles faptul c nvarea unui limbaj de programare este un exerciiu de voin carepresupune parcurgerea a trei e taje:

nvarea stereotipurilor sintactice fundamentale ale limbajului (sintaxa limbajului)

Descoperirea unui numr ct mai mare de semantici primitive, care pot fi nvelite cu sintaxa limbajului

(semantica limbajului) Formarea unor deprinderi de utilizare eficient a limbajului, n funcie de natura i complexitatea

problemei, pentru rezolvarea respectivei probleme (pragmatica limbajului).

Ideea cluzitoare a acestui support de curs este de a invita cititorul s nvee singur sintaxaorientrii pe obiecte, ncercnd s l ajute, ndeosebi n efortul de deconspirare a semanticii i pragmaticiiorientrii pe obiecte.

Trimiterile de natur sintactic vor fi raportate la limbajul Java.Trebuie s mrturisesc, totodat, faptul c, n viziunea acestei lucrri, fiecare cititor este o instan

cognitiv activ, capabil de efort permanent de abstractizare, singura modalitate de a ajunge la onelegere superioar a esenei unei paradigme de modelare i, n particular, de programare .

Atitudinea de spectator, cu instinct de conservare puternic, la derularea ideilor din aceast lucrare, esteabsolut contraproductiv pentru atingerea obiectivului fundamental: nvarea ct mai multor elemente -

suport, eseniale pentru modelarea / programarea orientat pe obiecte a soluiei unei probleme .Ce se va ntmpla cu cei care nu se vor putea mpca cu ideea de a se dezmori voluntar, iat o

pro blem n legtur cu care prefer s spun doar att: nu peste mult timp vor descoperi c au mbtrnitnainte de vreme, fr a fi neles mare lucru despre plcerea de a uita de scurgerea timpului, realizndlucruri care s uimeasc, deopotriv, pe alii i pe propriul lor creator .

Referindu-m la studenii pentru care, n principal, am scris aceast lucrare, trebuie s spun c, nviziunea mea, ideea de student se confund cu imaginea unui individ care are apeten pentru studiu .Dac, n facultate, se mai studiaz i discipline care, unora li se par, nefolositioare, datoria studentului este sfac efortul de a se identifica cu ideile fundamentale ale unui numr ct mai mare de discipline, socotite de elfolositoare. Dac, n facultate, studenii se mai ntlnesac i cu profesori ale cror cutri nu sunt nc suficientde bine sistematizate, acesta nu este un motiv de a renuna la dorina de a cunoate.

De la natur, studentul poate fi asimilat cu un obiect care are toate capabilitile necesare pentru aparcurge drumul dificil, dar pasionant, al cunoaterii elementelor fundamentale, n diferite ramuri ale

matematicii i tiinei calculatoarelor .


5/65

A aminti, tuturor celor care nu au realizat nc, faptul c omul are nevoie de tiin pentru a nelege oparte din realitatea necunoscut (rezult c tiina are funcie explicativ), pentru a modela comportamentulunor fenomene i procese din realitatea obiectiv, n vederea optimizrii dinamicii lor (rezult c tiina arefuncie modelatoare), pentru a mbogi realitatea obiectiv cu obiecte artificiale(rezult c tiina are funciedemiurgic).

Sper ca cititorul s neleag bine rolul activ pe care trebuie s i-l asume n deconspirarea, prin studiuindividual i exerciii perseverente, a etajelor sintactice eseniale programrii n Java.


6/65

1 Cum se explic permanenta nevoie de paradigmenoi n ingineria softului. Ce nelegem prinorientarea pe obiecte

1.1 Cum se explic permanenta nevoie de paradigme noi n ingineriasoftului?

Binefacere sau blestem, omenirea este, asemenea ntregului univers, ntr-o continu deplasare spre alterepere ontologice i gnoseologice. Avea dreptate Heraclit din Efes cnd, folosind cuvinte meteugit alese,constata c singura certitudine a universului pare a fi devenirea . Dac, acum peste 2500 de ani n urm,devenirea ocupa o poziie central n modul de gndire al lui Heraclit, n zilele noastre devenirea s-a transformatn izvor nesecat i cauz a tuturor transformrilor importante pe care le suport universul cunoscut omului. S-ar

prea c nimic din ceea ce face omul nu dureaz. Acest fapt este , dup ascuimea simurilor noastre, n opoziiecu ceea ce Natura sau Marele Creator fac. Omul aspir la eternitate luptnd cu efemerul inerent alcreaiilor lui. Marele Creator este eternitatea nsi. Las pe seama filozofilor continuarea efortului de preamrire

sau punere la index a rolului pe care l joac devenirea n viaa omului i, de ce nu, n univers.Caracterul obiectiv al devenirii poate explica, n genere i nevoia de paradigme 1noi n ingineria softuluii, n particular n programare.

*Permindu-mi o scurt digresiune, ingineria softului este o ramur a tiinei calculatoarelor care se

ocup, la urma urmei, de studierea unei probleme extrem de delicate: Dat o problem oarecare, ce trebuiefcut pentru a o rezolva cu ajutorul calculatorului?

Confruntai de-a lungul timpului, cu diferite tipuri de probleme, specialitii n ingineria softului au fcuto descoperire banal:

Efortul depus pentru a rezolva o problem cu ajutorul calculatorului este direct proporional cucomplexitatea problemei.

Odat fcut aceast descoperire iese la iveal alt ntrebare: Cum definim complexitatea uneiprobleme? Atenie, cititorule, este vorba de complexitatea unei probleme nu de complexitatea soluieialgoritmice a unei probleme.

Complexitatea unei probleme este o caracteristic intrinsec a enunului asumat al acesteia.Complexitatea soluiei algoritmice a unei probleme este o caracteristic intrinsec a modului n care o

anumit instan cognitiv (de pild un student din anul II) obine respectiva soluiie algoritmic.Este, sper, ct se poate de clar faptul c cele dou tipuri de complexitate cuantific caracteristicile

structurale ale unor colecii de obiecte, diferite din punct de vedere al sferei de cuprindere i al coninutului.Cei care au parcurs unul sau mai multe cursuri de iniiere n Algoritmic i Programarei amintesc,

pro babil, nelesul pe care l are complexi tatea unui algoritm. Formalizarea matematic a complexiti ialgoritmilor este un prilej minunat de a ilustra fora de analiz a matematicii de puterea continuului, aplicatuniversului algoritmilor, al cror comportament este eminamente discret.

Este corect s evideniem, n acest punct, utilitatea teoretic i practic (ndeosebi n cazul aplicaiilor

critice relativ la complexitatea algoritmilor folosii) a eforturilor de clasificare a algoritmilor secveniali iparaleli, n funcie de complexitatea lor Acest gen de afirmaii sunt prezentate n toat cup rinderea i adnc imealor n cri fundamentale pentru nvrea programrii calculatoarelor2.

Ingineria softului (IS) ia act de aceast realitate i, n replic, i concentreaz atenia asupracomplexitii problemelor . O ncercare de a evidenia elementele cu ajutorul crora putem descriecomplexitatea unei probleme n ingineria softului ne conduce la seria de observaii de mai jos.

Rezolvarea unei probleme cu ajutorul calculatorului nseamn, de cele mai multe ori, simularea /asistarea de ctre calculator a unor activiti, desfurate de ctre sisteme de alt natur. Aadar,aproape invariabil, ne aflm n faa unor dificulti care rezult din caracterul instabil al relaieidintre model i sistemul modelat . Neglijarea acestui aspect simplific efortul de realizare, n cele din

1

Este cazul s spun em c, prin paradigm se nelege, fr a exagera cu explicaiile, un mod de abordare a problemelor dintr-un anumitdomeniu, evident, cu scopul de a rezolva aceste probleme. Poate c limba romn nu avea neaprat nevoie de acest cuvnt, dar insistena cucare este utilizat n alte pri poate fi considerat o scuz pentru utilizarea lui n aceast carte.2Knuth, Cormen
http://-/?-http://-/?-


7/65

urm, a unui sistem soft, dar preul pltit este exprimat, sintetic, astfel: uzur moral rapid iposibiliti de adaptare reduse . Se poate lupta cu mijloace raionale mpotriva caracterului instabil alrelaiei dintre model i sistemul modelat? Rspunsul este: da, se poate lupta, dac specialistul n IS estedispus s anticipeze impactul posibilelor schimbri ale sistemului modelat asupra soluiei (modelului). Anticipnd schimbrile sistemului modelat, simplificm efortul de adaptare a soluiei laaceste schimbri.

Modelul care st la baza soluiei unei probleme abstractizeaz viziunea specialistului sau grupului despecialiti n IS, asupra sistemului modelat. Semn al posibilitilor noastre limitate de a cunoate, oriceviziune nu poate dect s aproximeze comportamentul sistemului modelat. Chiar i n aceste condiii,de la a aproxima defectuos pn la a aproxima inspirat este nu doar un drum lung ci i plin dediverse tipuri de ncercri. Exemple de astfel de ncercri:

specificarea complet a cerinelor funcionale; acordarea ateniei cuvenite cerinelor non-funcionale;

alegerea inspirat a modalitilor de armonizare a cerinelor contradictorii;

alegerea inspirat a paradigmei de modelare, etc.

Trecerea, cu succes, peste dificultile schiate mai sus este realizat n condiii ergonomice dacmanagementul acestor dificulti (plus nenumrate altele) este tratat cu maximum de seriozitate i

competen.

ncercnd s form o concluzie, complexitatea unei probleme n IS este influenat de:

1. Stabilitatea relaiei model-sistem modelat; lipsa de stabilitate n aceast relaie, asumat contient,induce creterea complexitii problemei de rezolvat.

2. Complexitatea structurii sistemului modelat (creterea acesteia induce, de asemenea, cretereacomplexitii problemei de rezolvat).

3. Desfurarea n condiii de eficien a procesului de rezolvare a unei probleme, adaug un plus decomplexitate oricrei probleme. Neasumndu-se acest plus de complexitate, putem uor compromite

procesul de rea lizare a unui sistem soft (=soluia executabil pe un calculator rea l a unei probleme date).

Un management bun are de rezolvat probleme de procurare i alocare optim a resurselor, comunicarentre partenerii de proiect (=specialitii n IS, beneficiarii, utilizatorii), lansare cu succes pe pia (daceste cazul), etc. Nu a sftui pe nici un specialist n IS s considere normal o afirmaie de genul: Daccele spuse la punctul 2 sunt tratate cu maximum de seriozitate i competen, 1 i 3 nu mai nseamnmare lucru. ndeosebi n cazul proiectelor mari, s-a dovedit, de nenumrate ori, neadevrul unei astfelde afirmaii.

n IS, complexitatea problemelor nu este un accident; mai mult, putem spune c este legitim s neateptm la elemente de complexitate chiar i acolo unde s-ar prea c acestea sunt lips . Dac maiamintim cititorului observaia tendenioas, potrivit creia complexitatea de calitate se ntemeiaz pesimplitate , acesta nelege mai bine insistena cu care prezint implicaiile complexitii unei probleme asupracalitii soluiei acestei probleme. Calitate? Complexitate3? Complexitate de calitate? Multe se mai pot spune.Specialistul n IS dorete s tie cteva lucruri simple:

Care sunt primejdiile? Care sunt exigenele? Cum se poate evita un eec?, etc.

Astfel de ntrebri, ne vom pune, ntr-o form sau alta i n aceast lucrare de iniiere n programareaorientat pe obiecte i le putei gsi reluate n crile Iniiere n ingineria sistemelor soft i Iniiere nmodelarea obiect orientat a sistemelor soft utiliznd UML , scrise de D. Bocu i aprute la EdituraAlbastr .

Nevoia p resant de a cuta, permanent, rsp unsuri noi la astfel de ntrebri , justific ava lana de nouticare caracterizeaz i lumea limbajelor de modelare, specifice ingineriei softului.

3Orice exerciiu de m odelare urmrete, indi ferent de acuitatea mijloacelor de investigaie, un anu mit mod de organizare a com plexitiisistemului modelat.
http://-/?-


8/65

= + +

1.2 Ce se nelege prin orientarea pe obiecte?S-au scris destule cri pe tema orientrii spre obiecte. i mai multe sunt, probabil, articolele din

revistele de specialitate. Unele, foarte convingtoare. Altele mai puin. Nu cred c voi umple, brusc, golul caremai exist, nc, n limba romn, scriind aceast carte. Dar voi ncerca s fac neles modul de gndireal unuispecialist n IS, care vede realitatea informaional n termeni specifici orientrii spre obiec te.

Orice sistem informaional

4

este mai uor de neles dac avem elemente suficiente referitoare ladatele vehiculate n sistem, procedeele de prelucrare (vehiculare) a datelor din sistem, interfeele sistemuluicu mediul n care acesta opereaz. Fiecare dintre elementele specificate mai sus are reguli proprii de organizarei fiinare. n plus, mai exist i relaiile strnse dintre aceste elemente. De fapt, ntreaga istorie a IS se nvrte n

jurul ecua iei prezentat n Figura 1.

Figura 1. Ecuaia general a soluiei unei probleme n IS.Ecuaia de mai sus a primit de-a lungul timpului numeroase rezolvri.

*nainte de a descrie tipurile fundamentale de rezolvri, voi efectua o scurt trecere n revist a

vocabularului IS, esenial n comunicarea dintre partenerii unui proiect de dezvoltare a unui sistem soft.

Prin urmare, o firm productoare de soft produce i livreaz produse i servicii care se adreseaznevoilor i cerinelor clienilor. Cerinele clienilor constitue un exemplu de problem cu care trebuie s seconfrunte echipa de dezvoltare. Produsele i serviciile care satisfac aceste cerine pot fi considerate ca fiindsoluii. Pentru a livra soluii valide (= de calitate, la pre de cost redus i n timp util) firmele trebuie s fac

permanent achiziie, comunicare (partajare) i utilizare de cunotine specifice referi toare la domeniulproblemei de rezolvat. Pentru a discrimina i comunica eficient informaiile necesare pentru rezolvarea unei

pro bleme, firmele folose sc tehnologii adecvate. O tehnologie este, n general vorbind, un instrument pe caremembrii echipei de dezvoltare trebuie s nvee s-o foloseasc la ntregul ei potenial.

Aadar, problema de rezolvat, la care se adaug necesitatea de a nva modul de utilizare atehnologiilor necesare n rezolvarea problemei, ne permit o imagine, nc optimist, asupra complexitiiefortului de realizare a unui sistem soft . Amplificarea acestei complexiti este motivul pentru care ntregulefort de realizare a unui sistem soft este structurat sub forma unui proiect. n cadrul unui proiect se desfoar,dup reguli precise, toate activitile necesare pentru a asigura succesul efortului de realizare a unui sistem soft.Dou dintre dimensiunile eseniale pentru succesul unui proiect sunt limbajul de modelare folosit i tipul deproces utilizat pentru a materializa fora limbajului de modelare. Despre toate acestea, mai multe aspecte lacursul care i propune iniierea studenilor n ingineria sistemelor soft.

*

Revenind la ntrebarea de baz a acestui paragraf, s observm c, nc de la apariia primelorcalculatoare, a aprut o nou dilem n faa omenirii:

Cum putem nva calculatoarele s ne rezolve n mod optim problemele?

La nceput, cnd calculatoarele erau folosite exclusiv pentru rezolvarea unor probleme cu caratertiinific, soluia era programarea n cod main. Dificultile de baz n rezolvare acestor tipuri de

probleme erau dou :elaborarea modelelor matematice i transpunerea lor n cod main . Mai alesprogramarea n cod main, era un gen de exerciiu la care nu se ngrmdeau dect indivizi care manifestauun interes ieit din comun pentru sistemele electronice de calcul din acea generaie. Apariia limbajelor deasamblare a generat o relaxare a cortinei de fier instalat de codul main ntre calculatoare i mareamas a curioilor. O relaxare asemntoare s-a produs i n ceea ce privete tipurile de problemeabordabile cu ajutorul calculatoarelor. Era momentul n care intrau pe scen aplicaiile de gestiune, datorit

4Ca i realitatea informaional, sistemul informaional desemneaz un ansamblu de resurse care optimizeaz fluxurile informaionale dintr -un sistem gazd. Pentru o documentare mai atent invit cititorul s rsfoiasc atent o carte bun de ingineria softului.
http://-/?-


9/65

Problem(activitate-sistemreal al cruicomportamenttrebuie modelat)

DATE

PRELUCRRI

apariiei memoriilor externe. Locul datelor simple ncepe s fie luat de date structurate i din ce n ce maivoluminoase. Presiunea exercitat de cererea crescnd de aplicaii de gestiune a impus trecerea la limbajelede nivel nalt i mediu. n paralel, cu deosebire n faa proiectelor uriae (controlul traficului aerian,gestiunea tranzaciilor unor bnci, informatizarea tot mai multor activiti ale intreprinderilor industriale)apare nevoia disciplinrii procesului de derulare a acestor proiectedin faza de specificare a cerinelor,trecnd prin faza de analiz, continund cu proiectarea soluiei i terminnd (grosier vorbind) cu

programarea.De unde aceast nevoie de disciplinare? Foarte simplu, complexitatea problemelor (parc am maiauzit undeva despre acest lucru) nu mai putea fi stpnit lucrnd fr metod . Astfel au aprut, de-alungul timpului, tot felul de mode n ceea ce privete abstractizarea soluiei i nu numai .

Managementul unui proiect trebuie s aib, permanent, n vizor, cel puin, asigurarea limbajului demodelare adecvat i a modelului de dezvoltare optim5. De la moda programelor-mamut (singura posibil nvremea programrii n cod main) s-a ajuns treptat la nevoia modularizrii (= descompunerea problemei iniialen subprobleme, eventual aplicarea repetat a acestui procedeu, obinndu-se nite piese ale soluiei numitemodule, care, asamblate, compuneau, n sfrit soluia). ntrebarea care a furnicat, ani la rnd, creiereleteoreticienilor i practicienilor, deopotriv, era:

Care sunt criteriile dup care se face modularizarea unei soluii?

Figura 2. Perspectiva clasic asupra relaiei dintre date i prelucrri n structura uneisoluii

Exist o serie de factori externi ai calitii unui sistem soft care in sub presiune tendina de amodulariza de amorul artei, precum: corectitudinea, robusteea, reutilizabilitatea , portabilitatea , etc. Existi o serie de factori interni ai calitii unui sistem soft, care preseaz, n egal msur, precum: structurareasoluiei, claritatea algoritmilor, calitatea arhitecturii, etc.

Meninerea n echilibru a acestor factori de presiune este o sarcin extrem de dificil. n cele dinurm, cercettorii au ajuns la concluzia c, din punct de vedere al celui care lucreaz, materializarea acestorfactori la parametri satisfctori sau marginalizarea lor, depind de decizia luat n ceea ce privete relaiadintre date i prelucrri n procesul de modularizare a soluiei unei probleme. Istoria ne arat c au existatteoreticieni i practicieni ncredinati c singura metod de modularizare valid este modularizarea dirijat dedate(altfel spus, nainte de a te ocupa de organizarea prelucrrilor, rezolv, n mod optim, problema organizriidatelor; din schema de organizare a acestora se va deriva i schema de structurare a prelucrrilor). Tot istoria nearat c au existat i teoreticieni i practicieni ncredinati c singura metod de modularizare valid estemodularizarea dirijat de prelucrri(altfel spus, ocup-te, mai nti, de organizarea prelucrrilor i, mai apoi,f rost de datele necesare i organizeaz-le conform cerinelor prelucrrilor). Curnd s-a observat c dihotomiadate-prelucrri nu este benefic sub nici o form. A existat o soluie de compromis (modularizarea dirijatde fluxurile de date), care s-a dovedit n timp nesatisfctoare n numeroase situaii din realitate. Din punct devedere al criticilor fundamentale care se pot formula la adresa acestor abordri esena este urmtoarea: Dacsoluia unei probleme nseamn ansamblul date-prelucrri, fiecare component avnd o existen relativautonom i reguli proprii de organizare, atunci avem situaia din Figura 2.

5Mai multe detalii n aceast privin n cartea Iniie re n ingin eria sistemelor soft, D . Bocu, Editura Albastr , Clu j-Napoc a, 2002
http://-/?-


10/65

Esenial n mesajul transmis de Figura 2 este faptul c datele sunt sficient de izolate de prelucrripentru ca o modificare n structura unei componente s dea uor peste cap structura celeilaltecomponente.

Conform paradigmelor caracterizate n Figura 2, era posibil o caracterizare de tipul celei prezentatepentru problema de mai jos.

Problema 1: S se realizeze un sistem soft care simuleaz deplasarea unui om pe o suprafaplan.

Dac a fi un partizan al modularizrii dirijate de date, mai nti mi-a pune urmtoarele ntrebri: caresunt atributele informaionale care caracterizeaz un om (stilizat convenabil, s spunem)?. Cum se caracterizeazun plan? Cum se memoreaz intern i extern datele despre aceste obiecte? Dup ce am distilat satisfctorlumea datelor, ncep s m ocup i de lumea prelucrrilor necesare n jurul acestor date. Obin, inclusiv nviziunea limbajelor de programare suport, dou lumi, care interfer, dar au reguli de organizare i reprezentare nmemorie distincte. Mai trist, legtura dintre date i prelucrri este o problem care se gestioneaz prinprogramare, ca i cnd nu ar fi suficiente problemele celelalte. Ce ne facem, ns, dac apare necesitateasimulrii deplasrii unei vieuitoare n genere, pe o suprafa plan? Pentru fiecare vieuitoare n parte iautravaliul de la capt? Posibil, dar total contraindicat din multe puncte de vedere( pre de cost, extensibilitate,ncadrare n termenele de execuie, etc.). Este limpede, reformulat ca mai sus, enunul problemei ne pune n faa

sarcinii de a modela comportamentul unor obiecte, heterogene ca tip, dar ntre care exist afiniti, att de naturinformaional ct i comportamental. Astfel apare, ceea ce n modelarea obiect orientat se numete problemagestiunii similaritilor unor colecii de obiecte . Gestiunea corect a similaritilor unei colecii de obiecte,heterogene din punct devedere al tipului definitor,se realizeaz desfurnd n

paralel efort de clasificarei, acolo unde este cazul,ierarhizare cu ajutoruloperaiilor degeneralizare / specializare.Cum arat lumea privit dinaceast perspectiv?

Simplificnd intenionat,cam ca n Figura 3.

Nu voi da, nc,nici o definiie, dar voi faceo serie de observaii pe carele voi aprofunda ncapitolele urmtoare.

Figura 3. Perspectiva orientat pe obiecte a soluiei unei probleme

1.

Se insinueaz faptul c soluia orientat pe obiecte a unei probleme se obine n urma unui demers deorganizare a unor obiecte, care au att proprieti informaionale ct i comportament (se manifest,astfel, ntr-un cadru absolut natural, un mai vechi principiu utilizat n modelare i anume principiulncapsulrii datelor i prelucrrilor. ncapsulare facem i n Pascal, cnd scriem unit-uri care furnizeazanumite servicii unor categorii bine definite de utilizatori. Aceste unit-uri au interfa i implementare.

Manifestarea principiului ncapsulrii, n acest cadru, nsemna ascunderea detaliilor deimplementare fa de utilizatori, prin publicarea unei interfee stabile. O interfa este stabil dac utilizatorulei nu sesizeaz eventualele modificri aduse implementrii interfeei . 6

6 Manifestarea principiului ncapsulrii, n acest cadru, nsemna ascunderea detaliilor de

implementare fa de utilizatori, prin publicarea unei interfee stabile. O interfa este stabil dac utilizatorulei nu sesizeaz eventualele modificri aduse implementrii interfeei.

Problem(activitate-sistemreal al cruicomportamenttrebuie modelat)

C1

C11 C12

C111

C121 C122

Soluia orientat pe obiecte a problemei
http://-/?-


11/65

2. n sfrit, aplicnd riguros principiul ncapsulrii, putem defini clase de obiecte care au o importan

esenial pentru maparea domeniului problemei peste domeniul soluiei. Exist, ns, numeroase alteraiuni pentru care principiul ncapsulrii se aplic conjugat cu alt principiu important n modelareaorientat pe obiecte: principiul motenirii. Aplicarea acestui principiu ne ajut s raionalizmredundanele care apar, n mod inerent, n procesul de elaborare a unei soluii n genere . Mai

mult, principiul motenirii pregtete terenul pentru rezolvarea unor probleme interesante care in depolimorfism i genericitate. Exemp lul de referin n aceast privin este Java.

Fr a mai insista prea mult, s desprindem concluzia care se impune evident la acest nivel deprezen tare : Modelnd orientat pe obiecte, asigurm maximum de coresponden posibil ntre obiectelecare populeaz sistemul modelat i obiectele care dau, practic, via soluiei . Lucru absolut remarcabil,deoarece principiul ncapsulrii (temelie a modularizrii de calitate n orientarea pe obiecte) introduce elementede stabilitate deosebit a soluiei chiar i n situaia n care apara modificri n sfera domeniului problemei.

Prpastia dintre date i prelucrri este nlocuit de reguli precise de asociere a datelor iprelucrrilor, pentru a descrie tipuri de obiecte ntlnite n domeniul problemei i care sunt importantepentru economia de resurse a soluiei.

Din aceast perspectiv privind lucrurile, este evident faptul c modelarea orientat pe obiecte estealtceva dect modelarea clasic (indiferent de nuan). Desluirea acestui altceva, la nivel de sintax,semantic i pragmatic (prin raportare la un limbaj de programare) ne va preocupa n continuare . Ceicare se grbesc s abordeze i specificul modelrii orientate pe obiecte, abstracie fcnd de limbajele de

pro gramare- suport pen tru implementare, pot consu lta lucrarea Iniiere n modelarea obiect orientat utilizndUML7.

7D. Bocu, Editura Albastr, Cluj-Napoca
http://-/?-


12/65

2 Concepte i principii n programarea orientat peobiecte

2.1 Concepte n programarea orientat pe obiectencepnd cu acest capitol, orientarea pe obiecte va fi privit, nu de la nlimea preceptelor ingineriei

softului, ci din perspectiva programrii Java. Subliniez, nc odat, marea provocare pentru un programatorcare ncearc fora unui limbaj n materie de obiect orientare nu este n sintax, semantica asociatdiferitelor tipuri de enunuri sintactice sau stilul de codificare, ci nsuirea spiritului orientrii pe obiecteaa cum este el promovat de elementele suport ale limbajului.

De aceea, reamintesc cititorului contient faptul c va trebui s se ntrebuineze serios pentru a descifra,dac mai este cazul, oferta limbajului C++ n ceea ce privete: tipurile fundamentale de date (similaritiremarcabile cu Java, dar i deosebiri, datorate n principal faptului c n C++ pointerii se manifest cu foartemult vigoare n cele mai neateptate contexte), reprezentarea structurilor de prelucrare (din nou, similaritiremarcabile ntre C++ i Java), operaiile I/O relative la consola sistem, din perspectiv C, precum i suportul C

pentru lucrul cu fluxur i, dac se dore te acest lucru. Nu voi spune dect urmtoarele: C++ este un superset allimbajului C; compilatoarele de C++ sunt realizate astfel nct toate enunurile din C sunt acceptate, darele recunosc i o varietate mare de enunuri specifice modului de lucru n orientarea pe obiecte .

Dup cum rezult din titlul acestui paragraf, n atenia mea se vor afla enunurile tipice programriiorientate pe obiecte n Java.

nainte de a ajunge la aceste enunuri, trebuie s facem primii pai n nvarea spiritului orientrii peobiecte. Voi prezenta, n continuare conceptele fundamentale de care ne lovim frecvent cnd programmorientat pe obiecte.

Spuneam n Capitolul 1 c, din perspectiv orientat pe obiecte, sistemul pe care l modelm va fintotdeauna abstractizat de o colecie de tipuri de obiecte, ntre care exist anumite relaii. S ne imaginm, deexemplu, c vrem s modelm lumea poligoanelor astfel nct s putem oferi suport pentru nvareaasistat de calculator a proprietilor poligoanelor . Exist o mare diversitate de poligoane. Chiar i cele caresunt de maxim interes din punct de vedere al predrii/nvrii n coal, sunt suficient de multe pentru a pune

pro bleme de abordare a prezentrii proprieti lor lor. i n acest caz , ca n oricare altul, la nceput avem n faaochilor realitatea de modelat, care poate fi sau nu structurat dup legile ei naturale.Pentru un individ cu pregtire matematic adecvat este evident c obiectele din Figura 4 sunt

clasificate aprioric. Eventual, putem spune c lipsesc unele tipuri de poligoane, pentru c inventarul fcut de noin Figura 4 esteincomplet.

Figura 4. Diferite tipuri de poligoane, aa cum se pot ntlni, n realitatea modelat, prinreprezentani

Probleme noastr nu este de a stabili nite frontiere nuntrul crora s avem obiecte de acelai tip, ci dea spune care sunt obiectele care nu ne intereseaz. Nu se ntmpl, ntotdeauna, aa. Exist probleme n careefectiv trebuie s depunem eforturi pentru a clasifica obiectele.

Operaia de clasificare presupune identificarea unor categorii de obiecte, apelnd, simultan laomiterea unor detalii, socotite nesemnificative, pentru a obine efectul de similaritate n procesul decaracterizare a obiectelor.


13/65

Dac n atenia noastr se afl problema clasificrii poligoanelor, atunci, dac n caracterizarea unui

poligon reinem atribu te precum: lista coordonatelor vrfurilor , definiia() , aria(), perimetrul(), atuncirezultatul clasificrii este o clas de obiecte pe care o putem numi clasa Poligon. Astfel c putem da definiia demai jos.

De finiia 1 Se numete clas o colecie de obiecte care partajeaz aceeai list de atributeinformaionale i comportamentale.

Prin urmare, primul concept important cu care ne ntlnim n programarea orientat pe obiecte esteconceptul de clas. Rezolvarea orientat pe obiecte a unei probleme se bazeaz esenial pe abilitateaspecialistului (n cazul nostru programatorul) de a descoperi care sunt clasele pe baza crora se poate construisoluia. Presupunnd c avem i noi aceast abilitate i, n acord cu criteriile proprii de clasificare (reflectate i ninventarul din Figura 4), obinem urmtoarea colecie de clase candidatela obinerea soluiei problemei noastre.

Figura 5. Clasele candidate la obinerea soluiei pentru problema modelrii poligoanelor

Departe de mine ideea c am dat o soluie definitiv problemei clasificrii poligoanelor. Am prezentat,ns, o soluie tributar unei anumite viziuni. n conformitate cu aceast viziune, singurele poligoane care

prezint interes pentru noi sunt triunghiurile , patrulaterele i romburile . Figura 5 ne atrage atenia , exp licit ,asupra diversitii tipologice a patrulaterelor, fapt care evideniaz necesitatea recurgerii i la alt operator dectclasificarea pentru a gestiona aceast diversitate. Situaia este, oarecum asemntoare i n cazul triunghiurilor,dar nu am subliniat explicit acest lucru.

Fcnd abstracie de aceste elemente, deocamdat, s revenim asupra problemei care ne intereseaz celmai mult n acest moment: cum stabilim proprietile unei clase?

Regulile de baz n stabilirea proprietilor unei clase sunt urmtoarele: Lista atributelor informaionale ale unei clase este, ntotdeauna, rezultatul unui compromis ntre

necesitatea unui maximum de informaii despre obiectele clasei respective (informaii, care, nfond, caracterizeaz starea obiectelor din clasa respectiv) i necesitatea unui minimum deredundane acceptate. Obiceiul unor programatori de a supradimensiona lista atributelor uneiclase pe motiv c mai bine s fie dect s le ducem lipsa, nu este un model de urmat, nici atuncicnd exist memorie cu carul.

Odat specificate, atributele trebuie declarate ca fiind resurse private ale clasei, folosind

sintaxa specific limbajului pentru ascunderea unei resurse. Dogma orientrii pe obiecte nlegtur cu lista atributelor este c acestea sunt accesibile, diferitelor categorii de clieni, nsetare ca i n consultare, prin intermediul unor metode speciale de setare(numite imodificatori) sau consultare(numite i selectori), crora li se mai adaug metode speciale

Clasa patrulaterelor

Clasa triunghiurilor Clasa hexagoanelor


14/65

implicate n crearea obiectelor unei clase (constructorii), respectiv, eliminarea acestor obiecte(destructorii). Evident, mai exist i alte tipuri uzuale de metode, precum iteratorii sau indexatorii,crora li se acord o atenie special n C#.

Odat specificat lista atributelor informaionale se poate trece la specificarea listei operaiilorclasei, list care abstractizeaz comportamentul clasei. n procesul de specificare acomportamentului unei clase trebuie avute permanent n vedere cele dou dimensiuni ale

comportamentului unei clase: comportamentul reclamat de gestiunea strii obiectelor (crearealor, setarea valorilor atributelor, modificarea valorilor atributelor, consultarea valorilor atributelor,distrugerea obiectelor) precum i comportamentul reclamat de relaia clasei n cauz cu alteclase. Lista operaiilor unei clase, la nevoie, poate fi organizat, din punct de vedere al modului deacces la aceste operaii. Un singur lucru este general valabil n aceast privin: faptul c oriceclas trebuie s afieze o list cu operaiile publice, care asigur accesul clienilor la serviciileoferite de clas. Lista acestor operaii se numete, n mod normal, interfaa clasei.

Atenie, cititorule! Cnd specifici resursele unei clase, eti preocupat s spui ce fac obiectele claseirespective, omind intenionat cum face clasa ceea ce trebuie s fac . Aadar, nu stric s facemo distincie necesar ntre definirea unei clase (= specificarea atributelor i a operaiilor) iimplementarea clasei (= scrierea codului asociat operaiilor clasei). Definirea rspunde unorcomandamente externe (ce in de modul de utilizare a obiectelor clasei); implementarea rspundeunor comandamente care in de intimitatea comportamentului obiectelor (mod de reprezentare n

memorie a obiectelor, mod de implementare a operaiilor n acest context). S mai adugm c ooperaie implementat se mai numete i metod.

Folosind notaia UML pentru reprezentarea vizual a proprietilor unei clase, avem situaia din Figura6.

Un concept, inevitabil n programarea orientat pe obiecte este i conceptul de obiect. L-am folosit,deja, la modul intuitiv, ca fiind o parte a unei realiti avnd o anumit valoare de ntrebuinare n contextul ncare apare. Acum este momentul s dm urmtoarea definiie.

De finiia 2. Se numete obiect o instan a unei clase .

De la teoria general a tipurilor de date, se tie c instana unui tip de dat este o variabil avnd o

anumit reprezentare n memorie, deci o identitate, i o anumit stare din punct de vedere al coninutuluimemoriei asociate. n toate limbajele de programare, care ofer suport orientrii pe obiecte, clasa este asimilatunui tip de dat (este drept un tip special), care devine folositor n momentul n care se manifest prinintermediul instanelor. Instanele unei clase se vor numi, aadar, obiectesau, uneori, variabile obiect.

Dogmatic vorbind, dac soluia unei probleme este modelat ca o singur clas, atunci ne ateptm cadinamica aplicaiei corespunztoare s fie opera comportamentului unei instane a clasei . Ce se ntmpl,ns, dac soluia unei probleme este abstractizat de o ierarhie sau de o reea de clase? n acest caz, dinamicaaplicaiei este opera colaborrii ntre instaele unora dintre clasele ierarhiei sau reelei n cauz . Semanticvorbind, modul n care colaboreaz mai multe obiecte pentru a rezolva o anumit problem, este greu de fixatntr-o formul definitiv. Din punct de vedere tehnic, ns, rezolvarea este relativ simpl, dup cum se poatededuce i din Figura 7.

Figura 6. Notaia UML pentru o clas

Lis ta atribute lor inform aionale ,

speci ficate prin nume, tip i eventualvaloare implicit

Lis ta opera iilor , specifica te prin

signatur


15/65

Figura 7.Exemplu de comunicare(colaborare) ntre dou obiecte

Notaia UML8 pentru o clas i nelesul complet al noiunii de signatur9 pot fi urmrite, lund-onaintea timpului, consultnd lucrarea [Iniiere n modelarea obiect orientat utilizn d UML, Dorin Bocu,

Editura A lbastr, Cluj-Napoca, 2002]n Figura 7 se prezint schema fundamental pentru colaborarea dintre obiecte. Unul dintre obiecte

(obiectul de tip Produs, n cazul nostru) iniiaz comunicarea cu cellalt obiect (de tip Furnizor, n cazulnostru). Se mai obinuiete s se spun c obiectul de tip Produsi-a trimis un mesajobiectului de tip Furnizor.Este de ateptat ca, ntr-o form sau alta, mesajul s fie urmat de un rspuns. Aadar, dac OFurnizor este ovariabil de tip Furnizori dac aceast variabil este accesibil unui obiect de tip Produs, atunci comunicareaeste posibil, cu condiia ca obiectil de tip Produs s cunoasc interfaa clasei definitoare a obiectuluiOFurnizori s aib acces la aceast interfa. n varianta cea mai simpl, un mesaj are structura:

.([]);

ceea ce ne ndreptete s dm definiia de mai jos.

Definiia 3. Se numete mesaj apelul unei metode a unui obiect, apel efectuat de ctre un clientpotenial al obiectului n cauz .

Cunoaterea acestui fapt este deosebit de important n situaia n care vrem s explicm semanticapolimorfismului n pro gramarea orientat pe obiect, ceea ce vom face n partea urmtoare a acestui capitol .

n sfrit, s mai menionez faptul c rspunsul pe care l d un obiect cnd primete un mesaj de la altobiect depinde de starea n care se afl obiectul care primete mesajul. Este un aspect asupra cruiaprogramatorul trebuie s fie atent, deoarece o stare improprie a obiectului destinatar, poate provocaeuarea iniiativei obiectului expeditor de a comunica . Multe excepii apar, n faza de testare a programelor,

8UML-prescurtare de la Unified Modeling Language-Limbaj de modelare unificat, specificat de Rational Software Corporation i omologatca standard de facto de ctre grupul OM G 9Signatura cuprinde, n genere: numele opreraiei, lista de parametri i, opional, tipul returnat

Obiect

ListareFurn(CodProd)

Clasa definitoare

a obiectului

(Produs)CodProd:112233

(Furnizor)AdresaListaFurn: XXXXXXXX

Furnizor

ListaFurn *AdresaListaFurn;:

ListareFurn(char codp[11]):

Produs

char codprod[11];:

void afisare();

:

Operaia afisare()apeleaz operaia ListareFurn()
http://-/?-http://-/?-


16/65

tocmai pentru c nu s-a manifestat suficient preocupare pentru evitarea utilizrii obiectelor atunci cnd acesteasunt ntr-o stare critic (referine nerezolvate, resurse necesare insuficiente, etc.).

Fie, n continuare, definiia conceptului de stare.

De finiia 4. Se numete stare a unui obiect o abstractizare a valorilor atributelor acelui obiectprecum i a relaiilor pe care obiectul le are cu alte obiecte .

Aadar, recapitulnd, conceptele eseniale cu care operm n lumea orientrii pe obiecte sunt: clas,obiect, stare obiect, mesaj.

2.2 Principii n programarea orientat pe obiecteAm vzut n paragraful 2.1 care sunt conceptele cele mai importante cu care ne ntlnim n programarea

orientat pe obiecte. Se tie de la alte discipline exacte c, fr principii de utilizare a lor, conceptele sunt bunedoar de pus n raft, ca nite bibelouri cu care putem aminti posteritii de o lume disprut. Conceptele prindvia, cu adevrat, doar n momentul n care sunt acompaniate de un set de principii care fixeaz regulileeseniale de utilizare a conceptelor. Evident, vom vedea care sunt aceste principii. Ce ne mai ateapt dincolo deele? Ne ateapt invitaia de a proba singuri valabilitatea acestor principii, la nceput, improviznd cuinerent stngcie, mai apoi descoperind adevrate abloane de rezolvare a unor probleme tip . Ne st la

dispoziie, n cantiti industriale, n internet, experiena tuturor celor care i-au fcut o religie din orientarea peobiecte i au realizat aplicaii de referin n acest spirit. Voi prezenta, n continuare, principiile pe care leconsider absolut necesare pentru a programa n spiritul orientrii pe obiecte.

AbstractizareaObinuiesc s insist pe importana acestui principiu deoarece mnuirea lui fr inspiraia necesar (iar

inspiraia, ntr-un domeniu, are cunoaterea acelui domeniu ca naintemergtor) poate pune lesne sub semnulntrebrii calitatea unei soluii.

Abstractizareaeste procesul de ignorare intenionat a detaliilor nesemnificative i de reinere aproprietilor definitorii ale unei entiti.

Prin urmare, din perspectiv procesual, abstractizarea este o modalitate de a reflecta asupra

pro prietilor une i entiti, cu scopul de a obine reprezentri care descriu comportamentul enti t ii, reprezentricare pot ndeplini simultan funcii explicative, funcii modelatoare i, de ce nu, funii demiurgice, la diferite

paliere de profunzime. Util itatea une i abstracii se manifest atunci cnd apar beneficiari n sfera ei demanifestare. Ca un exemplu, referindu-ne la limbajele de programare, putem observa c, toate limbajele ofersuport specific pentru abstractizare. Cu ct suportul pentru abstractizare este mai consistent, cu att putem spunec avem de-a face cu un limbaj de programare de nivel mai nalt. In cazul limbajelor de programare,abstractizarea nseamn un anumit gen de apropiere de limbajul uman i, prin aceasta, de gndirea uman.

De asemenea, la nivelul limbajelor de programare vorbim despre trei tipuri fundamentale de abstracii,ca rezultate ale procesului de abstractizare: abstraciile procedurale, abstraciile la nivelul datelor i clasele.

Abstraciile procedurale sunt cel mai mult folosite n programare. Utilizarea lor metodic permiteignorarea detaliilor legate de desfurarea proceselor. Toate funciile puse la dispoziia programatorilor n C prinintermediului sistemului de fiiere antet sunt exemple de abstracii procedurale, a cror utilizare este uor denvat dac le cunoatem: numele, eventual lista de parametri i/sau tipul returnat, plus semantica operaiilor

realizate de respectivele abstracii. Nu trebuie s avem, neaprat, informaii despre implementarea acestorfuncii. Care este ctigul? Se creaz, la un anumit nivel de abstractizare a unui program, posibilitatea ca acestas fie exprimat ca o succesiune de operaii logice i nu n termeni de instruciuni primare ale limbajului. Pentrulizibilitatea programului i, n consecin, pentru depanare, aa ceva este de maxim interes.

Abstraciile la nivelul datelor permit, de asemenea, ignorarea detaliilor legate de reprezentarea unuitip de date, n beneficiul utilizatorilor tipului de date. Un exemplu remarcabil de astfel de abstracie la niveluldatelor este tipul variant, specificat de cei de la firma Borland n cadrul limbajului Object Pascal. Cei care aurealizat aplicaii Delphi i au dat cu nasul peste tipul variantau probabil amintiri plcute despre versatilitateai uurina n utilizare a acestui tip de dat.

Clasele ca abstracii combin ntr-o nou abstracie, extrem de puternic i polivalent semantic, celedou abstracii mai sus pomenite, care in de acea epoc din istoria programrii n care deviza era:Algoritmi+structuri de date=programe. Arsenalul pus la dispoziia programatorului de clase, n calitate deinstrumente de abstractizare va fi n atenia acestui curs, n continuare.


17/65

ncapsulareaPrincipiul ncapsulrii insist pe separarea informaiilor de manipulare a unei entiti de aspectele

implementaionale. Se deduce, cu uurin, faptul c ncapsularea este o varietate de abstractizare . Practicatmetodic i cu suport sintactic adecvat, n programarea orientat pe obiecte, ncapsularea este susinut i la altenivele, de ctre limbaje de programare diferite. De exemplu, conceptul de unit din Object Pascal, permite

ncapsularea resurselor unei aplicaii Delphi, ceea ce, n fond, nseamn modularizare, la un nivel deabstractizare mai nalt dect cel specific ncapsulrii la nivel de clase. Cuvintele cheie pe care se sprijinoperaionalizarea principiului ncapsulrii sunt interfaa i implementarea. Motivul pentru care se insist att

pe acest principiu este simplu: separnd interfaa de implementare i admind c interfaa este foarte binestructurat (rezult c este stabil n timp i acceptat de utilizatori din punct de vedere al utilitii icomoditii n utilizare) nseamn c eventuale modificri ale implementrii (absolut fireti n condiiilembuntirii permanente a mediilor de execuie i programare) nu vor putea afecta utilizatorii .

Este bine ca cititorul s fac distincie ntre ncapsulare i localizarea datelor i a funciilor , ncadrul aceleeai entiti. ncapsularea are nevoie de localizare pentru a sublinia caracterul de black-box alentitilor, dar ea nseamn mult mai mult dect att. De asemenea, nu trebuie s fetiizm ncapsularea,ateptnd de la ea s garanteze sigurana n procesul de manipulare a obiectelor. Ct de sigur n utilizare este unsistem soft, hotrte programatorul, care combin eficient fora principiului ncapsulrii cu procedeeletehnice de asigurare a proteciei fa de ingerinele cu efecte negative.

Aadar, din perspectiva ncapsulrii, o clas, indiferent de limbajul n care va fi implementat, trebuie saib, obligatoriu, dou compartimente, ca n Figura 8.

Figura 7. Componentele obligatorii ale unei clase, din perspectiva ncapsulrii

MotenireaMult vreme, motenirea a fost un vis pentru a crui ndeplinire, ntr-o form destul de primitiv,

pro gramatori i trebuiau s depun eforturi intense. Apariia limbajelor care ofer suport sintactic pen truoperaionalizarea principiilor orientrii pe obiecte (OO), a confirmat, printre altele i marea importan a

principiului moteniri i pen tru specificul une i soluii OO. Din perspectiv mecanic privind lucrur ile, acest

principiu afirm posibilitatea ca o clas B s moteneasc o parte dintre proprietile unei clase A. n acestfel avem la dispoziie un mecanism practic pentru gestiunea similaritilor, naturale, de altfel ntr-o societate deobiecte foarte diversificat. n paragraful 2.1 (Figura 4) am prezentat, deja, un exemplu de societate posibil deobiecte, n care diversitatea punea probleme de clasificare, lsnd deschis problema gestiunii similaritilor, ncazul mulimii patrulaterelor. Mergnd pe linia utilizrii notaiei UML pentru reprezentarea unei soluii OO,atunci trebuie s spunem c dac avem o clas Bcare motenete o parte dintre proprietile clasei A, acest lucruva fi redat grafic n felul n care es te artat n Figura 9.

Student

Dat e i operaii private

Operaii publice

(Implementarea )

(Interfaa)


18/65

Figura 8. O parte din semantica relaiei de motenire care opereaz ntre clase

Dup cum se vede, relaia de motenire nu este doar o relaie al crei neles se reduce la posibilitatea caBs moteneasc o parte din proprietile lui A; semantica relaiei de motenire este mult mai subtil.

Mai nti, este vorba despre necesitatea de a reflecta cu ndemnarea necesar la cele dou posibilitide a identifica o astfel de relaie: procednd top-downsau bottom-up, deci specializnd , dup ce am identificato clas rdcin, sau generaliznd , dup ce am terminat operaia de clasificare a claselor i am nceput sorganizm clasele n familii, dup similaritile care le leag. Indiferent de abordare, rezultatul trebuie s fieacelai: o ierarhie de clase, n care similaritile sunt distribuite pe nivele de abstractizare, reducnd astfel laminimum redundanele i pregtind terenul pentru o reutilizare elegant a codului i pentru o serie de alteavantaje care nsoesc un lan de derivare. Exemplificm cu ierarhia din Figura 10, a crei semantic ne este dejacunoscut.

n Figura 10 regsim aproape toate elementele specifice unei soluii obiect orientate, care folosetejudicios principiul motenirii. Astfel , aproape toate soluiile orientate pe obiect au o clas rdcin (care, n

anumite situaii poate fi o clas abstract, adic o clas care nu poate avea instane directe, dar referine avndtipul ei pot fi asociate cu instane ale descendenilor), dac soluia se reduce la o singir ierarhie de clase. nierarhie putem ntlni i clase intermediare, precum i clase terminale sau frunz .

Figura 9. Principiul motenirii n aciune

A

B

Clasa printe, superclasa,

clasa de baz

Clasa copil, subclasa,

clasa derivat

Simbolul care indicrelaia de generalizare

dintre clasele Ai B

GENERALIZARE

SPE

CIALIZARE

Patrulater

Polig on

Triunghi

Paralelogram

Romb Dreptunghi

Trapez Patrulaterinscriptibil

Clas rdcin,

poa te fi i

abstract

Clas

intermediar

Clase frunz


19/65

Din punctul de vedere al programatorului, pe lng utilitatea motenirii n procesul de gestiune asimilaritilor, mai exist un avantaj care poate fi exploatat n faza de implementare a soluiei, avantaj derivat din

principiul mo teniri i sub forma unui alt principiu care afirm c:

Orice printe poate fi substituit de oricare dintre descendeni

Acest principiu este de mare utilitate pentru programatori, el fiind operaionalizat prin intermediuloperaie de casting, aplicat obiectelor ale cror clase definitoare sunt n relaie de motenire. Evident, estevorba de un casting implicit n lumea obiectelor (descendentul motenind tot ceea ce se poate de la strmoi, va

putea opera n locul strmo ului). Castingul de acest tip se numete up-casting. Se practic, explicit i down-castingul, dar programatorul trebuie s fie pregtit s rspund de consecine. ntr-un down-casting, este posibilca obiectul de tip strmo, convertit la un obiect de tip descendent, s nu asigure coerena informaional de careare nevoie descendentul, deci pot apare, principial, excepii. n Java se ntlnesc amndou tipurile de casting.

n sfrit, n Figura 10 avem un exemplu de utilizare a motenirii simple, potrivit creia un descendentpoate avea un singur str mo. Unele limbaje de programare(C++, de exemplu) accept i motenirea multipl,ceea ce nseamn c o clas poate avea doi sau mai muli strmoi. O astfel de soluie pentru principiulmotenirii este plin de riscuri, cu toate avantajele pe care le presupune. Motenirea multipl poate generaambiguiti care pot pune la ncercare rbdarea programatorului.

Figura 10. Exemplu de motenire multipl

n exemplul din Figura 11, clasa D are ca strmoi clasele B i C. Obiectele clasei D vor avea moteniteresursele lui A, att pe traseul lui B ct i pe traseul lui C. Ambiguitatea referirii la o resurs a lui A n cadrulunei instane a lui D este evident. Cnd este considerat strict necesar, motenirea multipl se utilizeaz cudiscernmnt. Java i C# nu mai promoveaz motenirea multipl, propunnd alte soluii la aceast problem.

Motenirea nu este doar o problem de sintax, ci este esena nsi a programrii orientate pe obiecte.Pe temeiul motenirii are rost s vorbim n continuare de principiul polimorfismului, aplicat la lumea obiectelor.

PolimorfismulDup cum se vede i n exemplul prezentat n Figura 10, ierarhia de clase care modeleaz, la urma

urmei, comportamentul unei aplicaii poate avea mai multe clase frunz, deci clase care pote genera instane.Crearea unei instane este, indicutabil o problem n care programatorul trebuie s se implice, el trebuind sstabileasc, n funcie de dinamica aplicaiei, ce constructor va coopera la crearea unei instane. n ideea c avemo aplicaie care se ocup de simularea nvrii poligoanelor, vi se pare interesant s declarm cte o variabil

pentru fiecare tip de poligon din ierarhia prezentat n Figura 10 (mai puin clasa rdcin)? Nu este interesantdin dou motive:

1. Explozia de variabile obiect nu este un indiciu de performan n programare.2. Odat create obiectele, programatorul trebuie s tie n orice moment ce fel de obiect lucreaz

la un moment dat. Chiar c a ceva poate deveni suprtor ntr-o aplicaie de marecomplexitate.

Nu ar fi mai civilizat s dec larm o var iabil de tip Poligon n care s pstrm instane create cu

ajutorul constructorilor oricror descendeni care pot avea urmai direci? Admind c, n clasa Poligon, amdeclarat o operaie calculArie() care este suprascris n fiecare descendent, atunci situaia creat este urmtoarea:

A

B C

D


20/65

obiectul creat cu ajutorul constructorului unui descendent al clasei Poligon i pstrat ntr-o variabil de tipPoligon(principiul substituiei ngduie acest lucru), s-i spunem p, va putea s apeleze diferite implementri aleoperaiei calculArie() , n funcie de contextul n care se creaz p. Aadar, un mesaj de tipul p.calculArie() cerspuns va genera? Rspunsul va fi dependent de context, controlul contextului (adic alegerea metodei specificeclasei definitoare a obiectului pstrat n p) realizndu-se de ctre sistem prin mecanisme specifice, n timpulexecuiei programului. Acest mod de legare a unui nume de operaie de codul metodei specifice tipului definitor

al variabile obiect gazd se numete late binding. Este un mod de legare mai puin performant dect legareastatic (la compilare), dar avantajele scuz dezavantajele insignifiante, n condiiile n care viteza procesoarelori disponibilul de RAM sunt n expansiune permanent.

S-a neles, probabil, faptul c polimorfismul este de neconceput fr motenire n care specializareaclaselor s se bazeze i pe suprascrierea unor metode n clase aflate n relaie de motenire. Tot ceea ce trebuie stie programatorul de aici ncolo este avertismentul c:

Motenirea i polimorfismul sunt ideale ca uz i contraindicate ca abuz .

Terminnd excursia n lumea conceptelor i a principiilor programrii orientate pe obiecte, nu nermne dect s anunm c n capitolele urmtoare vom ncerca s vedem aceste abstracii la lucru n contextJava.


21/65

3 Specificarea i implementarea unei clase dinperspectiv Java

3.1 n loc de introducereFr s am pretenia c am epuizat semantica modelrii orientate pe obiect, n capitolele precedente, n

acest capitol voi ncepe incursiunea n lumea elementelor suport oferite de Java pentru implementarea orientatpe obiect a mod elelor obiect orientate .

Laboratoarele de cercetare i lumea practicienilor vd, nc, n acest limbaj un moment de referin nzbuciumata evoluie a limbajelor de programare. Apariia limbajului C# la orizont, prin bunvoina celor de laMicrosoft, se anun un concurent redutabil, care, i propune s ctige, deopotriv, atenia fanilor Java i C++.Pn ce apele se vor limpezi, m voi ocupa de ceea ce, tocmai, am anunat n lista subiectelor care fac obiectulacestui capitol.

3.2 Atenie la importana efortului de abstractizare!Voi ncerca s art cum se specific i implementeaz clasele n Java. n tot acest timp, ncercai,

mpreun cu mine, s nu minimalizai nici o clip importana hotrtoare a abstractizrii n elaborarea unorsoluii stabile i flexibile10.n acest scop voi considera un exemplu pretext de problem prin intermediul creia voi ncerca s pun

n valoare puterea de reprezentare a limbajului Java.

S se scrie codul Java care pune la dispoziia unor utilizatori poteniali capabiliti de lucru culiste simplu nlnuite de numere ntregi, pentru care resursele necesare reprezentrii sunt alocatedinamic. n continuare m voi referi la aceast problem cu acronimul LSI.

De ce numai acest tip de list? De ce doar numere ntregi? Pentru c aa cere utilizatorul n acestmoment. Nici mai mult, nici mai puin. Aa se ntmpl i n viaa de toate zilele. Specialitii n IS trebuie slivreze beneficiarilor ceea ce acetia se ateapt s primeasc . Amorul artei sau dispreul fa de beneficiar,sunt taxate necrutor de ctre ansamblul regulilor jocului din industria de soft.

Nu voi exagera cu descrierea travaliulu i conceptual n urma cruia am ajuns la nite concluzi i nlegtur cu rezolvarea problemei LSI. Dar, cteva elemente de descriere a atmosferei trebuie, totui precizate.Se tie c structurile dinamice de date sunt preferate structurilor statice de date, atunci cnd

utilizarea chibzuit a memoriei i flexibilitatea relaiilor dintre obiectele care populeaz structura suntcriticepentru calitatea unui sistem soft.

Se mai tie, totodat, c o structur dinamic de date este complet specificat dac am clarificat:

Tipul datelor care populeaz structura.

Mecanismul de nlnuire a datelor din structur. Punctele de intrare n structur. Operaiile cu ajutorul crora ntreinem i consultm structura.

Fiecare din cerintele de mai sus, poate face obiectul unor consideraii cu implicaii interesante asupra

soluiei. M limitez doar la a observa faptul c o structur de date dinamic este un exemplu reprezentativde tip de dat care poate fi modelat orientat pe obiecte, n a fel nct serviciile oferite s fie complete iuor de apelat.

Intrnd puin n domeniul problemei, dac ne gndim la o list simplu nlnuit, semantica ei poate fivizualizat, parial, ca n Figura 12.

10Nu este o contradicie ntre termeni. Cele mai bune mod ele, ntr-o lum e care nu st pe loc, sunt modelele care pot fi socotite, n acelaitimp, nchise i deschise, deci stabile i flexibile.
http://-/?-


22/65

Figura 11. Incercare de vizualizare a unei liste simplu nlnuite

Prin urmare, obiectele care fac parte din inventarul problemei sunt: Nod (avnd ca proprieti informaionaleDatai Adresade legtur cu urmtorul element iar ca proprieti comportamentale, cel puin operaii legate decrearea unui nod i consultarea proprietilor lui informaionale) i Lista (un obiect care, n principiu este oagregare 11de obiecte de tip Nod).

Un obiect care poart marca tipului Lista va avea, aadar, proprieti informaionale i comportamentspecific. Abstractiznd cu nverunare, lista proprietilor informaionale ale unui obiect de tip Listaar putea sconin doar adresa primului nod din list. ns, dac trecem n revist exigenele clienilor fa de un obiect detip Lista, vom descoperi c este indicat s avem un atribut pentru a indica dac lista conine sau nu elemente (unexemplu de redundan n procesul de utilizare a memoriei interne care asigur o vitez sporit n procesul deutilizare a unei liste). Dac acest atribut este un ntreg care indic chiar numrul elementelor din list, cu att mai

bine. A adar, n notaie UML, n acest moment am putea avea situaia din Figura 13.

Figura 12. Clasele candidate la rezolvarea problemei LSDI

Ce observaii putem face? Clasa Nod este o clas concret, adic, avnd constructor, poate aveainstane. S mai observm faptul c atributele clasei Nod sunt prefixate cu cte un semn -, ceea ce, n UML,nseamn c sunt private. Conform dogmei OO, absolut normal. De asemenea, s mai observm c operaiile

11In modelarea obiect orientat se folosete relaia de agregare pentru a indica o asocierentre obiecte care, din punct de vedere semantic,sunt ntr-o relaie parte-ntreg. Reprezentarea unei relaii de agregare este la latitudi nea programatorului.

Adresa de start a primului nod

Data_ 1 Data_2 Data_n

Informae

Legtura spre urmtorul nod Ultimul nod nu are un succesor

Nod

-Int Data;-Nod Urmatorul;

+Nod(int Numar);+void setareData(int Numar);+int consultareData();+void setareUrmator(Nod AUrm)+Nod con sultUrmator()

Lista

-Nod Astart;-Nod AUltim;-Int NrElem;

+void setareAStart(Nod Element);

+Nod consultaAStart();

+void setareNrElem(int ne);+int consultaNrElem();

+setareAUltim(Nod Element)

+Nod consultaAUltim();+void insereazaDNod(Nod Element);

+void insereazaINod(Nod Element);

+void stergeNodAdr(Nod Element);+void stergeNodNum(int Nr);

+salveazaInFisier(char nu mef[]);+incarcaDinFisier(char numef[]);)
http://-/?-


23/65

clasei Nod sunt prefixate cu semnul + isunt scrise cu font drept, ceea ce, n UML, nseamn c sunt publice iau deja implementare valabil. Semantica acestei clase i a contextului n care opereaz s-ar prea c nu ne

pre tinde specificarea unor opera ii priva te sau pro tejate. Oare? Este adevrat c n Java, de exe mplu, crearea unuiobiect de tip Nod se va face rezonabil, chiar i dac nu am prevedea un constructor, dat fiind faptul c obiectelese creaz i n acest caz, atributele fiind iniializate cu valori predefinite (0 pentru numere, null pentru obiecte,false pentru valori booleene, \u0000pentru caractere). Dac un astfel de comportament implicit nu este de

acceptat, atunci este loc pentru a specifica operaii care fac validarea strii obiectelor. Aceste operaii ar putea fifolosite, ca uz intern, de orice alt operaie care este sensibil la starea obiectului care o folosete la un momentdat.

Pe de alt parte, observm faptul c unele dintre operaiile clasei Listasunt scrise cu carac tere italice. nUML aceasta nseamn c aceste operaii sunt abstracte. Prin urmare, clasa Lista este o clas abstract, decinu are constructor i tipul introdus de aceast clas nu va putea avea instane directe. Pentru a fi util, clasa Listatrebuie s aib descendeni. Care vor fi aceti descendeni? Vom considera c aceti descendeni sunt doi: o clascare modeleaz o list simplu nlnuit de ntregi, n care cuvntul de ordine la creare este ordinea fizicde introducere i o clas care modeleaz o list simplu nlnuit de ntregi , n care elementele listei suntintroduse astfel nct, dup fiecare introducere acestea s fie n ordine cresctoare . Pe scurt: listeindiferente la ordinea numerelor ntregi i liste sensibile la ordinea numerelor ntregi. Vom obine ierarhia dinFigura 14.

Figura 13. Ierarhia claselor care modeleaz dou varieti de list simplu nlnuit.

Se poate observa c cele dou varieti posed operaiile necesare pentru a simula, n caz de nevoie i

comportamentul unei stive (AStart este Top-ul iar inserareINod() i ste rgeNodAdr(AStart) sunt operaiilespecifice unei stive, adic Push( ) i Pop()). Cititorul bnuiete c inserareINod() este abreviere de la inserarenainte de nod iar inserareDNod()este abtreviere de la inserare dup nod.

Consideraii de acest gen i chiar mai profunde, trebuie s prilejuiasc orice ncercare de rezolvareorientat pe obiect a unei probleme.

3.3 Specificarea i implementarea unei clase n JavaEste cunoscut faptul c, n Java, orice aplicaie este puternic obiect orientat, cel puin datorit cadrului

sintactic obligatoriu pentru realizarea unui applet sau a unei aplicaii Java obinuite. Dac spiritul orientrii peobiecte este bine neles, atunci Java este o soluie interesant pentru multe probleme a cror rezolvare presupunerealizarea unor aplicaii pentru care lumea Internet-ului este puternic deschis. Indiferent de tipul aplicaiei,

piesele de baz n realizarea acesteia sunt clasele. Vom avea, n cazul unei aplicaii Java obinu ite, o singurclas public, care conine funcia main() i una sau mai multe clase care modeleaz, la diferite nivele de

rafinare, comportamentul aplicaiei. De asemenea, n cazul unui applet Java, vom avea o singur clas publiccare extinde clasa Applet i una sau mai multe clase care modeleaz, la diferite nivele de rafinare,comportamentul applet-ului.

Privit de la cel mai nalt nivel de ab stractizare, definiia unei clase n Java este:

[] class [extends] [implements]{

//List d e resurse sau corp clas

}

Resursele unei clase sunt de dou tipuri: atribute i/sau operaii. Problema noastr, dup cum am vzut,este de a organiza aceste resurse, astfel nct s putem beneficia de o serie de avantaje din punct de vedereal efortului de dezvoltare ct i din punct de vedere al calitii softului 12.

12Despre calitatea softului cititorul poate gsi elementele eseniale n D. Bocu, Iniiere n ingineria sistemelor soft, Editura Albastr, 2002

Lista

ListaOarecare ListaSortata
http://-/?-


24/65

n paragraful 2.2 am vzut c o ncapsulare corect (n acord i cu dogma OO) nseamn s declarm caprivate atributele i s definim o interfa coresp unztoare clasei . Vom vedea, mai jos, ce nseamn acest lucrun cazul problemei noastre.

Atributele unei clase se specific sintactic astfel:

[] Tip ;

Operaiile unei clase se specific prin signatur i implementare ca mai jos:

[]Tip_returnat Identificator_metod>

([) [throws]{

}

Formalizmul folosit pentru prezentarea sintaxei de definire a unei clase se bazeaz, dup cum se poatededuce, pe urmtoarele convenii:

Orice construcie a utilizatorului este prezentat ntre simbolurile < ...>.

Orice construcie opional este ncadrat de simbolurile [...].

Cuvintele rezervate sunt evideniate prin ngroare.

ntrebarea fireasc care se pune este urmtoarea: la ce ne folosesc aceste elemente de variaie npro cesul de definire a unei clase.

Voi ncerca s rspund pe rnd la toate ramurile acestei intrebri.

Modificatorii aplicabili claselorDup cum se poate observa, cuvntul cheie class poate fi prefixat, opional, de un modificator. Lista

complet a acestor modificatori este: abstract, final, public .

Modificatorul de clas abstractJava permite extinderea unei clase existente cu o subclas. Cu timpul, este posibil s v constituii

pro priile biblioteci de clase care considera i c vor fi extinse de ali programatori. Pentru unele clase, poate s fie

inutil s implementai o operaie ct timp nu se cunoate cum va fi extins clasa. n astfel de cazuri, putei utilizacuvntul cheie abstractpentru a indica faptul c n descendeni toate operaiile clase trebuie s fie supradefiniteobligatoriu.

Clasa Lista din Figura 14 ar putea fi definit, prin urmare astfel, n Java:

abstract class Lista{

privateNod AStart;privateNod AUltim;privateintNrElem;publicvoidsetareAStart(Nod Element);publicNo d consultaAStart();publicvoidsetaretNrElem();

publicintconsultaNrElem();publicNod consultaAUltim();public abstract voidinsereazaDNod(Nod Element);public abstract voidinsereazaINod(Nod Element);public abstract voidstergeNodAdr(Nod Element);public abstract voidstergeNodNum(intNr);public final voidsalveazaInFisier(char numef[]);public finalNod incarcaDinFisier(charnumef[]);)}

Este evident faptul c descendenii ListaOarecare i ListaSortatasunt obligai s implementeze toateoperaiile clasei Lista,care sunt abstracte. De asemenea, s observm c implementarea definitiv a operaiilorde salvare/restaurare a listei este realizat n clasa Lista i va fi folosit fr modificri n descendeni.

Modificatorul de clas final (tocmai l-am utilizat mai sus)


25/65

n general vorbind, Java permite unei clase s extind o alt clas. Atunci cnd definim o clas, n contextuln care anticipm utilizarea ei, s-ar putea s nu dorim extinderea ei de ctre alte clase. n acest caz, prinincluderea cuvntului cheie finaln cadrul definiiei clasei vom mpiedica crearea de subclase ale clasei n cauz.Aadar, clasa:

public final class NumeClasa {...}

nu va putea s aib urmai.

Modificatorul de clas publicAtunci cnd utilizm cuvntul cheie public n cadrul declaraiei clasei, ne asigurm c acea clas este

vizibil / accesibil de oriunde. Dac dorim s controlm accesul la o clas, cuvntul cheie public nu are cecuta n declaraia clasei. S reamintim, totodat, faptul c Java permite o singur clas public ntr-un fiier cucod surs. Evident, caracterul public al unei clase poate avea alte conotaii n contextul organizrii codului sursal unei aplicaii cu ajutorul pachetelor. Mai precis spus, o clas public poate fi utilizat din exteriorul pachetuluin care a fost declarat, pentru a crea instane sau pentru a o extinde. n schimb, o clas care nu a fost declarat

public este considera t o clasa friend, putnd fi accesat doar din interiorul pachetului n care este rezident.

Modificatorii aplicabili atributelor

Domeniul de valabilitate al unui atribut definete locaiile din program n care atributul este cunoscut.n procesul de definire a unei clase putem controla domeniul unui atribut al clasei precednd declaraia lui cuunul din cuvintele cheie: public, private, protected, static, final, tranzient, volatile . S menionm faptul cun atribut care nu este nsoit de nici un modificator este vizibil friendly, adic doar din interiorul clasei i dinclasele din acelai pachet.

Modificatorul de atribut publicUn atribut public este vizibil / accesibil oriunde este vizibil / accesibil clasa care l conine. Aadar,

pentru a declara ca public un atr ibut vo m proceda ca mai jos::

publicintvizibilOriundeEsteVizibilaClasa;:

Dogma spune c o clas care ajunge la client trebuie s-i ascund atributele fa de acesta, accesul la

ele fiind mijlocit de interfa, dac este cazul. Nu este, ns, exclus ca o serie de clase neterminale (care nu sunt,deci clase frunz) s declare ca publice o parte a atributelor, protecia lor fiind controlat, la niveluldescendenilor prin intermediul interfeelor sau al organizrii n pachete.

Modificatorul de atribut privateUn atribut privat este vizibil numai n interiorul clasei sale. Subclasele i clienii externi nu pot accesa

aceste atribute.

Modificatorul de atribut protectedUn atribut al clasei, declarat ca protejat, este accesibil n descendenii clasei sau n cadrul pachetului din

care face parte clasa deintoare. Atenie, un atribut declarat ca protected ntr-o clas va putea fi accesat nscriere i citire n toi descendenii clasei n cauz, rezideni chiar i n afara pachetului gazd al clase care deineatributul protejat. Nu va fi permis accesul direct la atributul protejat pentru clase care nu sunt descendei ai clasei

care declar atributul protejat.

Modificatorul de atribut staticOrice atribut care nu este declarat ca static este numit atribut de instan, ceea ce nseamn c fiecare

instan are propria copie a atributului. Atunci cnd este n interesul comportamentului clasei ca un atribut s fiepartajat de toate obiectele clasei n cauz, acel atribut va fi declara t ca static.

Modificatorul de atribut finalAtunci cnd n definiia unei clase menionm un atribut final, indicm compilatorului faptul c acel

atribut are valoare constant, care nu poate fi modificat de program. Iniializarea atributului cu o valoare sepoate face la crearea obiectlui gazd, p rin contribuia construc torului sau n cadrul une i declaraii de tipul:

:

pro tected static final int nr= 10;:


26/65

Atenie! Cele dou metode de iniializare sunt mutual exclusive.

Modificatorul de atribut transientAtunci cnd declarm un atribut ca fiind de tip transient, indicm compilatorului Java faptul c atributul

nu este o parte permanent a obiectului, deci de uz intern i n cazul serializrii, de exemplu, nu va fi salvat pememoria extern. Un atribut tranzient se declar astfel:

:private transientString password;:

Modificatorul de atribut volatileAtunci cnd se compileaz programul, compilatorul analizeaz codul i, adeseori va efectua anumite

manevre cu scopul de a optimiza performanele codului. Atunci cnd dorim s scoatem un atribut de subincidena unei astfel de eventualiti, o declarm ca volatil. Practic, aceasta nseamn c exist situaii

particulare n care comunicaia cu alte pro grame sau rutine necesit neinterven ia compilatorului asupra unuiatribut, esenial pentru buna desfurare a comunicaiei n cauz.

Modificatorii aplicabili operaiilor

n aceast seciune vom prezenat o serie de modificatori care, de cele mai multe ori, sunt aplicabilimetodelor care implementeaz operaiile claselor. Aceti modificatori sunt: public, private, protected, static,final, abstract, native, synchronized.

Modificatorul de metod publicSemnificaia acestui modificator, n cazul n care se aplic unei metode, este asemntoare cu cea pe

care o are cnd se aplic unui atribut.

Modificatorul de metod privateSemnificaia acestui modificator, n cazul n care se aplic unei metode, este asemntoare cu cea pe

care o are cnd se aplic unui atribut.

Modificatorul de metod protected

Semnificaia acestui modificator, n cazul n care se aplic unei metode, este asemntoare cu cea pecare o are cnd se aplic unui atribut.

Modificatorul de metod staticSemnificaia acestui modificator, n cazul n care se aplic unei metode, este, ntr-o oarecare msur,

asemntoare cu cea pe care o are cnd se aplic unui atribut. Mai precis, trebuie s spunem c o metod static,pentru a fi util izat nu reclam neaprat o instan, putnd fi utilizat i p rintr-un apel de tipul:

NumeleC lasei. NumeleM etodeiStatice(parametri);

O metod static poate fi utilizat pentru a accesa ali membri statici ai clasei, dar, n nici un caz, pentrua accesa variabile nestatice.

Modificatorul de metod finalAm vzut, deja, n cursul 2, c anumite metode ale claselor pot fi supradefinite n clasele descendente.

Dac, din variate motive, dorim s blocm posibilitatea supradefinirii unei metode, atunci vom informacompilatorul de aceast intenie declarnd metoda ca final astfel:

public f ina l vo id MetodaNuPoateFiSupra defini ta();

Modificatorul de metod abstractDac o metod a unei clase este precedat de cuvntul cheie abstract, atunci compilatorul nu va

autoriza crearea de instane ale clasei n cauz. Totodat, o clas care extinde clasa n cauz va trebui simplementeze metoda abstract obligatoriu. Declararea se face astfe:

public abstract void implementareUlterioar ();

Atenie! O metod abstract nu poate fi privat sau final.


27/65

Semantica cuvntului cheie abstract (= metoda va fi implementat n descendeni) vine n contradiciecu semantica cuvintelor cheie privatei finalcare spun, n moduri diferite, c metoda nu poate fi modificat.

Modificatorul de metod nativeAcest modificator se utilizeaz pentru a spune compilatorului c o anumit metod utilizeaz cod scris

ntr-un alt limbaj de programare, cum ar fi C/C++, de exemplu. Aceast posibilitate trebuie folosit cu

discernmnt deoarece lovete puternic n portabilitatea aplicaiei, aa cum este ea neleas n Java.

Modificatorul de metod synchronizedSe tie c Java ofer suport pentru multitasking sub forma un program mai multe fire de execuie.

n funcie de activitatea programului respectiv, uneori este necesar s garantm faptul c, dou sau mai multe firenu pot accesa simultan aceeai metod. Prin urmare, pentru a controla numrul de fire de execuie care potaccesa o metod la un moment dat, utilizm cuvntul cheie synchronized. Atunci cnd compilatorul Javantlnete o metod prefixat de cuvntul cheie synchronized, introduce un cod special care blocheaz metodacnd un fir ncepe execuia instruciunilor metodei i o deblocheaz cnd firul i ncheie execuia. n mod uzual,sincronizarea metodelor este reclamat de necesitatea partajrii datelor.

Am prezentat, mai sus, semantica cuvintelor cheie ascunse sub sintagma modificatori, aplicaiatributelor sau operaiilor.

Sintaxa care st la baza definirii unei clase mai conine, opional i cuvntul cheie extends pentru a

indica o clas de baz clasei n curs de definire.De asemenea, n sintaxa prezentat se mai evoc i eventualitatea apariiei cuvntului cheie implementsurmat de numele interfeelor pe care le implementeaz clasa, atunci cnd este cazul. Evident, cuvntul cheieextends este legat de problematica motenirii n programarea orientat pe obiecte n Java iar cuvntul cheieimplements este legat de problematica utilizrii interfeelor, pentru a introduce numeroase elemente deflexibilitate n programarea Java, inclusiv rezolvarea motenirii multiple, neadmis direct n Java.

Despre aceste dou probleme vom discuta pe ndelete in Capitolul 5.nainte de a trece la prezentarea cadrului C++ pentru definirea unei clase putem urmri, mai jos, codul Java

asociat definirii claselor Nod i Lista, aa cum apar ele n lumina observaiilor fcute pn acum.

//---------- ------- --------------------------- -

//Cod Java care demareaza procesul de rezolvare

//a problemei LSI

//---------- ------- --------------------------- -//Specificare minim ala a c lasei Nod

//Implementare c lasa Nod

class Nod

{priva te int Data;

priva te Nod Urmatorul;

//constructor

public N od(int Numar)

{

Data= Numar;

};

//modificator atr ibut Data

public void setareData(int nr){

Data= Numar;

};

//selector a tribut Data

public int consultareData(){

return Data;

};

//M odificator atr ibu t Urmatorulpublic void setUrmator(Nod E lement)


28/65

{

Urmatorul=Element;};

//Selector a tribut Urmatoru l

public N od consultaUrmator()

{return Urmatorul;

};

};

//Specificare aproape comple ta a clasei abstracte Lis ta

abstract class Lista

{

priva te Nod AStart;

priva te Nod AUltim ;

priva te int NrElem;

//M odificator atr ibu t ASta rt

public void setareAStart(N od Element){

AStart=Element;

};

//Selector a tribut AStart

public N od consultaAStart()

{

return AStart;

};

//M odificator atr ibu t NrElem

public void setareNrElem (int ne)

{NrElem=ne;

};

//Selector a tribut NrElempublic int consultaN rElem()

{

return NrElem;

};

//M odificator atr ibu t AUltim

public void setareAUltim (Nod Element)

{

AUltim=Element;};

//Selector a tribut AUltim

public N od consultaAUltim()

{

return AUltim;

};

//M etoda abstracta

//Va f i imp lementata in descendenti

//Insereaza un element dup a ultimul nod introdus

public abstrac t void insereazaDN od(Nod Element);

//M etoda abstracta


29/65

//Va fi implementata in descendenti

//Insereaza un element ina intea ult imulu i nod introduspublic abstrac t void insereazaINod(Nod E lement);

//M etoda abstracta


//S terge un element de adresa spec ificatapublic abstrac t void stergeNodAdr(Nod E lement);

//M etoda abstracta


//Insereaza un element de pozitie specifica ta

public abstrac t void stergeNodNum(int N r);

//M etoda publica finala

//Deocam data neimplementata

//Salveaza lista reperata de AStart

//intr-un fisier de nume specifica t

public f ina l vo id salveazaInFisier(char numef[] )

{System.out.println("Neimplementata...");

};

//M etoda publica finala

//Deocam data neimplementata

//Restaureaza lista folosind inform ati ile din fisierul

//de nume specifica t

public f ina l Nod incarcaD inFisier(char numef[] )

{

System.out.println("Neimplementata...");

return null;

};

}

Codul prezentat mai sus trebuie s fie extins i rafinat pentru a acoperi toate cerinele iniiale alepro blemei i pentru a face fa exigenelor de calitate fireti (modularizare corect, fiabili tate , extensibilita te,etc.).


30/65

4 Motenirea n programarea orientat pe obiecte dinperspectiv Java

4.1 Scurt introducereAm vzut, deja, faptul c unul dintre principiile importante n programarea orientat pe obiecte

este principiul motenirii . Aa cum se ntmpl, n general, cu principiile, nici principiul motenirii nutrebuie fetiizat sau bagatelizat . Bagatelizarea lui nseamn, ceva de genul: Hai s facem motenire ca s neaflm n treab sau ca s vedem dac funcioneaz. Fetiizarea, din contr, ar nsemna Sfinte Sisoe, nimic maifrumos i mai eficient dect aplicarea principiului motenirii la tot pasul.Ambele variante sunt false. Cum ammai spus i alt dat, principiul motenirii este disponibil pentru uz, nu pentru abuz . Ceva mai concret spus:

Motenirea este o modalitate performant de reutilizare a codului, dar nu este ntotdeauna celmai bun instrument pentru ndeplinirea acestui obiectiv.

Dac este folosit necorespunztor, programele obinute vor fi destul de fragile.Motenirea poate fi utilizat cu succes n cadrul unui pachet, unde implementrile subclaselor i

superclaselor sunt controlate de aceeai programatori. De asemenea, poate fi folosit la extinderea claselorcare au fost concepute i documentate exact n acest scop .

ns, motenirea unor clase concrete obinuite, n afara granielor unui pachet, poate fi periculoas.Trebuie s subliniez faptul c toate consideraiile pe care le fac n acest paragraf se refer la motenireaneleas ca motenire a implementrii (o clas extinde o alt clas, exprimndu-ne n spirit Java). Se tie,desigur c relaia de motenire opereaz i n relaia dintre interfee, chestiune care nu cade sub incidenaobservaiilor critice, de mai sus, la adresa motenirii.

Defeciunea esenial care poate apare cnd apelm la motenire se refer la faptul c, prin

motenire, ncapsularea are de suferit n mod natural .i aceasta deoarece funcionarea corect a unei subclase depinde de detaliile de implementare ale

superclasei . Implementarea superclasei se poate modifica de la o versiune a programului la alta, situaie n care ,subclasa este expus deteriorrii chiar i n cazul n care codul ei a rmas neatins. Prin urmare, subclasa esteobligat s evolueze odat cu superclasa, exceptnd, bineneles, situaia n care autorii superclasei au conceput-o i documentat-o special pentru a fi extins.

O regul de bun sim n utilizarea principiului motenirii ne spune c este bine s folosimmotenirea numai dac subclasa este, ntr-adevr, un subtip al superclasei.

Altfel spus, o clas B trebuie s extind o clas A numai dac ntre cele dou clase exist o relaiede tipul B este un A.

Cu referire la mulimea poligoanelor, prerea unor aa zii specialiti, conform creia putem derivaclasa dreptunghi din clasa triunghi este complet n afara logicii relaiei de motenire. Nici n visul cel maifrumos un dreptungi nu este un triunghi. n schimb, putem spune c triunghiul este un descendent al poligonului,

pe motiv c orice tr iunghi este un poligon, etc.

Concluzionnd, motenirea este un aspect important n programare, dar problematic, pentru cpoate fi aplicat denaturndu-i esena i pentru c ncalc, n mod natural, regulile ncapsulrii.

Motenirea se poate folosi eficient numai cnd ntre superclas i subclas exist o relaie real de genultip-subtip. Chiar i n acest caz, codul obinut poate fi fragil, avnd probleme cnd apar modificri i fiind

predispus la anu mite bree n securitatea resurselor une i clase.Evitarea unor astfel de probleme este posibil, n anumite situaii, prin utilizarea compunerii n locul

motenirii.Relaia de compunere presupune ca n definiia unei clase A s apar i instane ale altor clase, ale

cror servicii urmeaz s fie utilizate de ctre clasa A. Pe de alt parte, este tot att de adevrat faptul c multepro bleme rezolvate n C++ cu ajutorul pointerilor, nu ar avea rezolvare echivalent semantic n Java, frsuportul motenirii.


31/65

4.2 Motenirea n JavaNu este cazul s revin asup ra sintaxei operaiei de motenire n Java .

Java a optat pentru un cuvnt cheie pentru a informa compilatorul de intenia unei clase de a motenipro prietile alte i clase. Acest cuvnt cheie este extends. Ceea ce trebuie s semnalm ca important, pentru

spiritul motenirii n limbajul Java, este faptul c acesta nu ofer suport pentru motenirea multipl , n sensuln care este aceasta neleas n alte limbaje. n Java, o clas poate avea o singur superclas. De aici rezult

posibilita tea teoretic de a construi doar ierarhii de clase, cu suportul oferit de moten irea cu extends. Dat fiindfaptul c n practic exist i nenumrate situaii n care semantica motenirii multiple se impune ca alternativacea mai valabil, Java ofer o porti pentru a simula motenirea multipl cu ajutorul interfeelor. Jongleriile carese pot face cu ajutorul interfeelor au depit de mult inteniile iniiale ale specificatorilor limbajului Java. Mvoi ocupa de acest subiect n paragraful 5.3.

Exemplul 4.1 ilustreaz motenirea, avnd ca idee cluzitoare specializarea clasei de baz prinadugare de membri noi. De asemenea, Exemplul 5.1 ilustreaz i cele dou tipuri de casting posibile n

pro gramarea orientat pe obiecte din Java. n esen, este vorba despre faptul c, avnd contextul d in Figura 15,sunt posibile dou tipuri de casting, principial deosebite.

Figura 14. Derivare pretext pentru dou tipuri de casting

Primul tip de casting este implicit. Este vorba despre conversia unei variabile obiect de tip B la ovariabil de tip A . Motivul pentru care acest tip de conversie este implicit este simplu: resursele lui A seregsesc printre resursele lui B . Astfel c, atunci cnd B este coerent din punct de vedere al strii, nu existnici un motiv ca As fie altfel, n urma conver siei.

Al doilea tip de casting necesit acordul explicit al programatorului pentru a fi efectuat i ntr-un anumitsens, asumarea rspunderii pentru aceast conversie. Este vorba de conversia unei variabile obiect de tip A la ovariabil de tip B . De ce este necesar acordul? Foarte simplu: resursele lui A sunt incluse printre resurselelui B. Conversia de mai sus este posibil s aduc variabila de tip B ntr-o stare improprie pentru utilizarea unormetode, deoarece unele date membre pot rmne neiniializate adecvat. Cu toate acestea, down casting-ul esteesenial n programarea generic, asupra creia vom reveni ntr-un curs special.

Exemplul 4 .1//C lasa de baz

//Modeleaz informaional obiectu l Fruc t

//Potrivi t abordri i d in acest cod

//metoda consultaTipFruct()nu poate fi//redefinit n d escendeni

class Fruct{

priva te int tip fruct;

Fruct(in t t )

{

tipfruct=t;

System.out.println("Constructor Fruct...");}

final int consu ltaTipFruct()

{

return tipfruct;

}

}

A

B


32/65

//Subclas a clasei Fruct//Para este un fruct->este respec tat spiritul natural

//a l motenirii

//Se adaug noi a tribute informaionale

//Se adaug metode specifice

//Este un exemplu clasic de specializare prin adaugare class Para extends Fruct{

priva te double greutate;

priva te int forma;

Para(int t ,double g,int f)

{

s

Programare Orientata Pe Obiecte II Bocu

Documents

Transcript of Programare Orientata Pe Obiecte II Bocu