Autor: Răzvan Cristea

Studentul va fi capabil la finalul acestui laborator să:

• înțeleagă conceptul de diamond problem și implicațiile sale în ierarhiile de clase
• utilizeze derivarea virtuală pentru a rezolva în mod eficient problema rombului
• identifice situațiile în care problema rombului poate apărea și să o gestioneze corect
• înțeleagă importanța și modul de utilizare a suprascrierii în contextul rezolvării problemei rombului
• recunoască impactul moștenirii multiple asupra designului orientat pe obiecte și să aplice bune practici pentru a minimiza complexitatea codului

Problema rombului, cunoscută și sub numele de diamond problem sau diamond of death, apare în limbajele de programare care permit moștenirea multiplă, cum este cazul limbajului C++. Aceasta se referă la ambiguitățile care pot apărea atunci când o clasă derivată moștenește aceeași clasă de bază prin cel puțin două căi diferite din ierarhia de moștenire. Rezultatul este un conflict între membri, metode sau alte atribute ale clasei de bază, deoarece compilatorul nu poate decide în mod automat ce instanță sau metodă să utilizeze.

Diamond problem apare atunci când o clasă derivată moștenește cel puțin două clase intermediare, iar aceste clase intermediare moștenesc la rândul lor aceeași clasă de bază. Grafic, ierarhia de moștenire formează o structură asemănătoare unui romb sau diamant. Pentru a putea înțelege mai bine cum arată diamond problem vom ilustra mai jos cazul cel mai simplu cu 4 clase.

Așa cum se poate observa și în imaginea de mai sus clasa D are două copii ale clasei A, ceea ce duce la ambiguități și inconsistențe. De exemplu, dacă încercăm să accesăm un membru al clasei A din clasa D, compilatorul nu poate determina care este drumul corect, deoarece atât calea D-B-A cât și calea D-C-A duc spre clasa A.

În limbajele C# și Java, moștenirea multiplă a claselor nu este permisă tocmai pentru a evita astfel de probleme. În schimb, aceste limbaje oferă mecanisme alternative, precum interfețele, care permit implementarea a numeroase comportamente fără a introduce conflicte legate de ambiguitatea moștenirii.

Interfețele funcționează ca un contract pentru clasele derivate, oferind flexibilitate similară moștenirii multiple, dar fără a introduce ambiguitățile asociate cu problema rombului. Această alegere de design reflectă o abordare mai simplificată și mai sigură pentru a evita complicațiile întâlnite în limbaje care permit moștenirea multiplă (C++, Python).

În continuare vom vedea cum vom putea soluționa diamond problem în C++ astfel încât programul scris de noi să aibă comportamentul dorit.

Pentru a putea gestiona și rezolva corect această problemă trebuie să aplicăm doi pași si anume: derivarea virtuala a claselor intermediare din clasa de baza și respectiv apelarea constructorilor clasei de bază în lista de inițializare a constructorilor clasei nepot. Pentru a vedea dacă aplicația se comportă în conformitate cu așteptările pe care le avem va trebui să o testăm constant pentru a vedea dacă am eliminat toate ambiguitățile generate de problema rombului.

Să luăm ca exemplu clasele A, B, C, D, unde A este clasa de bază iar B și C moștenesc clasa A. Clasa D moștenește atât clasa B cât și clasa C. Pentru fiecare clasă vom pune la dispoziție constructorul fără parametri și respectiv destructorul.

class A
{
public:
 
    A() 
    {
        std::cout << "Constructor A\n";
    }
 
    ~A() 
    {
        std::cout << "Destructor A\n";
    }
};
 
class B : public A 
{
public:
 
    B() : A()
    {
        std::cout << "Constructor B\n";
    }
 
    ~B() 
    {
        std::cout << "Destructor B\n";
    }
};
 
class C : public A 
{
public:
 
    C() : A()
    {
        std::cout << "Constructor C\n";
    }
 
    ~C() 
    {
        std::cout << "Destructor C\n";
    }
};
 
class D : public B, public C 
{
public:
 
    D() : B(), C()
    {
        std::cout << "Constructor D\n";
    }
 
    ~D() 
    {
        std::cout << "Destructor D\n";
    }
};

Dacă vom inițializa în funcția main un obiect de tipul clasei D vom observa că se va apela de două ori constructorul clasei A iar destructorul clasei A se va apela tot de două ori atunci când durata de viață a obiectului se va încheia.

#include <iostream>
 
int main() 
{
    D obj;
 
    std::cout << '\n';
 
    return 0;
}

Iar output-ul arată ca mai jos.

