Day 9: Struct Embedding, Composition & Polymorphism

Section 0: The "Why" & Core Vocabulary

ในฐานะวิศวกรที่ย้ายมาจาก Kotlin / Spring Boot เราคุ้นเคยกับโมเดล Object-Oriented Programming แบบดั้งเดิม: การสร้างคลาสฐาน (Base Class) แล้วสืบทอดด้วยคีย์เวิร์ด extends หรือ open class พร้อมอาศัยการ Overwrite เมธอดแบบ Polymorphic Dynamic Dispatch

Go ตัด Class Inheritance ทิ้งทั้งหมด ไม่มีคำว่า extends, implements หรือ super ภาษา Go ใช้หลักการ "Composition over Inheritance" อย่างหมดจดผ่านกลไก Struct Embedding (Anonymous Fields) ซึ่งเป็นการรวม Struct หนึ่งไว้ในอีก Struct หนึ่งโดยตรง พร้อมสนับสนุน Field/Method Promotion ในระดับคอมไพเลอร์

Section 1: Go Syntax & Command Blueprint

การประกอบร่าง Struct ใน Go ไม่ต้องใช้คีย์เวิร์ดพิเศษใดๆ เพียงแค่ประกาศชื่อ Type ภายใน Struct โดยไม่ต้องตั้งชื่อตัวแปรฟิลด์ (Anonymous Field):

1.1 พื้นฐาน Struct Embedding และ Field Promotion

package main

import "fmt"

// Base Entity สำหรับระบบบัญชี Ledger
type BaseEntity struct {
    ID        string
    CreatedAt int64
}

// PaymentTransaction ทำการ "Embed" BaseEntity เข้ามาตรงๆ
type PaymentTransaction struct {
    BaseEntity      // Anonymous Field (Embedding)
    Amount          int64
    DestinationIBAN string
}

func main() {
    // กำหนดค่าแบบ Struct Literal ต้องระบุชื่อ Embedded Type
    tx := PaymentTransaction{
        BaseEntity: BaseEntity{
            ID:        "TX-8839102",
            CreatedAt: 1711920000,
        },
        Amount:          500000, // 5,000.00 บาท (เซนต์/สตางค์)
        DestinationIBAN: "DE89370400440532013000",
    }

    // 1. Field Promotion: เรียกตรงๆ ได้เลยเสมือนเป็นฟิลด์ของตัวเอง
    fmt.Println("Transaction ID:", tx.ID) 
    
    // 2. Explicit Access: เรียกผ่านชื่อ Type ข้างในได้เช่นกัน (ผลลัพธ์เหมือนกัน)
    fmt.Println("Explicit ID:", tx.BaseEntity.ID)
}

1.2 Method Promotion & Shadowing (การบังตา ไม่ใช่การ Overwrite)

ใน Kotlin เมื่อคุณ override fun audit() โค้ดของ Base Class จะถูกแทนที่ใน vtable แต่ใน Go หาก Outer Struct ประกาศชื่อเมธอดซ้ำ มันจะแค่ Shadow (บัง) เมธอดเดิมเท่านั้น:

// Method บน BaseEntity
func (b *BaseEntity) Audit() string {
    return fmt.Sprintf("Base audit: ID=%s", b.ID)
}

// Method บน PaymentTransaction ที่มีชื่อเดียวกัน (Shadowing)
func (p *PaymentTransaction) Audit() string {
    return fmt.Sprintf("Payment audit: ID=%s, Amount=%d", p.ID, p.Amount)
}

func RunAudit() {
    tx := &PaymentTransaction{
        BaseEntity: BaseEntity{ID: "TX-9901"},
        Amount:     2500,
    }

    // เรียก Outer Method ที่บังอยู่
    fmt.Println(tx.Audit()) // "Payment audit: ID=TX-9901, Amount=2500"

    // เมธอดของ Base ไม่ได้หายไปไหน! เรียกผ่าน Inner ได้เสมอ
    fmt.Println(tx.BaseEntity.Audit()) // "Base audit: ID=TX-9901"
}

1.3 Embedding Pointer vs Value

เราสามารถเลือก Embed เป็นแบบ Value หรือ Pointer ก็ได้ ซึ่งให้ผลลัพธ์ในหน่วยความจำต่างกันอย่างสิ้นเชิง:

// 1. Value Embedding: ข้อมูล BaseEntity ฝังตัวเป็นเนื้อเดียวกับ Struct ใน RAM
type IngestBuffer struct {
    BaseEntity // Contiguous memory
    Capacity   int
}

// 2. Pointer Embedding: Struct เก็บแค่ Pointer 8 ไบต์ ชี้ไปยัง Object อื่น
type RaceTracker struct {
    *BaseEntity // 8-byte pointer ชี้ไปหา BaseEntity ที่อื่น
    RunnerBib   int
}

Section 2: Memory Architecture & Full Struct Definitions

เพื่อความเข้าใจระดับ Bare-Metal เราจะผ่า Struct ของระบบจับเวลางานวิ่ง (Race Timing RFID Engine) ว่าในหน่วยความจำระดับ 64-bit Hardware มีการจัดวาง Memory Layout อย่างไรเมื่อเกิดการ Embed

2.1 โครงสร้าง Struct ในระบบ Race Timing

