Sunteți pe pagina 1din 12

Programarea orientata obiect Programarea orientata obiect (POO) a devenit din ce in ce mai raspindita in ultimii ani.

Unul dintre motivele raspindirii este speranta ca aceasta noua tehnica de programare va conduce la cresterea productivitatii si la imbuntatirea claritatii programelor. Un alt motiv al cresterii popularitatii unor limbaje obiectuale precum C++ sau Java este speranta ca deplasarea de la deprinderile deja dobandite spre acesta noua tehnica de programare, intr-un acelasi limbaj, se va putea obtine fara mare efort. Din nefericire acest lucru este mai greu de realizat deoarece programarea orientata obiect este mai mult decit o simpla colectie de noi limbaje de programare; este de fapt o noua modalitate de a gandi despre tehnicile de calcul, despre structurea datelor intr-un computer. Programarea orientata obiect influenteaza direct felul in are noi vedem lumea; deseori este numita "o noua paradigma in programare". Cuvantul paradigma vine sau din latinescul paradigma sau din grecescul paradeigma. Semnificatia initiala era aceea a unui exemplu ilustrativ. Definitia a fost apoi extinsa acum insemnind un set de teorii, standarde si metode care reprezinta laolalta o noua modalitate de o organiza cunostintele si deci, implicit, o noua modalitate de a vedea lumea. In acest sens, programarea orientata obiect este o noua paradigma. Incercarea de a privi lumea prin prisma orientarii obiect, ne forteaza sa reconsideram felul in care reprezentam informatiile, le structuram in interiorul unui computer, felul in care le prelucram, precum si felul in care ne construim computerele. Ne forteaza deci sa ne schimbam felul in care privim lumea. Pentru a ilustra cateva din ideile majore in progrmarea orientata obiect sa vedem mai intai cum rezolvam in modul cel mai firesc o problema din lumea reala iar apoi sa vedem cum anume putem modela cu ajutorul unui sistem de calcul, de o maniera cat mai apropiata, tehnicile pe care le-am folosit pentru a rezolva problema din lumea reala. Orientatarea obiect Sa vedem cum rezolvam o problema in viata reala si sa incercam sa desprindem din aceasta elementele care ne-ar putea ajuta sa programam computerele sa lucreze de o maniera asemanatoare. Sa presupunem de pilda ca doresc sa trimit un mesaj de felicitare prietenului meu Flaviu care se afla intr-un alt oras. Actiunea trebuie mai intai initiata. Initierea actiunii o fac cu ajutorul unui mesaj pe care-l transmit telefonic agentului Miki de la posta, care se ocupa cu preluarea comenzilor de telegrame prin telefon. In acest mesaj va trebui sa specific actiunea ce vreau sa se efectueze si contiutul mesajului pe care vreau sa il trimit. In momentul in care a preluat mesajul meu (comanda), Miki este unicul raspunzator cu ducerea la bun sfarsit a actiunii. Deci initierea actiunii s-a facut prin transmiterea unui mesaj de la emitator (eu) la un agent receptor (Miki). Mesajul reprezinta pentru Miki o cerere de actiune. Miki va duce la bun sfarsit actiunea ceruta recurgand la un set de operatii (o metoda). Sa subliniem acum un fapt in aparenta minor dar important: eu nu trebuie sa cunosc cum functioneaza metoda utilizata. In cazul nostru,

