Day 10: Implicit Interfaces, Runtime Internals & Dynamic Dispatch

Section 0: The "Why" & Core Vocabulary

ในฐานะวิศวกรที่ย้ายมาจาก Kotlin / Spring Boot เราคุ้นเคยกับ Nominal Subtyping: หากเรามี Interface PaymentProcessor เราต้องประกาศ class SwiftProcessor : PaymentProcessor หากไม่ได้เขียนชื่อสัญญานี้อย่างชัดเจน แม้คลาสจะมีฟังก์ชัน process(tx: Transaction) เหมือนกันทุกประการ JVM ก็จะไม่ยอมให้ใช้งานข้ามกัน

Go พลิกวิธีคิดทั้งหมดด้วย Structural Typing (Duck Typing ในระดับ Compile-Time): "If it walks like a duck and quacks like a duck, it's a duck." ผู้สร้าง Struct ไม่จำเป็นต้องรู้ว่าในอนาคต Struct ของตนจะถูกนำไปใช้ใน Interface อะไร ส่วนผู้บริโภค (Consumer) จะเป็นผู้ประกาศ Interface ขนาดจิ๋ว (1-2 เมธอด) ณ จุดที่ต้องการใช้งานเอง (Consumer-driven Interfaces)

Section 1: Go Syntax & Command Blueprint

การนิยาม Interface ใน Go ใช้คีย์เวิร์ด type [ชื่อ] interface โดยระบุเฉพาะ Method Signatures (ชื่อ, พารามิเตอร์, ค่าที่คืน) เท่านั้น:

1.1 พื้นฐานการประกาศ Interface และ Implicit Satisfaction

package main

import "fmt"

// 1. ประกาศ Interface ขนาดเล็ก (แนะนำ 1-2 เมธอดตามปรัชญา Go)
type PaymentGateway interface {
    Authorize(amount int64) (string, error)
}

// 2. ประกาศ Concrete Struct ธรรมดา (สังเกต: ไม่มีการอ้างอิงถึง PaymentGateway เลย!)
type PromptPayService struct {
    MerchantID string
}

// 3. ผูก Method เข้ากับ Struct
// ทันทีที่บรรทัดนี้ถูกเขียน PromptPayService จะกลายเป็น PaymentGateway โดยอัตโนมัติ!
func (p *PromptPayService) Authorize(amount int64) (string, error) {
    txID := fmt.Sprintf("PP-%s-%d", p.MerchantID, amount)
    return txID, nil
}

// 4. ฝั่ง Consumer รับ Interface เข้ามาทำงาน
func ExecuteCheckout(gateway PaymentGateway, amount int64) {
    txID, err := gateway.Authorize(amount)
    if err != nil {
        fmt.Println("Payment failed:", err)
        return
    }
    fmt.Println("Payment authorized successfully. TXID:", txID)
}

func main() {
    service := &PromptPayService{MerchantID: "M-10928"}
    // ส่ง service เข้าไปได้ทันทีเพราะ Implement เมธอด Authorize ครบถ้วน
    ExecuteCheckout(service, 45000)
}

1.2 กฎเหล็ก Method Sets: Value Receiver vs Pointer Receiver

นี่คือจุดที่ทำให้วิศวกร JVM สับสนที่สุด: ทำไมบางครั้งคอมไพเลอร์จึงฟ้องว่า Struct ของเราไม่ได้ Implement Interface ทั้งๆ ที่เขียนเมธอดชื่อเดียวกันเป๊ะ?

type RFIDReader interface {
    ResetCounter()
}

type ImpinjGate struct {
    Count int
}

// Implement ด้วย Pointer Receiver เพราะต้องการแก้ไขค่าภายใน Struct
func (g *ImpinjGate) ResetCounter() {
    g.Count = 0
}

func StartRaceGate() {
    // ถูกต้อง: ส่ง Pointer (*ImpinjGate) ซึ่งมี ResetCounter() อยู่ใน Method Set
    var r1 RFIDReader = &ImpinjGate{Count: 10}
    r1.ResetCounter()

    // คอมไพล์พังทันที! (Compile Error)
    // cannot use ImpinjGate{} (value of type ImpinjGate) as RFIDReader value:
    // ImpinjGate does not implement RFIDReader (method ResetCounter has pointer receiver)
    // var r2 RFIDReader = ImpinjGate{Count: 10} 
}

1.3 Type Assertion (Safe vs Unsafe)

