Qual è il problema del diamante nell'ereditarietà multipla?

Question

Accepted Answer

Il **problema del diamante** sorge quando una classe eredita da due classi che condividono un antenato comune, creando un'ambiguità: se entrambe le classi intermedie sovrascrivono un metodo (o contengono un campo), quale versione ottiene la classe inferiore?

## Il diamante

```text
        A  (defines greet())
       / \
      B   C   (each may override greet())
       \ /
        D   ← inherits from B and C: which greet()?
```

## In Python (che permette l'ereditarietà multipla)

```python
class A:
    def greet(self): return "A"
class B(A):
    def greet(self): return "B"
class C(A):
    def greet(self): return "C"
class D(B, C):                  # multiple inheritance
    pass

print(D().greet())             # "B"  — resolved by MRO, not ambiguous
print(D.__mro__)               # D → B → C → A → object  (C3 linearization)
```

Python lo risolve in modo deterministico tramite il **Method Resolution Order (MRO)** usando la linearizzazione C3, e `super()` coopera con tale ordine.

## Come i linguaggi lo gestiscono

| Linguaggio | Approccio |
|---|---|
| C++ | Lo permette; l'ambiguità è un errore di compilazione a meno che non lo qualifichiate o usiate `virtual` inheritance per condividere una base |
| Java/C# | **Vietano** l'ereditarietà multipla di classi; permettono l'ereditarietà multipla di *interfacce* (nessuno stato, quindi nessun diamante di dati) |
| Python | Lo permette; risolve tramite MRO (C3) |
| Scala | **Traits** con un ordine di linearizzazione definito |

## Insidia

Ancora con un MRO, l'ereditarietà multipla di *stato* diventa confusa rapidamente — inizializzazione della base duplicata, catene `super()` sorprendenti. Interfacce/traits (comportamento, non stato) evitano gran parte dei problemi.

## Perché è importante

Spiega un importante fork nel design dei linguaggi: Java e C# hanno vietato l'ereditarietà multipla di classi specificamente per evitare questa ambiguità, offrendo interfacce invece.

Comprendere l'MRO è pratico in Python: `super()` cooperativo e l'ordine dei mixin hanno senso solo una volta che vedete come il diamante è linearizzato.

Linguaggio	Approccio
C++	Lo permette; l'ambiguità è un errore di compilazione a meno che non lo qualifichiate o usiate `virtual` inheritance per condividere una base
Java/C#	Vietano l'ereditarietà multipla di classi; permettono l'ereditarietà multipla di interfacce (nessuno stato, quindi nessun diamante di dati)
Python	Lo permette; risolve tramite MRO (C3)
Scala	Traits con un ordine di linearizzazione definito