ما هي مشكلة الماس في الوراثة المتعددة؟

Question

Accepted Answer

تنشأ **مشكلة الماس** عندما يرث فئة من فئتين تشتركان في سلف مشترك، مما يخلق غموضًا: إذا كانت كلا الفئتين الوسطيتين تتجاوزان دالة (أو تحتفظان بحقل)، فأي إصدار تحصل عليه الفئة السفلية؟

## شكل الماس

```text
        A  (defines greet())
       / \
      B   C   (each may override greet())
       \ /
        D   ← inherits from B and C: which 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):                  # multiple inheritance
    pass

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

يحل Python المشكلة بشكل حتمي من خلال **ترتيب حل الدوال (MRO)** باستخدام خطية C3، و`super()` يتعاون مع هذا الترتيب.

## كيفية تعامل اللغات معها

| اللغة | النهج |
|---|---|
| C++ | يسمح بها؛ الغموض هو خطأ في وقت الترجمة ما لم تحدد المسار، أو استخدم `virtual` inheritance لمشاركة قاعدة واحدة |
| Java/C# | **تحظر** وراثة الفئات المتعددة؛ تسمح بـ *واجهات* متعددة (لا توجد حالة، لذلك لا توجد ماس من البيانات) |
| Python | تسمح بها؛ تحل عن طريق MRO (C3) |
| Scala | **Traits** مع ترتيب خطي محدد |

## المأزق

حتى مع MRO، الوراثة المتعددة للـ *حالة* تصبح محيرة بسرعة — تهيئة قاعدة مكررة، سلاسل `super()` مفاجئة. الواجهات/الـ traits (السلوك، وليس الحالة) تتجنب معظم الألم.

## لماذا يهم

هذا يشرح انقسام تصميم اللغة الرئيسي: حظرت Java و C# بشكل محدد وراثة الفئات المتعددة لتجنب هذا الغموض، مما يوفر واجهات بدلاً من ذلك.

فهم MRO عملي في Python: يعمل `super()` التعاوني وترتيب mixin فقط بمعنى بعد أن ترى كيف يتم خطية الماس.

اللغة	النهج
C++	يسمح بها؛ الغموض هو خطأ في وقت الترجمة ما لم تحدد المسار، أو استخدم `virtual` inheritance لمشاركة قاعدة واحدة
Java/C#	تحظر وراثة الفئات المتعددة؛ تسمح بـ واجهات متعددة (لا توجد حالة، لذلك لا توجد ماس من البيانات)
Python	تسمح بها؛ تحل عن طريق MRO (C3)
Scala	Traits مع ترتيب خطي محدد