Differences
This shows you the differences between two versions of the page.
|
poo:breviare:breviar-04 [2018/09/22 08:44] mihai.nan created |
poo:breviare:breviar-04 [2023/10/16 19:37] (current) carmen.odubasteanu [Laboratorul 4] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Laboratorul 4 ====== | ====== Laboratorul 4 ====== | ||
| - | * Responsabil laborator: Mihai Nan | + | |
| - | * Profesor coordonator: Carmen Odubasteanu | + | |
| ===== Principii POO ===== | ===== Principii POO ===== | ||
| Line 7: | Line 6: | ||
| ==== Ierarhizarea ==== | ==== Ierarhizarea ==== | ||
| - | * La fel ca notiunile de **abstractizare** si **incapsulare**, **ierarhizarea** este un concept fundamental in programarea orientata pe obiecte. Rolul **procesului de abstractizare** (cel care conduce la obtinerea unei abstractiuni) este de a identifica si separa, dintr-un punct de vedere dat, ceea ce este important de stiut despre un obiect si ceea ce nu este important. Rolul **mecanismului de incapsulare** este de a permite ascunderea a ceea ce nu este important de stiut despre un obiect. Dupa cum se poate observa, **abstractizarea** si **incapsularea** tind sa micsoreze cantitatea de informatie disponibila utilizatorului unei abstractiuni. O cantitate mai mica de informatie conduce la o intelegere mai usoara a respectivei abstractiuni. Dar ce se intampla daca exista un numar foarte mare de abstractiuni? | + | La fel ca notiunile de **abstractizare** si **incapsulare**, **ierarhizarea** este un concept fundamental in programarea orientata pe obiecte. Rolul **procesului de abstractizare** (cel care conduce la obtinerea unei abstractiuni) este de a identifica si separa, dintr-un punct de vedere dat, ceea ce este important de stiut despre un obiect si ceea ce nu este important. Rolul **mecanismului de incapsulare** este de a permite ascunderea a ceea ce nu este important de stiut despre un obiect. Dupa cum se poate observa, **abstractizarea** si **incapsularea** tind sa micsoreze cantitatea de informatie disponibila utilizatorului unei abstractiuni. O cantitate mai mica de informatie conduce la o intelegere mai usoara a respectivei abstractiuni. Dar ce se intampla daca exista un numar foarte mare de abstractiuni? |
| - | * Intr-o astfel de situatie, des intalnita in cadrul dezvoltarii sistemelor software de mari dimensiuni, simplificarea intelegerii problemei de rezolvat se poate realiza prin ordonarea acestor abstractiuni, formandu-se astfel **ierarhii** de abstractiuni. | + | |
| + | Intr-o astfel de situatie, des intalnita in cadrul dezvoltarii sistemelor software de mari dimensiuni, simplificarea intelegerii problemei de rezolvat se poate realiza prin ordonarea acestor abstractiuni, formandu-se astfel **ierarhii** de abstractiuni. | ||
| <note warning> | <note warning> | ||
| Line 16: | Line 16: | ||
| === Ierarhia pe obiecte - Relatia de agregare === | === Ierarhia pe obiecte - Relatia de agregare === | ||
| - | * Ierarhia de obiecte este o ierarhie de tip intreg "\parte". Sa consideram un obiect dintr-o astfel de ierarhie. Pe nivelul ierarhic imediat superior acestui obiect se gaseste obiectul din care el face parte. Pe nivelul ierarhic imediat inferior se gasesc obiectele ce sunt parti ale sale. | + | Ierarhia de obiecte este o ierarhie de tip intreg "\parte". Sa consideram un obiect dintr-o astfel de ierarhie. Pe nivelul ierarhic imediat superior acestui obiect se gaseste obiectul din care el face parte. Pe nivelul ierarhic imediat inferior se gasesc obiectele ce sunt parti ale sale. |
| - | * Este simplu de observat ca o astfel de ierarhie descrie relatiile de tip **part of** dintre obiecte. In termeni aferenti programarii orientate pe obiecte, o astfel de relatie se numeste **relatie de agregare**. | + | |
| - | * In secventa de cod de mai jos se poate vedea cum este transpusa o astfel de relatie in codul sursa Java. | + | |
| + | Este simplu de observat ca o astfel de ierarhie descrie relatiile de tip **part of** dintre obiecte. In termeni aferenti programarii orientate pe obiecte, o astfel de relatie se numeste **relatie de agregare**. | ||
| + | |||
| + | |||
| + | In secventa de cod de mai jos se poate vedea cum este transpusa o astfel de relatie in codul sursa Java. | ||
| <code java> | <code java> | ||
| Line 44: | Line 48: | ||
| === Ierarhia de clase - Relatia de mostenire === | === Ierarhia de clase - Relatia de mostenire === | ||
| - | * Ierarhia de clase este o ierarhie de tip generalizare"\"" specializare. Sa consideram o clasa "B" care face parte dintr-o astfel de ierarhie. Pe nivelul ierarhic imediat superior se gaseste o clasa "A" care defineste o abstractiune mai generala decat abstractiunea definita de clasa "B". Cu alte cuvinte, clasa "B" defineste un set de obiecte mai speciale incluse in setul de obiecte definite de clasa "A". Prin urmare, putem spune ca "B" **este un fel de** "B". | + | Ierarhia de clase este o ierarhie de tip generalizare"\"" specializare. Sa consideram o clasa ''B'' care face parte dintr-o astfel de ierarhie. Pe nivelul ierarhic imediat superior se gaseste o clasa ''A'' care defineste o abstractiune mai generala decat abstractiunea definita de clasa ''B''. Cu alte cuvinte, clasa ''B'' defineste un set de obiecte mai speciale incluse in setul de obiecte definite de clasa ''A''. Prin urmare, putem spune ca ''B'' **este un fel de** ''B''. |
| - | * Dupa cum se poate observa, ierarhia de clase este generata de relatii de tip "is a" dintre clasele de obiecte, aceasta relatie numindu-se **relatie de mostenire**. In cadrul unei astfel de relatii, clasa "A" se numeste **superclasa** a clasei "B", iar "B" se numeste **subclasa** a clasei "A". | + | |
| - | * Dupa cum am spus inca de la inceput, **mostenirea** este **inima** programarii orientate pe obiecte. Este normal sa apara intrebarea: de ce? Ei bine, limbajele de programare orientate pe obiecte, pe langa faptul ca permit programatorului sa marcheze explicit relatia de mostenire dintre doua clase, mai ofera urmatoarele facilitati: | + | |
| - | - o **subclasa** preia (**mosteneste**) reprezentarea interna (**datele**) si comportamentul (**metodele**) de la **superclasa** pe care o mosteneste. | ||
| - | - un obiect instanta a unei subclase poate fi utilizat in locul unei instante a superclasei sale; | ||
| - | - legarea dinamica a apelurilor metodelor. | ||
| - | * In cadrul acestui laborator, ne vom ocupa de primele doua aspecte enuntate, cunoscute si sub numele de **mostenire de clasa**, respectiv **mostenire de tip**. | + | Dupa cum se poate observa, ierarhia de clase este generata de relatii de tip "is a" dintre clasele de obiecte, aceasta relatie numindu-se **relatie de mostenire**. In cadrul unei astfel de relatii, clasa ''A'' se numeste **superclasa** a clasei ''B'', iar ''B'' se numeste **subclasa** a clasei ''A''. |
| + | |||
| + | |||
| + | Dupa cum am spus inca de la inceput, **mostenirea** este **inima** programarii orientate pe obiecte. Este normal sa apara intrebarea: de ce? Ei bine, limbajele de programare orientate pe obiecte, pe langa faptul ca permit programatorului sa marcheze explicit relatia de mostenire dintre doua clase, mai ofera urmatoarele facilitati: | ||
| + | |||
| + | |||
| + | - o **subclasa** preia (**mosteneste**) reprezentarea interna (**datele**) si comportamentul (**metodele**) de la **superclasa** pe care o mosteneste. | ||
| + | - un obiect instanta a unei subclase poate fi utilizat in locul unei instante a superclasei sale; | ||
| + | - legarea dinamica a apelurilor metodelor. | ||
| + | |||
| + | In cadrul acestui laborator, ne vom ocupa de primele doua aspecte enuntate, cunoscute si sub numele de **mostenire de clasa**, respectiv **mostenire de tip**. | ||
| <note warning> | <note warning> | ||
| Line 75: | Line 85: | ||
| == Mostenirea de clasa in Java == | == Mostenirea de clasa in Java == | ||
| - | * **Mostenirea de clasa** este o facilitate a limbajelor de programare orientate pe obiecte care permite sa definim implementarea unui obiect in termenii implementarii altui obiect. Mai exact, **subclasa** preia sau "mosteneste" reprezentarea interna ("datele") si comportamentul ("metodele") de la **superclasa**. | + | **Mostenirea de clasa** este o facilitate a limbajelor de programare orientate pe obiecte care permite sa definim implementarea unui obiect in termenii implementarii altui obiect. Mai exact, **subclasa** preia sau "mosteneste" reprezentarea interna ("datele") si comportamentul ("metodele") de la **superclasa**. |
| - | * Dupa cum se poate observa, acest principiu POO permite reutilizarea de cod. | + | Dupa cum se poate observa, acest principiu POO permite reutilizarea de cod. |
| - | * Pentru a intelege mai bine conceptul de mostenire de clasa, dar si pentru o exemplificare a regulilor de vizibilitate a membrilor de clasa, se propune analizarea urmatoarei secvente de cod Java. Se poate observa ca, din perspectiva unui client, nu se face distinctie intre membrii mosteniti de o clasa si cei specifici ei. | + | |
| + | |||
| + | Pentru a intelege mai bine conceptul de mostenire de clasa, dar si pentru o exemplificare a regulilor de vizibilitate a membrilor de clasa, se propune analizarea urmatoarei secvente de cod Java. Se poate observa ca, din perspectiva unui client, nu se face distinctie intre membrii mosteniti de o clasa si cei specifici ei. | ||
| <code java> | <code java> | ||
| Line 113: | Line 125: | ||
| </code> | </code> | ||
| - | = **Cuvantul cheie super = | + | == Cuvantul cheie super == |
| - | * In cazul in care exista date care au acelasi nume si in **subclasa**, dar si in **superclasa**, este posibil sa se produca anumite confuzii, datorate acestui inconvenient. | + | In cazul in care exista date care au acelasi nume si in **subclasa**, dar si in **superclasa**, este posibil sa se produca anumite confuzii, datorate acestui inconvenient. |
| - | * In exemplul de mai jos, ce camp de date este initializat (cel din **subclasa** sau cel din **superclasa**)? Care ar putea fi explicatia acestui raspuns? | + | |
| - | <code java> | ||
| - | class A { | ||
| - | int nr; | ||
| - | } | ||
| - | class B extends A { | + | In exemplul de mai jos, ce camp de date este initializat (cel din **subclasa** sau cel din **superclasa**)? Care ar putea fi explicatia acestui raspuns? |
| - | int nr; | + | |
| - | public B() { | + | |
| - | this.nr = 1; | + | |
| - | } | + | |
| - | } | + | |
| - | </code> | + | |
| <note important> | <note important> | ||
| Line 156: | Line 158: | ||
| == Mostenirea de tip in Java == | == Mostenirea de tip in Java == | ||
| - | * **Mostenirea de tip** este o facilitate a limbajelor de programare orientate pe obiecte care permite sa utilizam o instanta a unei subclase in locul unei instante a superclasei sale. | + | * **Mostenirea de tip** este o facilitate a limbajelor de programare orientate pe obiecte care permite sa utilizam o instanta a unei subclase in locul unei instante a superclasei sale. |
| - | * Pentru o mai buna intelegere, vom analiza un exemplu elocvent. | + | |
| + | * Pentru o mai buna intelegere, vom analiza un exemplu elocvent. | ||
| <code java> | <code java> | ||
| Line 232: | Line 235: | ||
| ==== Supraincarcarea vs Supradefinirea metodelor ==== | ==== Supraincarcarea vs Supradefinirea metodelor ==== | ||
| **Supraincarcarea** si **supradefinirea** metodelor sunt doua concepte extrem de utile ale programarii orientate pe obiecte, cunoscute si sub denumirea de **polimorfism**, si se refera la: | **Supraincarcarea** si **supradefinirea** metodelor sunt doua concepte extrem de utile ale programarii orientate pe obiecte, cunoscute si sub denumirea de **polimorfism**, si se refera la: | ||
| - | - **supraincarcarea (overloading)**: in cadrul unei clase pot exista metode cu acelasi nume cu conditia ca signaturile lor sa fie diferite (lista de argumente primite sa difere fie prin numarul argumentelor, fie prin tipul lor) astfel incat la apelul functiei cu acel nume sa se poata stabili, in mod unic, care dintre ele se executa. | + | |
| - | - **supradefinirea (overriding)**: o subclasa poate rescrie o metoda a clasei parinte prin implementarea unei metode cu acelasi nume si aceeasi signatura ca ale superclasei. | + | |
| + | - **supraincarcarea (overloading)**: in cadrul unei clase pot exista metode cu acelasi nume cu conditia ca signaturile lor sa fie diferite (lista de argumente primite sa difere fie prin numarul argumentelor, fie prin tipul lor) astfel incat la apelul functiei cu acel nume sa se poata stabili, in mod unic, care dintre ele se executa. | ||
| + | - **supradefinirea (overriding)**: o subclasa poate rescrie o metoda a clasei parinte prin implementarea unei metode cu acelasi nume si aceeasi signatura ca ale superclasei. | ||
| + | |||
| + | {{ :poo:breviare:java_overloading.jpg?600 |}} | ||
| <note warning> | <note warning> | ||