metoda consta in transmiterea informatiilor unui coleg de-al lui (un alt Miki, sa zicem Miki2) care va recurge la o alta metoda pentru finalizarea cererii. De pilda va scrie felicitarea si va delega un factor postal sa o inmineze destinatarului (Flaviu). Este evident ca, pentru a transmite felicitarea cu pricina lui Flaviu, as fi putut sa procedez si altfel. De pilda sa-mi sun la telefon sora care locuieste in acelasi oras cu Flaviu si sa-i transmit cererea (mesajul). Sorei mele ma voi adresa in mod asemanator factorului postal, si anume specificand actiunea si continutul mesajului. Ea, recurgind de buna seama la o metoda proprie, putea duce cererea la indeplinire personal. Prin urmare, interpretarea cererii depinde de agent. Acest exemplu simplu ne permite introducerea unor concepte de baza in orientarea obiect. Entitatile implicate in actiune le vom numi obiecte. Obiectele responsabile cu ducerea la indeplinire a actiunii le vom numi agenti. Setul de operatii prin care se realizeaza o actiune il vom numi metoda. Cererea de actiune o vom numi mesaj. Setul numelor metodelor unui obiect il vom numi interfata. Citeva observatii se cuvin facute in acest moment. Mai intii ca acelasi mesaj transmis unor obiecte diferite conduc la apelarea acelorasi metode. Eu voi folosi o interfata care imi permite sa trimit un mesaj catre obiectele specializate in trimiterea mesajelor si voi chema intodeauna aceeasi metoda. In convorbirea cu agentul postal sau cu sora mea cei folosi aceeasi adresare: trimite mesaj, adresant, continut. Apoi ca receptorul (agentul responsabil cu actiunea) nu stie pana in momentul "rularii" ce metoda va folosi. Legatura intre mesaj si metoda este "tarzie", spre deosebire de legatura dintre programul principal si un subprogram care este dinainte cunoscuta, este facuta mai "timpurie" (in momentul compilarii). Este de asemenea important sa remarcam faptul ca eu am cunoscut dinainte de lansarea mesajului la ce fel de comportament ma pot astepta din partea lui Miki, deoarece el face parte din marea familie (clasa) a agentilor de posta. Spunem ca el este o instanta a clasei agentilor de posta. Mai mult, eu stiu despre el ca este un furnizor de servicii si prin urmare stiu ca se va comporta ca un vanzator (va trebui sa-i platesc pentru serviciile vandute, va fi disponibil intre anumite ore, etc). Pot afirma, prin urmare, ca clasa agentilor postali este de fapt o subclasa a clasei vanzatorilor, sau altfel spus, clasa vanzatorilor este o superclasa. Rationamentul poate continua cu observatia ca toti vanzatorii sunt oameni, oamenii sunt mamiferi si ca toate mamiferele sunt obiecte materiale. Ceea ce obtinem este o ierarhie de clase in care fiecare clasa prin mostenire dobindeste caracteristicile superclasei din care este derivata. (De pilda, agentul fiind vanzator va cere bani pentru servicii, fiind mamifer probabil ca s-a nascut dintr-o mama, fiind obiect material probabil ca daca l-as intilni as putea sa-l ating.) Este evident ca mostenirea trebuie sa fie o caracteristica a tuturor limbajelor de programare orientate obiect. Forta ei consta in aceea ca

acelasi cod este reutilizat. Daca vreau sa construiesc un agent postal virtual, mostenind clasa vanzator nu va mai trebui sa scriu eu metodele care fac tranzactiie financiare, el le va sti automat. Eu va trebui sa adaug metodele de transmitere a mesajelor. Faptul ca acelasi mesaj adresat unor agenti diferiti poate declansa metode diferite poarta numele de polimorfism. Polimorfismul este de fapt adecvarea codului la obiect, interpretarea mesajului depinzind de obiect. Dupa aceasta prezentare globala a conceptelor de baza din POO vom discuta pe rand fiecare concept. Concepte de baza in OO Pentru a intelege conceptele de baza ale OO este bine sa ne reamintim care sunt scopurile POO. Pornind de la observatia ca in cazul programarii sa-i spunem clasice, aproximativ 60% pana la 80% din efortul industriei software era dedicat nu producerii de noi sisteme soft ci modificarii lor dupa ce au fost create [MEY], rezulta ca scopurile POO sunt imbunatatirea :

gradului de reutilizare scalabilitatii portabilitatii fiabilitatii si eficientei

Cresterea gradului de reutilizare a condus la ideea construirii unor componente soft (clase) care pot fi utilizate in constructia sistemelor de o maniera asemenatoare celei in care utilizam componentelor hard (circuitele integrate). Mecanisme cum ar fi mostenirea si interfetele ne permit derivarea unor componente noi din cele vechi. Imbunatatirea scalabilitatii inseamna gandirea unor modalitati de diminuare a efortului investit in efectuarea schimbarilor in sistemele soft. In sistemele soft traditionale, interdependenta crescuta a modulelor declanseaza reactii in lant la fiecare modficare a unui modul. O arhitectura OO, descentralizata, permite efectuare schimbarilor fara modificari majore in celelalte componente soft. Cresterea portabilitatii inseamna descresterea eforturilor necesare adaptarii sistemului soft la un nou sistem de operare sau la o noua arhitectura hard. La modul ideal aceasta ar insemna sa compilam o singura data si sa putem rula sistemul soft pe orice masina. O fiabilitate sporita este asigurata de variabile statice, de o programare bazata pe evenimente, de mecanisme pentru manipularea exceptiilor si de mecanisme eficiente de colectarea a gunoaielor. Cresterea eficientei este asigurata de crearea unor bibioteci de componente gata pentru a fi utilizate, furnizate odata cu mediul de dezvoltare. Eficienta mai este asigurata de toate celelalte cracteristici ale POO care contribuie direct sau indirect la scaderea numarului de erori,