// โครงสร้างข้อมูลพื้นฐานของตัวอ่านสัญญาณ RFID
type ReaderMeta struct {
    GateID    uint32 // 4 Bytes
    AntennaID uint16 // 2 Bytes
    // 2 Bytes Padding เพื่อ Align ให้ครบ 8 Bytes Boundary
}

// การประมวลผลสัญญาณชิปนักวิ่ง
type ChipPassEvent struct {
    ReaderMeta        // Embedded Struct (Value): กินเนื้อที่ 8 Bytes พอดี
    TimestampNano int64 // 8 Bytes
    RunnerBib     int32 // 4 Bytes
    RSSI          int16 // 2 Bytes
    // 2 Bytes Padding ต่อท้ายเพื่อทำให้ผลรวมขนาด Struct หาร 8 ลงตัว
}

2.2 ASCII Memory Layout (Contiguous Memory Allocation)

สังเกตว่า ReaderMeta ไม่ได้ถูกจองเป็น Pointer หรือ Object แยกใน Heap เหมือนใน Java! มันถูกวางแนบสนิทอยู่ภายใน Memory Block เดียวกัน (Zero Pointer Overhead):

2.3 Pointer Embedding Memory Breakdown

หากเราเปลี่ยนเป็น *ReaderMeta (Pointer Embedding) โครงสร้าง RAM จะเปลี่ยนไปทันที:

Section 3: Visual Workflow & Assembly/RAM Mechanics

ทำไมการใช้ Struct Embedding ใน Go จึงเร็วกว่า Polymorphism ใน JVM? มาดูลำดับขั้นตอนการทำงานจริงระดับ Assembly และ CPU Pipeline

3.1 Static Dispatch vs Dynamic vtable Lookup

3.2 Receiver Passing Mechanics

เมื่อเราเรียกเมธอดบน Embedded Struct คอมไพเลอร์ของ Go จะทำการแปลงคำสั่งเสมือนเป็นการเรียกฟังก์ชันธรรมดาที่มีตัวแปรแรกเป็น Parameter:

// เมื่อคุณเขียน:
tx.BaseEntity.Audit()

// หรือเขียนแบบ Promoted:
tx.Audit() // (หากไม่ได้นิยาม Audit() บน tx ไว้)

// คอมไพเลอร์จะเขียนโค้ด Assembly เทียบเท่ากับการเรียก:
BaseEntity.Audit(&tx.BaseEntity)

สังเกตว่า Address ที่ส่งเข้าไปคือ Address ของ tx.BaseEntity โดยตรง ไม่มีการสร้าง Object Wrapper ใหม่ขึ้นมาเลยแม้แต่ไบต์เดียว

Section 4: Edge Cases, Hazards & Idiomatic Patterns

type SourceAccount struct {
    Balance int64
}

type TargetAccount struct {
    Balance int64
}

type InternalTransfer struct {
    SourceAccount
    TargetAccount
}

func Process() {
    transfer := InternalTransfer{}
    // คอมไพล์ไม่ผ่านทันที: ambiguous selector transfer.Balance
    // fmt.Println(transfer.Balance) 

    // วิธีแก้: ต้องระบุ Explicit Qualifier
    fmt.Println(transfer.SourceAccount.Balance)
    fmt.Println(transfer.TargetAccount.Balance)
}

type AuditLogger struct {
    Prefix string
}
func (a *AuditLogger) Log(msg string) { fmt.Println(a.Prefix, msg) }

type SettlementBatch struct {
    *AuditLogger // Embedded Pointer
    BatchID      string
}

func RunBatch() {
    batch := SettlementBatch{BatchID: "B-100"}
    // พังทันที! เพราะ batch.AuditLogger มีค่าเป็น nil
    // batch.Log("Starting...") 
}

Idiomatic Go Patterns: Composition in Production

• Favor Value Embedding over Pointer: แนะนำให้ใช้ Value Embedding เป็นค่าเริ่มต้นเสมอ เพื่อลด Heap Allocations, ลดงานของ Garbage Collector และเพิ่ม L1 Cache Locality
• ห้ามใช้ Embedding เพื่อหวังผลแบบ Class Hierarchy: อย่าพยายามสร้าง Struct ซ้อนกันเกิน 2-3 ชั้นเพื่อเลียนแบบ OOP ใน Go ให้สร้าง Struct เท่าที่จำเป็น และใช้ Interface เล็กๆ 1-2 Methods เพื่อกำหนด Behavior แทน
• Embedded Mutex Pattern: ใน Go เรานิยม Embed sync.Mutex หรือ sync.RWMutex เข้าไปใน Struct เพื่อให้ Struct นั้นมีคุณสมบัติ Thread-Safe (Lock/Unlock) ได้โดยไม่ต้องตั้งชื่อฟิลด์ใหม่:

  type SafeLedger struct {
      sync.Mutex // Promotes Lock() and Unlock()
      balances   map[string]int64
  }
  
  func (l *SafeLedger) Deposit(acc string, amt int64) {
      l.Lock() // เรียกตรงๆ ได้เลย
      defer l.Unlock()
      l.balances[acc] += amt
  }

Section 5: Knowledge Verification Quiz (16 Challenges)

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

Section 6: Hands-on Engineering Labs

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