Differences
This shows you the differences between two versions of the page.
|
poo-is-ab:laboratoare:06 [2024/10/27 21:44] razvan.cristea0106 [Concluzii] |
poo-is-ab:laboratoare:06 [2025/01/19 22:29] (current) razvan.cristea0106 |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Laborator 6 - Moștenire multiplă și agregare ===== | + | ===== Laborator 06 - Moștenire multiplă și agregare ===== |
| **Autor: Răzvan Cristea** | **Autor: Răzvan Cristea** | ||
| Line 22: | Line 22: | ||
| <note important>În general, găsirea unei combinații potrivite de clase care să respecte **moștenirea multiplă** poate fi o provocare, deoarece aceasta poate duce la situații **complexe** și **ambigue**. **Moștenirea multiplă** poate să genereze probleme atunci când două **clase părinte** au **metode** sau **membri comuni**, ceea ce poate crea **conflicte** sau **confuzie** în interpretarea acestora în **clasa copil**. Astfel, devine esențial ca **moștenirea multiplă** să fie utilizată doar atunci când **clasele părinte** sunt **bine definite**, **fără** suprapuneri de responsabilități sau funcționalități, pentru a **evita** situațiile de ambiguitate și a păstra codul ușor de întreținut și de extins.</note> | <note important>În general, găsirea unei combinații potrivite de clase care să respecte **moștenirea multiplă** poate fi o provocare, deoarece aceasta poate duce la situații **complexe** și **ambigue**. **Moștenirea multiplă** poate să genereze probleme atunci când două **clase părinte** au **metode** sau **membri comuni**, ceea ce poate crea **conflicte** sau **confuzie** în interpretarea acestora în **clasa copil**. Astfel, devine esențial ca **moștenirea multiplă** să fie utilizată doar atunci când **clasele părinte** sunt **bine definite**, **fără** suprapuneri de responsabilități sau funcționalități, pentru a **evita** situațiile de ambiguitate și a păstra codul ușor de întreținut și de extins.</note> | ||
| - | Pentru acest laborator propunem ca și clase părinte **ProdusComercial** și respectiv **PiesaElectronica**, iar ca și clasă copil **CameraWeb**. Dacă am menționat **moștenire** acest lucru este echivalent cu relația de **"is-a"** ceea ce înseamnă că **orice cameră web** este un **produs comercial** și în același timp **orice cameră web** este o **piesă electronică**. | + | **Moștenirea** poate fi vizualizată ca o structură arborescentă, ceea ce explică de ce organizarea claselor într-un astfel de sistem este denumită **ierarhie de clase**. Într-o **ierarhie**, fiecare **clasă derivată** își are rădăcinile în **clasele părinte**, iar această organizare permite construirea unei structuri **logice** și **ordonate** a relațiilor dintre clase. De exemplu, în C++, putem observa în imaginea de mai jos un **arbore de fluxuri (ierarhia claselor de fluxuri)** în care clasele specifice de intrare și ieșire (precum **''ifstream''**, **''ofstream''**, **''stringstream''**) sunt derivate din clase generale precum **''istream''**, **''ostream''** sau **''iostream''**. Această structură arborescentă oferă atât claritate conceptuală, cât și flexibilitate în reutilizarea și extinderea funcționalităților claselor. |
| + | |||
| + | {{ :poo-is-ab:laboratoare:arbore_fluxuri.jpg?400 |}} | ||
| + | |||
| + | Pentru acest laborator propunem ca și clase părinte **ProdusComercial** și respectiv **PiesaElectronica**, iar ca și clasă copil **CameraWeb**. Dacă am menționat **moștenire** acest lucru este echivalent cu relația de **"is-a"** ceea ce înseamnă că **orice cameră web** este un **produs comercial** și în același timp **orice cameră web** este și o **piesă electronică**. | ||
| Declarația clasei **ProdusComercial** se poate observa în blocul de cod mai jos. | Declarația clasei **ProdusComercial** se poate observa în blocul de cod mai jos. | ||
| Line 75: | Line 79: | ||
| #include "PiesaElectronica.h" | #include "PiesaElectronica.h" | ||
| - | class CameraWeb : public ProdusComercial, public PiesaElectronica // CameraWeb mosteneste atat ProdusComercial cat si PiesaElectronica | + | class CameraWeb : public ProdusComercial, public PiesaElectronica // CameraWeb mosteneste atat clasa ProdusComercial cat si clasa PiesaElectronica |
| { | { | ||
| int rezolutie; | int rezolutie; | ||
| Line 249: | Line 253: | ||
| ==== Agregare ==== | ==== Agregare ==== | ||
| - | **Agregarea** presupune ca într-o clasă să avem unul sau mai multe **atribute** de tipul **altei clase**. Când spunem **agregare** acest lucru este echivalent cu relația de "has-a" sau "has-many" în funcție de context. | + | **Agregarea** presupune ca într-o clasă să avem unul sau mai multe **atribute** de tipul **altei clase**. Când spunem **agregare** acest lucru este echivalent cu relația de **"has-a"** sau **"has-many"** în funcție de context. |
| <note>Agregarea este de două tipuri după cum urmează: | <note>Agregarea este de două tipuri după cum urmează: | ||
| Line 258: | Line 262: | ||
| </note> | </note> | ||
| - | Ca și exemplu didactic vom crea o clasă nouă denumită **Laptop** care va conține un atribut de tip **CameraWeb** punând astfel în evidență relația de **"has-a"** dintre două clase. Acestă agregare este de tip **weak**, deoarece un laptop poate să nu aibă cameră web. | + | Ca și exemplu didactic vom crea o clasă nouă denumită **Laptop** care va conține un atribut de tip **CameraWeb** punând astfel în evidență relația de tip **"has-a"** dintre două clase. Acestă **agregare** este de tip **weak**, deoarece un laptop poate să nu fie dotat cu o cameră web. |
| <code cpp> | <code cpp> | ||
| Line 332: | Line 336: | ||
| </code> | </code> | ||
| - | Iar implementarea funcțiilor din cadrul namespace-ului se poate observa mai jos. | + | Iar implementările funcțiilor din cadrul namespace-ului se pot observa mai jos. |
| <code cpp> | <code cpp> | ||
| Line 363: | Line 367: | ||
| </code> | </code> | ||
| - | Testarea acestui namespace este facută în **funcția main** după cum urmează în codul de mai jos. | + | Testarea acestui **namespace** este facută în **funcția main** după cum urmează în codul de mai jos. |
| <code cpp> | <code cpp> | ||
| Line 390: | Line 394: | ||
| - | Am înțeles cum putem defini clase derivate care extind mai multe clase de bază, oferind posibilitatea reutilizării codului din mai multe surse și creând ierarhii complexe, dar flexibile. Am discutat despre avantajele și riscurile moștenirii multiple, precum posibilele conflicte de nume și gestionarea lor prin tehnici specifice, cum ar fi operatorii din clasele părinte și apelul lor explicit pentru a evita conflictele. | + | Am înțeles cum putem defini **clase derivate** care **extind mai multe clase de bază**, oferind posibilitatea reutilizării codului din mai multe surse și creând **ierarhii complexe**, dar flexibile. Am discutat despre avantajele și riscurile **moștenirii multiple**, precum posibilele conflicte de nume și gestionarea lor prin tehnici specifice, cum ar fi operatorii din **clasele părinte** și apelul lor **explicit** pentru a evita conflictele. |
| - | Relația de **"has-a"** ne-a permis să creăm structuri de tip container, unde o clasă conține una sau mai multe instanțe ale altei clase fără a se afla într-o ierarhie de moștenire. Astfel, am putut organiza eficient datele și responsabilitățile între clase, menținând o separare clară a rolurilor. | + | Relația de **"has-a"** ne-a permis să definim structuri de tip **container**, unde o clasă conține **una sau mai multe** instanțe ale altei clase **fără** a se afla într-o ierarhie de clase. Astfel, am putut organiza eficient datele și responsabilitățile între clase, menținând o separare clară a rolurilor. |
| Am văzut cum **namespace-urile** pot ajuta la **evitarea conflictelor de nume** și ne oferă control asupra **identificării funcțiilor și variabilelor specifice** din cadrul unui anumit context. Namespace-urile sunt o soluție eficientă pentru organizarea codului, mai ales când avem funcții și clase cu nume **identice ca și denumiri** în proiecte mari. | Am văzut cum **namespace-urile** pot ajuta la **evitarea conflictelor de nume** și ne oferă control asupra **identificării funcțiilor și variabilelor specifice** din cadrul unui anumit context. Namespace-urile sunt o soluție eficientă pentru organizarea codului, mai ales când avem funcții și clase cu nume **identice ca și denumiri** în proiecte mari. | ||
| - | Am observat că funcțiile friend **nu** sunt moștenite în mod implicit în clasele derivate, fiind necesar să le **apelăm explicit** pentru fiecare **clasă părinte** atunci când le folosim. Acest lucru ne permite să menținem controlul asupra accesului la datele **private** între clase, **fără** a extinde accesul la întreaga ierarhie. | + | Am observat că funcțiile friend **nu** sunt moștenite în mod implicit în **clasele derivate**, fiind necesar să le **apelăm explicit** pentru fiecare **clasă părinte** atunci când le folosim. Acest lucru ne permite să menținem controlul asupra accesului la datele **private** între clase, **fără** a extinde accesul la **întreaga ierarhie**. |
| - | Aceste concepte fundamentale de moștenire multiplă, agregare și gestionare a spațiului de nume ne oferă instrumente puternice pentru a structura și organiza codul eficient. Aceste tehnici vor fi extrem de utile în viitoarele proiecte, facilitând modularea codului și scalarea aplicațiilor, reducând în același timp redundanța. | + | Aceste concepte fundamentale de moștenire multiplă, agregare și gestionare a spațiului de nume ne oferă instrumente puternice pentru a structura și organiza codul eficient. Aceste tehnici vor fi extrem de utile în viitoarele proiecte, facilitând modularizarea codului și scalarea aplicațiilor, reducând în același timp redundanța. |