modificarea cu usurinta a componentelor, portabilitate crescuta si costuri scazute pentru dezvoltare. Arhitectura Tehnologia orientata obiect afecteaza in primul rand arhitectura sistemelor soft. Prin arhitectura unui sistem soft intelegem felul in care acesta este organizat din componente (obiecte) care interactioneaza intre ele. Programarea la scara mica se va ocupa de realizarea acestor componenete iar programarea la scara mare se va ocupa de gruparea componentelor soft intr-un sistem coerent. Arhitectura este importanta deoarece scalabilitatea sistemului soft si gradul in care componentele lui sunt reutilizabile depind de flexibilitatea structurii sistemului si de gradul in care aceste componente au o functionalitate autonoma. Evident, arhitectura trebuie mentinuta cat mai simpla posibil. Dar prin ce anume se deosebeste arhitectura unui sistem soft OO de arhitectura unui sistem soft traditional? In programarea traditionala datele sunt centrale si programul contine subrutinele de manipulare a acestor date. Subrutinele (sau modulele sau functiile sau un alt nume) sunt prin urmare blocurile fundamentale ale programari traditionale si au ca sarcina efectuarea unei anumite parti din sarcina sistemului soft. Aproape toate operatiile sunt implementate ca subrutine. In programarea OO sunt unite doua concepte traditionale - cel de subrutina si cel de tipuri de date intr-unul singur: cel de clasa. Blocurile fundamentale vor fi structurile de date, numite clase, care contin in interiorul lor functii care le determina un anumit comportament si care realizeaza functiile subrutinei. Programarea orientata obiect foloseste conceptul de module pentru segmentarea partilor independente ale unui program. Aceste module realizeaza anumite sarcini din program si furnizeaza rezultatele altor module. De exemplu un modul va opera pe baza de date, altul va afisa datele la client. Modulele contin obiecte. Obiectele contin structuri de date si metode de manipulare a acestor date. Faptul ca se pune accent pe structurile de date nu inseamna deci ca se neglijeaza functiile. Insa intr-o arhitectura OO ele sunt subordonate abstractiilor de date (tipurilor de date de obiecte). Daca intr-o abordare traditionala (bazata pe decompozitia functiilor) descrierea datelor se gaseste sub forma declaratiilor de tip, intr-o abordare OO functiile pot exista numai daca sunt parte a unei structuri de date, a unei clase. Clasele Elementele de baza ale sistemelor soft orientate obiect sunt clasele. Prin clase vom intelege orice structura de date relevanta pentru sistemul soft. Observatia fundamentala este ca desi intr-o

abordare OO totul este organizat in jurul structurilor de date, acestora le sunt atasate operatiile specifice transformindu-le in entitati care pot functiona autonom. Intr-o abordare OO stricta, fiecare operatie apartine unei singure clase. Realizarea unui sistem soft este privita de programarea OO de o maniera similara construirii unui sistem hard, adica din componente. Deosebirea este ca aceste componente sunt de aceasta data componente soft (clase) care au o proprietate speciala si anume ca din ele se pot deriva cu usurinta componente mai specializate.

