Hvad er diamantproblemet ved multipel arv?

Question

Accepted Answer

**Diamantproblemet** opstår, når en klasse arver fra to klasser, som deler en fælles forfader, hvilket skaber tvetydighed: hvis begge mellemklasser overstyrer en metode (eller indeholder et felt), hvilken version får nederste klasse?

## Diamanten

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

## I Python (som tillader multipel arv)

```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 løser det deterministisk via **Method Resolution Order (MRO)** ved hjælp af C3-linearisering, og `super()` samarbejder med den rækkefølge.

## Hvordan sprog håndterer det

| Sprog | Tilgang |
|---|---|
| C++ | Tillader det; tvetydighed er en kompileringsfejl, medmindre du kvalificerer det, eller bruger `virtual` arv til at dele en base |
| Java/C# | **Forbyder** multipel klassearv; tillader multipel *interfaces* (ingen tilstand, så ingen diamant af data) |
| Python | Tillader det; løser via MRO (C3) |
| Scala | **Traits** med en defineret lineariseringsrækkefølge |

## Fælde

Selvom MRO, multipel arv af *tilstand* bliver forvirrende hurtigt — duplikeret baseinitialiser, overraskende `super()`-kæder. Interfaces/traits (adfærd, ikke tilstand) undgår det meste af problemet.

## Hvorfor det betyder noget

Det forklarer en stor fork i sprogdesign: Java og C# forbød specifikt multipel klassearv netop for at undgå denne tvetydighed, og tilbyder interfaces i stedet.

At forstå MRO er praktisk i Python: samarbejdsvillig `super()` og mixin-rækkefølge giver kun mening, når du først ser, hvordan diamanten lineariseres.

Sprog	Tilgang
C++	Tillader det; tvetydighed er en kompileringsfejl, medmindre du kvalificerer det, eller bruger `virtual` arv til at dele en base
Java/C#	Forbyder multipel klassearv; tillader multipel interfaces (ingen tilstand, så ingen diamant af data)
Python	Tillader det; løser via MRO (C3)
Scala	Traits med en defineret lineariseringsrækkefølge