เมื่อเราถือตัวแปร Interface แล้วต้องการดึงค่า Concrete Type ดั้งเดิมออกมาใช้งาน เราใช้ไวยากรณ์ i.(ConcreteType):

func InspectGateway(gw PaymentGateway) {
    // 1. Unsafe Assertion: หาก gw ไม่ใช่ *PromptPayService จะเกิด RUNTIME PANIC ทันที!
    // pp := gw.(*PromptPayService) 

    // 2. Safe Assertion (Idiomatic Go): ใช้รูปแบบ Value, Ok Idiom
    if pp, ok := gw.(*PromptPayService); ok {
        // ดึงสำเร็จ! pp มี Type เป็น *PromptPayService เข้าถึงฟิลด์ MerchantID ได้
        fmt.Println("Connected to PromptPay Merchant:", pp.MerchantID)
        return
    }

    fmt.Println("Unknown payment gateway provider")
}

1.4 Type Switch (Polymorphic Branching)

หากต้องการตรวจสอบหลายๆ Type พร้อมกัน ให้ใช้ switch v := i.(type) ซึ่งทำหน้าที่เหมือน pattern matching บน Types:

func RouteTransaction(gw PaymentGateway, amount int64) {
    switch concrete := gw.(type) {
    case *PromptPayService:
        fmt.Println("Routing via Thai QR / PromptPay system:", concrete.MerchantID)
    default:
        fmt.Printf("Generic gateway execution for type: %T\n", concrete)
    }
}

Section 2: Memory Architecture & Full Struct Definitions

ในภาษา Go ค่า Interface ไม่ใช่ Pointer ธรรมดาแบบ void* ใน C หรือ Object Reference บน JVM แต่ Interface ถูกนิยามไว้ใน Go Runtime Source Code (src/runtime/runtime2.go) ออกเป็น 2 ชนิดที่ชัดเจน:

2.1 โครงสร้าง iface (Non-Empty Interface) = 16 ไบต์

ใช้สำหรับ Interface ที่มี Method กำกับ เช่น io.Reader, error, PaymentGateway

// runtime/runtime2.go
type iface struct {
    tab  *itab          // 8 ไบต์: ชี้ไปยัง Interface Table (Type metadata + Method table)
    data unsafe.Pointer // 8 ไบต์: ชี้ไปยัง Concrete Value จริงบน Heap หรือ Memory Block
}

type itab struct {
    inter *interfacetype // 8 ไบต์: นิยามฝั่ง Interface Type (เช่น PaymentGateway)
    _type *_type         // 8 ไบต์: นิยามฝั่ง Concrete Type จริง (เช่น *PromptPayService)
    hash  uint32         // 4 ไบต์: สำเนา Hash ของ _type เพื่อให้ Type Assertion เปรียบเทียบได้เร็วใน O(1)
    _     [4]byte        // 4 ไบต์: Padding เพื่อ Align ให้ครบ 8 ไบต์ Boundary
    fun   [1]uintptr     // ขนาดแปรผัน: Array ของ Function Pointers ชี้ไปยัง Machine Code ของ Methods
}

2.2 โครงสร้าง eface (Empty Interface / any) = 16 ไบต์

ใช้สำหรับ Interface ที่ไม่มี Method ใดๆ (interface{} หรือ any) ไม่จำเป็นต้องมี Method Table (fun) จึงใช้ _type โดยตรง:

// runtime/runtime2.go
type eface struct {
    _type *_type         // 8 ไบต์: ชี้ไปยัง Type Metadata ของค่าที่ใส่เข้ามา
    data  unsafe.Pointer // 8 ไบต์: ชี้ไปยัง Concrete Data Pointer
}

2.3 ASCII Memory Layout: การชี้เป้าของ iface ใน RAM 64-bit

Section 3: Visual Workflow & Assembly/RAM Mechanics

อะไรเกิดขึ้นเมื่อเราแปลง Struct ธรรมดาไปเป็น Interface? ทำไมประสิทธิภาพจึงเปลี่ยนไป? มาเจาะลึกกลไกเบื้องหลังระดับ CPU และ Escape Analysis

3.1 ขั้นตอนการแปลง Struct เข้าสู่ Interface (Interface Boxing)

3.2 กลไกการเรียกเมธอด: Direct Call vs Dynamic itab Dispatch

ลองเปรียบเทียบคำสั่งระดับ Assembly เมื่อเรียกเมธอดตรงๆ เทียบกับการเรียกผ่าน Interface:

// 1. Direct Concrete Call: s.Authorize(100)
// Compiler รู้ตำแหน่งแน่นอนตั้งแต่ต้น (Compile-Time Known Address)
CALL  main.(*PromptPayService).Authorize(SB) // คำสั่งตรงๆ 1 สเต็ป, ทำ Inlining ได้ทันที!

// 2. Dynamic Interface Call: gw.Authorize(100)
MOVQ  0(SP), AX       // โหลด *itab เข้าสู่ CPU Register AX
MOVQ  24(AX), AX      // อ่าน fun[0] (Function Pointer ของ Authorize) จาก itab
MOVQ  8(SP), DX       // โหลด data pointer (Receiver) เข้าสู่ Register DX
CALL  AX              // Indirect Call ข้าม Pointer! (ขัดขวาง Inlining และเสี่ยง Branch Misprediction)

สรุปผลกระทบต่อ Latency ในงาน High-Frequency Banking: การเรียกผ่าน Interface มีต้นทุน Indirect Call เพิ่มขึ้นเล็กน้อย (ราว 1-3 นาโนวินาที) แต่สิ่งที่สร้าง Overhead แท้จริงคือ Escape to Heap ซึ่งสร้างงานให้ Garbage Collector ต้องตามล้างขยะในภายหลัง

Section 4: Edge Cases, Hazards & Idiomatic Patterns

type SecurityAuditor interface {
    Audit()
}

type BankAuditor struct{}
func (b *BankAuditor) Audit() {}

func GetAuditor() SecurityAuditor {
    var auditor *BankAuditor = nil // Concrete pointer มีค่าเป็น nil
    return auditor                 // ส่งกลับเป็น SecurityAuditor (iface)
}

func RunSystemCheck() {
    auditor := GetAuditor()

    // หายนะระดับ Production: เงื่อนไขนี้ได้ผลลัพธ์เป็น FALSE!
    // auditor != nil จะเป็น TRUE เสมอ เพราะ iface.tab มีค่าชี้ไปยัง Metadata ของ *BankAuditor!
    if auditor != nil {
        fmt.Println("Auditor exists, running audit...")
        // หากเมธอด Audit() พยายามเข้าถึงฟิลด์ภายใน จะเกิด NIL POINTER DEREFERENCE PANIC ทันที!
        auditor.Audit() 
    }
}

// วิธีแก้ที่ถูกต้อง:
func GetAuditorSafe() SecurityAuditor {
    // อย่าประกาศ Typed Pointer หากไม่มีค่า ให้คืน nil ตรงๆ!
    return nil // คืน Untyped nil ทำให้ iface.tab = nil และ iface.data = nil
}

// Idiomatic Go Pattern: Guard การันตี Interface ตั้งแต่ขั้นตอน Compile-Time
// หาก PromptPayService ขาดเมธอดของ PaymentGateway บรรทัดนี้จะคอมไพล์ไม่ผ่านทันที!
var _ PaymentGateway = (*PromptPayService)(nil)

Idiomatic Go Interface Principles:

• Accept Interfaces, Return Structs: ฟังก์ชันควรรับพารามิเตอร์เป็น Interface (เพื่อความยืดหยุ่นและการทำ Mock/Unit Test) แต่ควรคืนค่ากลับมาเป็น Concrete Struct เสมอ เพื่อให้ Caller เลือกเองว่าจะนำไปใช้งานต่ออย่างไร
• Keep Interfaces Small (Role Interfaces): Interface ใน Go มักมีขนาดเพียง 1 ถึง 2 เมธอดเท่านั้น เช่น io.Reader, io.Writer, fmt.Stringer หลีกเลี่ยง "Fat Interface" ที่มีมากกว่า 5 เมธอด
• Define Interfaces where used (Consumer-Side): อย่าสร้าง Package รวม Interface เอาไว้ล่วงหน้าเหมือน Spring ให้สร้าง Interface ใน Package ของผู้เรียกใช้งาน (Consumer) เมื่อจำเป็นต้อง Decouple โค้ดจริงๆ เท่านั้น

Section 5: Knowledge Verification Quiz (16 Challenges)

ทดสอบความเข้าใจเชิงลึกระดับ Runtime & Architecture ทุกข้อมีคะแนนสะสมและอธิบายเหตุผลอย่างละเอียด

Section 6: Hands-on Engineering Labs

เขียนโค้ด Go ตามหลัก Idiomatic Architecture ตรวจสอบความถูกต้องด้วย Verification Engine