Construirea unui sistem soft inseamna deci selectarea claselor (modulelor, structurilor de date, etc) necesare si identificarea (definirea) interconexiunilor lor. Clasele necesare pot fi luate fie din bibliotecile (ierarhiile de clase) furnizate odata cu limbajul si mediul de dezvoltare, fie pot fi derivate din acestea si extinsa (sau restransa) functionalitatea lor. In ceea ce priveste conexiunile dintre module, programarea traditionala nu a reusit limitarea dependentelor; un modul putea foarte bine sa depinda de un altul. Modificarea unui modul atragea dupa sine o reactie in lant ceea ce facea extrem de dificile sarcinile legate de scalabilitatea sistemelor, reutilizarea modulelor soft, coerenta interfetelor si fiabilitatea sistemelor soft. Unul din motivele majore ale acestor probleme era mecanismul numit variabile globale care permitea unui modul sa declare o variabila pe care multe alte module sau poate chiar toate o puteau accesa si modifica. Conceptul de variabila globala introducea un cuplaj puternic intre module deoarece toate modulele care accesau o asemenea variabila deveneau dependente de toate modulele care o puteau modifica. In programarea OO, intre clase nu pot exista decat doua tipuri de relatii: cea de furnizare de servicii si cea de mostenire. Instantele Obiectele sunt instante ale claselor. Putem privi clasele ca pe niste proiecte de componente iar instantele ca pe componente realizate dupa acele proiecte. Evident ca dintr-un proiect se pot instantia (crea) oricat de multe componente (instante). Evident de asemenea ca din proiectul (clasa) unei componente soft se poate deriva proiectul (clasa) unei alte componente soft care va mosteni toate proprietatile celei dintai la care putem adauga si altele sau, de ce nu, le putem restrange pe cele dintai. Controlul comunicatiei intre componente

Am aratat anterior ca gradul de autonomie al componentelor unui sistem soft depinde decisiv de comunicarea intre componente. Cu cat comunicarea este mai strict controlata cu atat autonomia (si cu aceasta gradul in care componentele pot fi descrise ca reutilizabile, scalabile si fiabile) este mai mare. Am aratat de asemenea ca pentru a limita interconexiunile dintre clase, programarea OO renunta la conceptul de variabile globale. Intr-o abordare OO stricta, intre clase sunt permise numai doua tipuri de relatii: cea de furnizare de servicii si cea de mostenire. Trebuie aratat ca cele doua tipuri de relatii nu reprezinta o tehnica de design ci una de implementare. Relatia tip furnizare de servicii mai este cunoscuta si ca o relatie de tip "has-a" (intr-o traducere libera, "are_o" sau "are_un"). O clasa este considerata client a alteia (numita furnizor) daca se bazeaza pentru nevoile ei de functionalitati oferite de furnizor. Natura acestui tip de relatie poate fi intelesa prin analogie cu relatia de afaceri client-furnizor; este o relatie bazata pe responsabilitati precise ale instantelor celor doua clase. De pilda, clasa AtomDeHidrogen "are-un" Electron si "are-un" Proton. Instanta AtomDeHidrogen are nevoie de o instanta a clasei Proton si o instanta a clasei Electron. Reprezentarea grafica a acestui tip de relatie este:

O relatie de tipul "has-a" are deci loc intre clase care nu pot fi derivate unele din celelalte. Relatia tip mostenire mai este cunoscuta si ca o relatie de tip "is-a" (intr-o traducere libera, "este_o" sau "este_un"). O relatie de tipul "is_a" are loc intre doua clase dintre care una este derivata mai specializata a celeilalte. Vom numi clasa care extinde functionalitatea altei clase ca fiind succesor iar cea a carei functionalitate este extinsa o vom numi ancestor. Datele si comportamentul ancestorului vor forma un subset al datelor si comportamentului succesorului. De pilda, electronul "este_o" particula. Din paragrafele anterioare rezulta ca clasele sunt componente soft autonome intr-o mare masura. Din limitarea tipurilor de relatii care pot exista intre clase rezulta in plus ca interdependenta uneia de alta, daca exista, este explicita si limitata fie la o relatie de tip furnizare de servicii fie la o relatie tip mostenire, ca in desenul urmator.

Abstractizarea si incapsularea (ascunderea informatiei) Pentru ca o clasa sa poata fi folosita de o alta, OO descrie clasele numai prin lista operatiilor aplicabile instantelor acelei clase. Evident ca toate clasele trebuie insotite de o declaratie privind comportamentul clasei si pentru a le face folosibile si de catre altcineva in afara de proiectant. Aceasta lista a operatiilor aplicabile clasei se numeste interfata. In afara operatiilor declarate in interfata (care descriu comportamentul clasei), clasele au si proprietati de stare care sunt considerate irelevante pentru utilizatorul clasei dar sunt esentiale pentru functionalitatea interna a clasei. Acete informatii nu sunt furnizate utilizatorului ci sunt ascunse, incapsulate. Ascunderea informatiei nu este legata de faptul ca producatorul clasei nu doreste sa se stie cum anume a implementat o functionalitate ci de faptul ca producatorul doreste sa-l scuteasca pe utilizator de detaliile inutile. In programarea orintata obiect s-au impus doua principii: 1. Utilizatorul trebuie sa primeasca toate informatiile necesare utilizarii corecte a claselor si nimic mai mult. 2. Proiectantul claselor trebuie sa primeasca toate informatiile necesare realizarii lor complete si nimic mai mult. Acest fel de administrare a informatiei (de ascundere a ei) poarta numele de incapsulare. Prin urmare, orice clasa poate fi privita din doua puncte de vedere diferite:

