polymorphism ทำงานอย่างไรเบื้องหลัง (dynamic dispatch)?

Question

Accepted Answer

**Dynamic dispatch** คือกลไกกรรมวิธีสำหรับการตัดสินใจว่า*ใช้การนำเข้าเมธอดใด*ขึ้นอยู่กับ**ประเภทจริง**ของวัตถุ ไม่ใช่ประเภทที่ประกาศไว้ของตัวแปร ภาษาส่วนใหญ่ที่ใช้คลาสนำเข้าสิ่งนี้ด้วย**ตารางเมธอดเสมือน (vtable)**

## โมเดล vtable

แต่ละคลาสมีตารางของตัวชี้ไปยังการนำเข้าเมธอดของมัน วัตถุแต่ละชิ้นถือตัวชี้ที่ซ่อนอยู่ไปยัง vtable ของคลาสของมัน การเรียกเสมือนจริงจะกลายเป็น: *ค้นหาเมธอดในตาราง 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 | เสมือนจริงโดยค่าเริ่มต้น | `final`/`static`/`private` ไม่ใช่เสมือนจริง |
| C++ | ไม่ใช่เสมือนจริงโดยค่าเริ่มต้น | ต้องทำเครื่องหมาย `virtual` สำหรับ dynamic dispatch |
| Python | ไดนามิกเสมอ | การค้นหาเมธอดผ่าน dict/MRO ของวัตถุ |

## ข้อเตือน

มีค่าใช้จ่ายเล็กน้อย (การอ้อม) และมันบล็อกการ inline ใน C++ การลืม `virtual` หมายถึงการเรียกจะผูกเชื่อมแบบสแตติกและการแทนที่จะ*ไม่*ถูกเรียก โดยปิดเงียบ — บัคที่ลึกซึ้ง

## เหตุใดจึงสำคัญ

การทำความเข้าใจ dispatch อธิบาย*เหตุใด*การแทนที่จึงใช้งานได้ และเหตุใดประเภทที่ประกาศจึงไม่ได้กำหนดลักษณะการทำงาน — แหล่งที่มาของความสับสนทั่วไป

นอกจากนี้ยังชี้แจงผลลัพธ์ที่แท้จริง: ต้นทุนประสิทธิภาพของการเรียกเสมือน เหตุใดตัวสร้างจึงไม่ควรเรียกเมธอดเสมือน และเหตุใด C++ ต้องการ `virtual` อย่างชัดแจ้ง

ภาษา	ค่าเริ่มต้น	บันทึก
Java	เสมือนจริงโดยค่าเริ่มต้น	`final`/`static`/`private` ไม่ใช่เสมือนจริง
C++	ไม่ใช่เสมือนจริงโดยค่าเริ่มต้น	ต้องทำเครื่องหมาย `virtual` สำหรับ dynamic dispatch
Python	ไดนามิกเสมอ	การค้นหาเมธอดผ่าน dict/MRO ของวัตถุ