다중 상속에서 다이아몬드 문제란 무엇인가요?

Question

Accepted Answer

**다이아몬드 문제(diamond problem)**는 class가 공통 조상을 공유하는 두 class를 상속할 때 발생하여 모호성을 만듭니다: 두 중간 class가 모두 메서드를 override한다면(또는 필드를 가진다면), 맨 아래 class는 어느 버전을 얻을까요?

## 다이아몬드

```text
        A  (greet() 정의)
       / \
      B   C   (각각 greet() 를 override 할 수 있음)
       \ /
        D   ← B 와 C 로부터 상속: 어느 greet()?
```

## Python에서 (다중 상속 허용)

```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):                  # 다중 상속
    pass

print(D().greet())             # "B"  — MRO 로 해결됨, 모호하지 않음
print(D.__mro__)               # D → B → C → A → object  (C3 선형화)
```

Python은 C3 선형화를 사용하는 **메서드 결정 순서(Method Resolution Order, MRO)**를 통해 결정론적으로 해결하며, `super()`가 그 순서와 협력합니다.

## 언어별 처리 방식

| 언어 | 접근 방식 |
|---|---|
| C++ | 허용; 한정하지 않으면 모호성이 컴파일 오류, 또는 하나의 기반을 공유하기 위해 `virtual` 상속 사용 |
| Java/C# | 다중 class 상속을 **금지**; 다중 *interface*는 허용 (상태 없음, 따라서 데이터 다이아몬드 없음) |
| Python | 허용; MRO(C3)로 해결 |
| Scala | 정의된 선형화 순서를 가진 **trait** |

## 함정

MRO가 있어도 *상태*의 다중 상속은 금세 혼란스러워집니다 — 중복된 기반 초기화, 놀라운 `super()` 체인 말입니다. Interface/trait(상태가 아닌 동작)는 대부분의 고통을 피해 갑니다.

## 왜 중요한가

이는 주요 언어 설계 분기를 설명합니다: Java와 C#은 이 모호성을 피하기 위해 다중 class 상속을 금지하고 대신 interface를 제공했습니다.

MRO를 이해하는 것은 Python에서 실용적입니다: 협력적 `super()`와 믹스인 순서는 다이아몬드가 어떻게 선형화되는지 봐야만 이해됩니다.

언어	접근 방식
C++	허용; 한정하지 않으면 모호성이 컴파일 오류, 또는 하나의 기반을 공유하기 위해 `virtual` 상속 사용
Java/C#	다중 class 상속을 금지; 다중 interface는 허용 (상태 없음, 따라서 데이터 다이아몬드 없음)
Python	허용; MRO(C3)로 해결
Scala	정의된 선형화 순서를 가진 trait