cel al poiectantului clasei care vede aspectele legate de implementare, variabilele care vor descrie starea clasei si metodele clasei care ii vor descrie comportamentul cel al utilizatorului care cunoaste doar interfata, felul in care poate fi utilizata clasa

Interfata utilizator descrie cum anume interactioneaza obiectul cu lumea exterioara. Utilizatorul nu va avea acces decit la ceea ce este descris in interfata. Implementarea descrie cum anume este realizata comportarea obiectului asa cum este declarata in intefata. Cind un proiectant utilizeaza o componenta soft, el trebuie sa inteleaga numai natura componentei si intefata ei (comportamentul). Nu este necesar ca acesta sa cunoasca informatii detaliate despre tehnica utilizata pentru a implementa componenta. In acest fel, interconectabilitatea intre sistemele soft este redusa. Importanta acestui aspect este evidenta daca ne aducem aminte ca gradul mare al interconectabliatii intre modulele soft din programarea traditionala a fost unul din principalele cauze ale complexitatii sistemelor soft.

Programare bazata pe evenimente In orientarea obiect, programarea nu este nimic altceva decit simularea unui model de univers. In prezenarea limbajelor orientate obiect se pune de regula accent in relevarea caracteristicile sintactice ale acestor limbaje care le deosebesc fie de limbajele procedurale in general fie de predecesoarele lor neorienatate obiect (vezi C si C++ sau Pascal si Pascal orientat pe obiecte). Astfel, prezentarea tinde sa puna accent mai mult pe aspecte cum ar fi clasele, mostenirea, mesajele, rutarea mesajelor, metode statice, si altele. Cel mai important aspect al limbajelor OO nu este insa legat de sintaxa ci este legat de insasi activitatea de programare care este bazata pe evenimente si pe delegarea responsabilitatilor. Bertrand Meyer [MEYE] o numeste metafora contractului. Timothy Budd [BUDD], numeste aceasta tehnica de programare ca fiind proiectare bazata pe responsabilitati (en. responsibility driven design). El face analogie intre un sistem soft OO si un copil. De la amandoi te astepti la un anumit comportament chiar atunci cand regulile nu sunt respectate suta la suta. In acelasi timp, atat la copil cat si la sistemul soft OO, responsabilitatea atribuita celor doi insemna si un anumit grad de independenta si de noninterferenta. Daca ii spui unui copil ca este responsabil cu plimbarea cainelui, asta nu inseamna ca trebuie sa il urmaresti pas cu pas, in permananta, de fiecare data cand executa aceasta actiune, pentru ca nu aceasta este natura responsabilitatii. De o maniera asemanatoare se intimpla lucrurile si cu programarea orientata obiect. Sa ne amintim ca in cazul programarii conventionale, procedurale, aceasta inseamna programarea ca