Constructor A
Constructor B
Constructor A
Constructor C
Constructor D

Destructor D
Destructor C
Destructor A
Destructor B
Destructor A

Rezolvarea acestei probleme este derivarea virtuală a claselor intermediare B și respectiv C după cum urmează.

class A
{
public:
 
	A()
	{
		std::cout << "Constructor A\n";
	}
 
	~A()
	{
		std::cout << "Destructor A\n";
	}
};
 
class B : virtual public A
{
public:
 
	B() : A()
	{
		std::cout << "Constructor B\n";
	}
 
	~B()
	{
		std::cout << "Destructor B\n";
	}
};
 
class C : virtual public A
{
public:
 
	C() : A()
	{
		std::cout << "Constructor C\n";
	}
 
	~C()
	{
		std::cout << "Destructor C\n";
	}
};
 
class D : public B, public C
{
public:
 
	D() : A(), B(), C()
	{
		std::cout << "Constructor D\n";
	}
 
	~D()
	{
		std::cout << "Destructor D\n";
	}
};

Iar dacă vom testa în funcția main această ierarhie de clase vom obține rezultatul dorit.

#include <iostream>
 
int main()
{
	D obj;
 
	std::cout << '\n';
 
	return 0;
}

Iar output-ul va arăta ca mai jos.

Constructor A
Constructor B
Constructor C
Constructor D

Destructor D
Destructor C
Destructor B
Destructor A

Așa cum am învățat în cadrul laboratoarelor anterioare pot exista situații în care vrem să oferim comportamente diferite metodelor în fiecare clasă. Prin urmare avem nevoie ca suprascrierea să fie prezentă în codul pe care îl scriem. Să urmărim exemplu de cod de mai jos.

#include <iostream>
 
int main()
{
	A* obj = new D();
 
	std::cout << '\n';
	delete obj;
 
	return 0;
}

Output-ul nu este cel la care ne-am aștepta după cum putem vedea mai jos.

Constructor A
Constructor B
Constructor C
Constructor D

Destructor A

Deși ordinea apelării constructorilor este cea firească în cazul destructorilor putem observa că aceștia nu se apelează în ordinea inversă constructorilor, ceea ce înseamnă că la dezalocarea memoriei pentru pointerul obj nu se produce o legătură întârziată (late binding).

Soluția este să marcăm destructorul clasei A ca fiind virtual, astfel tabela virtuală de pointeri va fi moștenită de clasele B, C și respectiv D.

class A
{
public:
 
	A()
	{
		std::cout << "Constructor A\n";
	}
 
	virtual ~A()
	{
		std::cout << "Destructor A\n";
	}
};

Iar acum dacă rulăm din nou codul din funcția main output-ul va fi cel dorit.

Constructor A
Constructor B
Constructor C
Constructor D

Destructor D
Destructor C
Destructor B
Destructor A

Este important să înțelegem că problema rombului nu reprezintă neapărat un concept negativ, ci mai degrabă o provocare specifică moștenirii multiple. Când apare, este esențial să o gestionăm cu atenție, pentru a evita ambiguitățile sau comportamentele nedefinite în timpul execuției programului. O gestionare corectă a acestei situații asigură un cod robust, clar și lipsit de erori critice, cum ar fi memory leaks sau conflicte în ordinea apelurilor constructorilor și respectiv destructorilor.

Problema rombului evidențiază complexitatea moștenirii multiple și potențialele capcane care pot apărea în proiectarea claselor într-un limbaj precum C++. Deși moștenirea multiplă oferă flexibilitate și permite reutilizarea codului, aceasta vine cu riscuri, cum ar fi ambiguitatea generată de apelurile multiple ale constructorilor sau destructorului clasei de bază. Soluția derivării virtuale este un mecanism eficient pentru a preveni aceste ambiguități, oferind o modalitate clară de a gestiona relațiile dintre clase. Totuși, utilizarea derivării virtuale necesită o înțelegere profundă a modului în care funcționează apelurile constructorilor și cum să definim explicit ordinea acestora.

Diamond problem nu este ceva rău în sine, ci o oportunitate de a învăța să scriem un cod bine structurat și de a ne baza pe mecanismele oferite de limbajul de programare utilizat pentru a rezolva ambiguitățile. Printr-o planificare atentă a ierarhiilor de clase și aplicarea corectă a derivării virtuale, putem evita erori critice, precum memory leaks sau comportamente imprevizibile. De asemenea, această problemă subliniază importanța testării riguroase și a înțelegerii detaliate a relațiilor dintre clase în programele complexe.