Interface: สัญญาที่ไม่ต้องเซ็นชื่อ

1 · interface คือรายชื่อ method เฉย ๆ

type Notifier interface {
    Notify(message string) error
}

อ่านว่า: "อะไรก็ตามที่มี method ชื่อ Notify รับ string คืน error — ถือว่าเป็น Notifier" ไม่มีการบอกว่าข้างในทำงานยังไง มีแค่รูปร่างของ method

ต่างจากภาษาอื่นตรงไหน

class EmailNotifier
    implements Notifier {
    // ...
}

type EmailNotifier struct{}

func (EmailNotifier) Notify(
    message string,
) error {
    return nil
}

ฝั่ง Go ไม่มีคำว่า Notifier โผล่มาเลยสักที่ แต่ EmailNotifier ก็เป็น Notifier เรียบร้อยแล้ว เรื่องนี้เรียกว่า structural typing หรือชื่อเล่นที่ติดปากกว่าคือ…

2 · Duck Typing

"If it walks like a duck and it quacks like a duck, then it must be a duck"

type DuckLike interface {
    Walk()
    Quack()
}

type RealDuck struct{}
func (RealDuck) Walk()  { fmt.Println("Duck is walking") }
func (RealDuck) Quack() { fmt.Println("Quack!") }

type ToyDuck struct{}
func (ToyDuck) Walk()  { fmt.Println("Toy duck moves forward") }
func (ToyDuck) Quack() { fmt.Println("Electronic quack!") }

func ObserveDuck(d DuckLike) {
    d.Walk()
    d.Quack()
}

ObserveDuck(RealDuck{})   // Duck is walking / Quack!
ObserveDuck(ToyDuck{})    // Toy duck moves forward / Electronic quack!

ObserveDuck ไม่รู้จัก ToyDuck เลย และ ToyDuck ก็ไม่เคยประกาศว่าเป็น DuckLike — compiler (ตัวแปลโค้ดของเราให้เป็นโปรแกรมที่เครื่องรันได้) จับคู่ให้เองตอนที่คุณส่งเข้าไป

3 · ทำไมต้องมี — ปัญหาของโค้ดที่ผูกติดตายตัว

// สมมติ Checkout Service ผูกกับ Paypal โดยตรง
type CheckoutService struct {
    paypal PaypalGateway
}

func (s CheckoutService) Checkout(amount int64) error {
    return s.paypal.Charge(amount)
}

โค้ดนี้ทำงานได้ แต่พังทันทีเมื่อ:

• บริษัทเปลี่ยนไปใช้ GooglePay → ต้องแก้ทั้ง business logic (โค้ดส่วนที่เป็นขั้นตอนทางธุรกิจจริง ๆ เช่น ขั้นตอนตอนลูกค้ากดสั่งซื้อ)
• อยากเขียน test → ต้องยิงเงินจริงเข้า PayPal
• อยากรองรับสองเจ้าพร้อมกัน → ต้อง copy โค้ดทั้งก้อน

เขียนใหม่ด้วย interface

// เริ่มจากกำหนด Contract กลาง:
type PaymentGateway interface {
    Pay(amount int64) error
}

// Checkout Service สนใจแค่ว่า "จ่ายเงินได้" ไม่สนว่าเจ้าไหน
type CheckoutService struct {
    gateway PaymentGateway
}

func NewCheckoutService(gateway PaymentGateway) *CheckoutService {
    return &CheckoutService{gateway: gateway}
}

func (s *CheckoutService) Checkout(amount int64) error {
    return s.gateway.Pay(amount)
}

// Implementation แต่ละเจ้า อยู่คนละไฟล์ก็ได้:
type PaypalGateway struct{}
func (PaypalGateway) Pay(amount int64) error {
    fmt.Printf("Paid %d satang via Paypal\n", amount)
    return nil
}

type GooglePayGateway struct{}
func (GooglePayGateway) Pay(amount int64) error {
    fmt.Printf("Paid %d satang via GPay\n", amount)
    return nil
}

// สลับเจ้าได้ที่จุดเดียว — business logic ไม่ต้องแก้เลย
service := NewCheckoutService(PaypalGateway{})
service = NewCheckoutService(GooglePayGateway{})

4 · กฎที่ทำให้ interface ไม่พัง: เล็กเข้าไว้

อย่าสร้าง interface ตามทุกสิ่งที่ type ทำได้ ให้สร้างตามสิ่งที่ผู้เรียกจำเป็นต้องใช้

type UserService interface {
    CreateUser()
    UpdateUser()
    DeleteUser()
    FindUser()
    Login()
    Logout()
    ResetPassword()
    SendEmail()
    ExportReport()
    GenerateInvoice()
}

type UserFinder interface {
    FindUser(id string) (User, error)
}

type UserCreator interface {
    CreateUser(user User) error
}

type Authenticator interface {
    Login(username, password string) error
}

ปัญหาของก้อนใหญ่: ฟังก์ชันที่แค่อยากอ่านข้อมูล user ต้องรับ interface ที่มี DeleteUser() ติดมาด้วย เขียน fake สำหรับ test ทีต้อง implement 10 method ทั้งที่ใช้จริงอันเดียว และผู้อ่านโค้ดก็เดาไม่ออกว่าฟังก์ชันนี้จะไปทำอะไรกับ user บ้าง

5 · กับดักใหญ่: pointer receiver กับ interface

type Notifier interface {
    Notify(message string) error
}

type EmailNotifier struct{}

// สังเกต: pointer receiver
func (e *EmailNotifier) Notify(message string) error {
    return nil
}

var n Notifier = EmailNotifier{}

cannot use EmailNotifier{} (value of struct type EmailNotifier)
    as Notifier value in variable declaration:
    EmailNotifier does not implement Notifier
    (method Notify has pointer receiver)

6 · ทดสอบความจำ

7 · ลงมือทำ

อ่านต่อจากต้นทาง

แหล่งหลักที่แนะนำ: A Tour of Go — Interfaces ถึงหน้า 14 — กดรันแก้โค้ดได้ในเว็บเลย ประมาณ 15 นาทีจบ พอเข้าใจแล้วค่อยอ่าน Go Code Review Comments — Interfaces ซึ่งบอกกฎที่ reviewer จริง ๆ ใช้ ข้อที่สำคัญที่สุดสรุปได้ว่า ให้ประกาศ interface ไว้ใน package ของฝั่งที่ใช้ ไม่ใช่ฝั่งที่ implement — ตรงข้ามกับสัญชาตญาณของคนมาจากภาษา OOP แต่มันคือสิ่งที่ทำให้ผู้ใช้กำหนดได้เองว่าต้องการ method อะไรบ้าง

อ้างอิง

• A Tour of Go — Interfaces — แบบฝึกหัดรันได้ในเบราว์เซอร์
• Go spec — Interface types — นิยามและกฎ method set
• Go spec — Method sets — ที่มาของกฎ pointer receiver
• Go Code Review Comments — Interfaces — interface ควรอยู่ package ไหน
• Effective Go — Interfaces and methods