ceva sa actioneze asupra a ceva (de pilda modificarea unei inregistrari, actualizarea unui tablou, etc). Rezulta ca acea parte de cod care efectueaza operatia (procedura), trebuie sa fie intim legata de datele si de elementele de control ale altor parti de cod din sistem. Aceasta dependenta se realizeaza prin intermediul unor variabile globale (de pilda prin utilizarea valorilor pointerilor). Proiectarea unui sistem soft bazat pe evenimente incearca sa reduca aceasta dependenta la cel mai coborit nivel posibil. Desigur ca incercari s-au mai facut. Ascunderea informatiei si modularizarea sunt prezente si in limbajele procedurale. Filosofia designului, proiectarii bazate pe evenimente, face din ascunderea informatiei si modularizare o adevarata arta. Rezulta de aici unul din marile beneficii ale programarii orientate obiect: subsistemele soft pot fi reutilizate de la un sistem la altul. Posibilitatea de a reutiliza codul implica faptul ca produsul soft poate sa aiba portiuni de cod care nu sunt specifice unui anumit domeniu. Realizarea comportarilor specifice domeniului respectiv se face prin delegarea responsabilitatilor unor secvente soft care sunt caracteristice acelui domeniu si acelei aplicatii. Ierarhiile de clase si mostenirea Pentru a evita redundanta, clasele care reprezinta variante le acelorasi structuri abstracte de date sunt organizate in structuri numite ierarhii de clase. Mostenirea este proprietatea prin care o clasa derivata dintr-o alta (numita acum superclasa) poseda toate atributele de stare si comportamentul superclasei. Avantajul unei asemenea organizari consta in aceea ca proiectantii pot stapini mai bine complexitatea unor sisteme soft pe de o parte iar pe de alta parte se creaza posibilitatea de a reutiliza componentele soft prin mostenire. Clasa derivata dintr-o alta clasa (superclasa) va mosteni toate proprietatile acesteia la care putem adauga si altele sau, de ce nu, le putem restringe pe cele dintii. Restringerea sau modificarea unor metode mostenite poarta numle de rescriere. POO, in general, pune un accent deosebit in reutilizarea codului si in dezvoltarea de elemente soft cu aplicabilitate cit se poate de generala. Mostenirea este o tehnica de implementare (si nu una de design cum ar parea) deosebit de utila din acest punct de vedere. Prin mostenire intelegem proprietatea prin care instantele unei clase pot sa acceseze atit datele cit si comportamentul, adica metodele asociate cu clasa din care clasa instantiata a fost derivata. Aceasta din urma se mai numeste si superclasa. Mostenirea este totdeauna tranzitiva. Asa cum o clasa poate mosteni trasaturile de la superclasa din care este derivata, superclasa la rindul ei poate fi clasa derivata dintr-o alta superclasa. Cu alte cuvinte, daca electronul este o subclasa a clasei leptonilor iar clasa leptonilor este la rindul ei o sublclasa a clasei particule ideale, atunci electronul va mosteni proprietati (date si metode) atit de la clasa ParticulaIdeala cit si de la clasa Lepton. Mostenirea inseamna deci ca atit datele cit si comportamentul asociate cu o clasa copil sunt totdeauna o extensie, deci un set mai larg, a proprietatilor asociate cu clasa parinte.

O subclasa trebuie sa aiba toate proprietatile unei clase parinte precum si alte propritati suplimentare. Pe de alta parte, deoarece o clasa copil este mai specializata, sau prezinta anumite restrictii fata declasa parinte, poate exiista o restringere a proprietatilor clasei parinte. Aceasta posibilitate, pendularea intre extinderea respectiv restringerea proprietatilor, face din mostenire o tehnica de forta in POO. Trebuie subliniat inca o data ca mostenirea se extinde atit asupra datelor, variabilelor cit si asupra metodelor deci comportamentului. Avantajele mostenirii Este evident ca atunci cind derivam o clasa dintr-o alta clasa, codul clasei din care facem derivarea nu mai trebuie rescris. (Implicatiile sunt deosebit de impotante nu numai sub aspectul economiei de timp si energie dar si prin aspectul cresterii lizibilitatii codului si scaderii costului de intretinere.) Aceleasi clase pot fi folosite in proiecte diferite, din clasele respective putindu-se deriva clasele de care este nevoie. Vom putea privi clasele ca pe niste componenete soft. Faptul ca putem deriva mai multe clase dintr-o aceeasi superclasa ne asigura ca, cel putin in mare, comportamantul va fi acelasi pentru toate clasele. Interfetele vor fi similare pentru acel grup de obiect ceea ce implica faptul ca nu se ofera utilizatorului o colectie eclectica de obiecte care sunt aproape identice dar care interactioneaza diferit. Daca mostenirea ne permite sa construim componenet soft reutilizabile, se pot crea biblioteci de componente reutilizabile pentru prototipuri rapide. Avantajul este ca proiectantii se pot concentra asupra acelei parti a sistemului soft care este noua. Astfel, un sistem soft poate fi generat mai repede si mai usor, conducind la un stil de programare numit proiectare rapida (en. Rapid Prototyping) sau programare exploratorie (en. exploratory programing). In acest caz proiectarea unui sistem soft incepe cu realizarea unui prototip care este pus la dispozitia utilizatorilor. Acestia il testeaza si pe baza observatiilor lor se construieste un alt sistem, imbunatatit pe baza experientei, si asa mai departe, sistemul este perfectionat dupa mai mute iteratii. Acest stil de programare este folositor in mod deosebit atunci cind scopul sistemului soft si cerintele utlizatorului nu pot fi formulate clar inca de la inceput. Este cazul modelarilor stiintifice cind o anumita realitate fizica este inteleasa detul de vag la inceputul experimentului.

