كيف يعمل تعدد الأشكال تحت السطح (التوزيع الديناميكي)؟

Question

Accepted Answer

**التوزيع الديناميكي** هو آلية وقت التشغيل التي تحدد *أي* تطبيق method يتم تشغيله بناءً على **النوع الفعلي** للكائن وليس النوع المصرح به للمتغير. معظم اللغات القائمة على الفئات تطبقه باستخدام **جدول الطرق الافتراضي (vtable)**.

## نموذج vtable

كل فئة لديها جدول من المؤشرات إلى تطبيقات طرقها. كل كائن يحتفظ بمؤشر مخفي إلى vtable الخاص بفئته. يصبح استدعاء virtual: *البحث عن الطريقة في vtable الخاص بالكائن، ثم الانتقال إلى هناك.*

```text
Animal a = new Dog();
a.speak();

a ──▶ Dog object ──▶ [Dog vtable]
                         speak() ──▶ Dog.speak()   ← chosen at RUNTIME
```

المصرف لا يقوم بتشفير `Animal.speak` بشكل مباشر؛ فهو ينبعث "استدعاء الفتحة N من أي vtable يشير إليه هذا الكائن."

## لماذا النوع المصرح به غير كافٍ

```java
Animal a = new Dog();     // declared Animal, actual Dog
a.speak();                // → Dog.speak(), because dispatch uses the OBJECT
```

## الفروقات بين اللغات

| اللغة | الافتراضي | الملاحظات |
|---|---|---|
| Java | Virtual بشكل افتراضي | `final`/`static`/`private` غير virtual |
| C++ | Non-virtual بشكل افتراضي | يجب تحديد `virtual` للتوزيع الديناميكي |
| Python | ديناميكي دائماً | البحث عن الطريقة عبر dict/MRO الخاص بالكائن |

## المزلة

هناك تكلفة صغيرة (indirection) وقد تحجب التحسينات البرمجية. في C++، نسيان `virtual` يعني أن الاستدعاءات تُربط بشكل ثابت والتجاوزات **لا** تُستدعى بصمت — وهي حشرة دقيقة.

## لماذا يهم

فهم التوزيع يشرح *لماذا* يعمل التجاوز ولماذا النوع المصرح به لا يحدد السلوك — وهي مصدر شائع للالتباس.

كما أنه يوضح العواقب الحقيقية: تكلفة الأداء لاستدعاءات virtual، لماذا يجب ألا يستدعي constructors الطرق virtual، ولماذا C++ يتطلب `virtual` بشكل صريح.

اللغة	الافتراضي	الملاحظات
Java	Virtual بشكل افتراضي	`final`/`static`/`private` غير virtual
C++	Non-virtual بشكل افتراضي	يجب تحديد `virtual` للتوزيع الديناميكي
Python	ديناميكي دائماً	البحث عن الطريقة عبر dict/MRO الخاص بالكائن