Polimorfismul si legare dinamica Polimorfismul se refera la posibilitatea ca o clasa instantiata, deci un obiect, sa posede mai multe metode cu acelasi nume dar cu parametrii diferiti. Aceasta ii asigura un comportament diferentiat in functie de parametrii furnizati la apelarea metodei. Acest comportament diferentiat poarta numele de legare dinamica sau tirzie. Vom reveni asupra conceptului pentru a arata prin ce difera de legarea timpurie din cazul programarii clasice. Tipuri statice

Preocuparea pentru asigurarea unei fiabilitati sporite a condus la asocierea cite unui tip pentru fiecare entitate soft folosita. Aceasta da posibilitate compilatorului sa verifice inainte de executie daca obiectele vor fi intotdeauna capabile sa execute operatiile cerute lor in timpul rularii. Managmentul automat al memoriei Rularea unui istem soft OO este asociata cu crearea unui numar mare de obiecte. La un moment dat, unele dintre acestea nu mai sunt necesare si memoria trebuie eliberata. O buna implementare a unui limbaj OO trebuie sa se refere si la aceasta problema furnizind un mecanism pentru managementul automat la memoriei (un colector de gunoaie) care, periodic, cauta obiectele devenite inutile si le distruge eliberind memoria. Obiecte Mecanismul de functionare a sistemelor soft OO presupun posibilitatea de a instantia clase (deci de a crea obiecte), de a le pregati (initializa) pentru utilizare si de a le da posibilitatea sa comunice (sa formuleze cereri) intre ele Prin creare intelegem alocarea spatiului de memoie pentru un nou obiect si asocierea unui nume pentru acel spatiu. Prin initializare vom intelege nu numai setarea valorilor initiale ale obiectului dar si stabilirea conditiilor minime pentru manipularea obiectului. Masura in care acest aspect este ascuns utilizatorului reprezinta un indiciu relativ la succesul incapsularii. Prin trimiterea de mesaje intre obiecte intelegem procesul prin care unui obiect i se adreseaza o cerere pentru realizarea unei actiuni. Creare si initilizare Mecanismul de creare si initializare a obiectelor difera de la limbaj la limbaj. Unul dintre motive este legat de modul in care este alocata respectiv eliberata (dealoca) memoria si pasii pe care trebuie sa-i faca programatorul pentru aceste procese. Alocarea poate fi statica sau dinamica si de aici si numele variabilelor pentru care se rezerva memorie. Variabilele statice sunt cele pentru care se rezerva locatie de memorie in momentul in care incepe sa se execute blocul de instructiuni in care acestea apar; memoria este eliberata in momentul in care este parasit blocul de instructiuni. Deci, memoria este rezervata cand incepe executia blocului de instructiuni si ramine alocata in timp ce programul este executat. Memoria este dealocata cand este parasit blocul de instructiuni. In momentul in care este rezervat spatiu (o adresa de memorie) pentru o variabila, se stabileste o legatura intre acel spatiu si numele variabilei. Numele variabilei nu poate fi schimbat in timpul executiei. Un exemplu de acest tip sunt variabilele din limbajul Java.

Variabilele dinamice sunt cele pentru care alocarea si dealocarea memoriei are loc in timpul executiei programului. Alocarea este facuta fie explicit, formuland o cerere de alocare, fie implicit, cand se trece controlul unor subrutine din program. Daca variabila contine adresa unei locatii de memorie in care se gaseste valoarea ei (datele), se creaza posibilitatea schimbarii dinamice a acelor date. Acest mecanism poarta numele de pointer. Variabile sunt utilizate in C++ si Pascal pe Obiecte. Acest mecanism forteaza utilizatorul sa determine cind anume o variabila dinamica devine candidat la distrugere (nu mai este necesara) si sa elibereze in mod explicit locatia de memorie o rutina din biblioteca sistem numita in ambele limbaje dispose.