Replace Subclass with Delegation

จุดประสงค์

Replace Subclass with Delegation ยุบครอบครัวของ subclass ที่ต่างกันตาม แกนของความผันแปรเพียงแกนเดียว ให้เหลือ class เดียวที่ถือ strategy object ไว้ แทนที่จะมี subclass RegularBooking และ PremiumBooking คุณมี Booking เดียวที่ delegate behavior ที่ผันแปรไปยัง PricingPolicy ที่ถูก inject เข้ามา ความผันแปรย้ายจากลำดับชั้นของ type ไปสู่ field ที่คุณตั้งค่าได้ — หรือกระทั่งเปลี่ยนได้ขณะ runtime

Code Smell

การ subclass เป็นการเลือกครั้งเดียวแบบ static: object เป็น PremiumBooking ตลอดไป และถ้า booking เดียวกันผันแปรตามแกนที่ สอง ด้วย — เช่น ราคาวันธรรมดากับวันหยุดสุดสัปดาห์ และ คืนเงินได้กับคืนเงินไม่ได้ — คุณก็จะเผชิญกับการระเบิดเชิงผสมของ subclass เมื่อความแตกต่างระหว่าง subclass แท้จริงเป็นเพียง “อัลกอริทึมตัวไหนทำงานตรงนี้” ความแตกต่างนั้นควรอยู่ใน delegate ไม่ใช่ใน type นี่คือการเคลื่อนไหวคลาสสิกจาก inheritance ไปสู่ pattern Strategy

ก่อน → หลัง

booking ที่ราคาขึ้นกับ tier ก่อนหน้านี้แต่ละ tier เป็น subclass หลังจากนั้น tier เป็น PricingPolicy ที่ Booking เดียว delegate ไปหา

TypeScript

// Before — one subclass per pricing tier
abstract class Booking {
  constructor(protected base: number) {}
  abstract price(): number;
}

class RegularBooking extends Booking {
  price(): number { return this.base; }
}

class PremiumBooking extends Booking {
  price(): number { return this.base * 1.5 + 20; }
}

// After — one Booking that delegates pricing to a strategy
interface PricingPolicy {
  price(base: number): number;
}

class RegularPricing implements PricingPolicy {
  price(base: number): number { return base; }
}

class PremiumPricing implements PricingPolicy {
  price(base: number): number { return base * 1.5 + 20; }
}

class Booking {
  constructor(private base: number, private pricer: PricingPolicy) {}
  price(): number { return this.pricer.price(this.base); }
}

Python

# Before — one subclass per pricing tier
class Booking:
    def __init__(self, base):
        self.base = base

    def price(self):
        raise NotImplementedError

class RegularBooking(Booking):
    def price(self):
        return self.base

class PremiumBooking(Booking):
    def price(self):
        return self.base * 1.5 + 20

# After — one Booking that delegates pricing to a strategy
class RegularPricing:
    def price(self, base):
        return base

class PremiumPricing:
    def price(self, base):
        return base * 1.5 + 20

class Booking:
    def __init__(self, base, pricer):
        self.base = base
        self.pricer = pricer

    def price(self):
        return self.pricer.price(self.base)

Go

// Go has no subclasses to begin with. The idiomatic shape is exactly the
// "after": a Booking value holds a PricingPolicy interface and delegates.

type PricingPolicy interface {
    Price(base float64) float64
}

type RegularPricing struct{}

func (RegularPricing) Price(base float64) float64 { return base }

type PremiumPricing struct{}

func (PremiumPricing) Price(base float64) float64 { return base*1.5 + 20 }

type Booking struct {
    Base   float64
    Pricer PricingPolicy
}

func (b Booking) Price() float64 {
    return b.Pricer.Price(b.Base)
}

// booking := Booking{Base: 100, Pricer: PremiumPricing{}}

Rust

// Rust has no subclasses. The strategy is a trait object (or a generic
// type parameter) held by the single Booking struct.

trait PricingPolicy {
    fn price(&self, base: f64) -> f64;
}

struct RegularPricing;
impl PricingPolicy for RegularPricing {
    fn price(&self, base: f64) -> f64 {
        base
    }
}

struct PremiumPricing;
impl PricingPolicy for PremiumPricing {
    fn price(&self, base: f64) -> f64 {
        base * 1.5 + 20.0
    }
}

struct Booking {
    base: f64,
    pricer: Box<dyn PricingPolicy>,
}

impl Booking {
    fn price(&self) -> f64 {
        self.pricer.price(self.base)
    }
}

// let booking = Booking { base: 100.0, pricer: Box::new(PremiumPricing) };

classDiagram
  class Booking {
    -pricer: PricingPolicy
    +price() number
  }
  class PricingPolicy {
    <<interface>>
    +price(base) number
  }
  class RegularPricing
  class PremiumPricing
  Booking --> PricingPolicy : delegates
  PricingPolicy <|.. RegularPricing
  PricingPolicy <|.. PremiumPricing

ลำดับชั้นของ tier กลายเป็น Booking เดียวที่ delegate ไปยัง PricingPolicy

กลไกการทำงาน

1. ระบุแกนเดียวที่ subclass ต่างกัน — method (หรือกลุ่มเล็ก ๆ ของ method) ที่บอดี้ต่างกัน
2. นิยาม strategy interface (interface ใน TypeScript/Go, protocol หรือ duck-typed class ใน Python, trait ใน Rust) ที่จับ behavior ที่ผันแปรนั้นไว้
3. สำหรับแต่ละ subclass ที่มีอยู่ ให้สร้าง strategy implementation ที่ถือ logic ผันแปรเวอร์ชัน
4. เพิ่ม field บน base class เพื่อถือ strategy ไว้ แล้วทำให้ base class delegate method ที่ผันแปรไปยัง field นั้น
5. แทนการเรียก new SubclassX() แต่ละครั้งด้วย new Base(..., new StrategyX()) แล้วรัน test
6. ลบ subclass ที่ตอนนี้ว่างเปล่าทิ้ง

ใช้เมื่อไหร่ / ข้อแลกเปลี่ยน

หยิบสิ่งนี้มาใช้เมื่อ subclass ต่างกันเพียงในอัลกอริทึมที่สลับเปลี่ยนได้ เมื่อ object ต้อง เปลี่ยน รูปแบบขณะ runtime (สิ่งที่ inheritance ทำไม่ได้) หรือเมื่อแกนของความผันแปรสองแกนที่เป็นอิสระจะคูณกันกลายเป็นการระเบิดของ subclass — การประกอบ strategy field สองตัวขยายเป็นเชิงเส้น ส่วน subclass ขยายเป็นเชิงคูณ

ข้อแลกเปลี่ยนคือมี object เพิ่มมาหนึ่งตัวกับชั้นการอ้อมอีกชั้น เพราะตอนนี้ caller ต้องเดินสาย strategy ตอนสร้าง base object ซึ่งส่วนใหญ่ก็คุ้ม ส่วนใน Go และ Rust นี่คือวิธีปกติในการทำให้ behavior ผันแปรอยู่แล้ว เพราะทั้งสองภาษาไม่มีลำดับชั้น subclass ให้ใช้ คุณจึงเขียนแบบ delegate มาตั้งแต่ต้น

เนื้อหาที่เกี่ยวข้อง

• Replace Inheritance with Delegation
• Collapse Hierarchy
• Extract Superclass & Interface

ใช้ Replace Subclass with Delegation เมื่อ	หลีกเลี่ยงเมื่อ
object ต้องการเปลี่ยน “type” ใน runtime	subclass type คงที่ตลอด lifecycle
object ต้องการเป็นหลาย type พร้อมกัน	subclass มีแค่ 2 variant และไม่น่าจะเพิ่ม
inheritance hierarchy ลึกเกินไปและซับซ้อน	delegation จะเพิ่ม indirection ที่ไม่ได้ประโยชน์

⚠️ ไม่ควร Replace Subclass with Delegation เมื่อ:

• subclass type ไม่เปลี่ยนใน runtime — inheritance เหมาะกว่า
• มีแค่ 2 subclass ที่ง่ายและไม่น่าจะซับซ้อนขึ้น
• delegation จะเพิ่ม code มากกว่าที่ inheritance ลด

🧹 inheritance เป็นการเลือกที่ตายตัว; strategy เปลี่ยนได้

เหตุผลลึกที่สุดที่ควรเลือก delegate ตรงนี้คือ เวลา: subclass ถูกตัดสินตอน construction และถูกตรึงไว้ตลอดชีวิตของ object ส่วน strategy field สามารถถูก reassign, สลับ, หรือกระทั่งประกอบกับ strategy ตัวที่สองตามแกนที่เป็นอิสระ เมื่อ behavior ต้องผันแปรแบบ dynamic — หรือตามมิติมากกว่าหนึ่ง — composition ชนะอย่างเด็ดขาด นั่นคือเหตุผลที่ Go และ Rust ยื่นรูปแบบนี้ให้คุณเพียงอย่างเดียว

Replace Subclass with Delegation เหมาะที่สุดเมื่อ subclass ต่างกันตามแกนของความผันแปรกี่แกน?

ศูนย์ แกนเดียว (behavior ที่สลับเปลี่ยนได้หนึ่งอย่าง) เจ็ดแกนเป๊ะ ๆ ใช้กับ subclass ไม่ได้เลย

refactoring นี้เคลื่อนไปสู่ design pattern ใด?

Singleton Strategy Observer Visitor

strategy field ทำอะไรได้ที่การเลือก subclass ทำไม่ได้?

ถูกตัดสินตอน compile time ถูก reassign หรือสลับขณะ runtime และประกอบตามหลายแกน ไม่ถือ state ใด ๆ หลีกเลี่ยงการเรียก method ทั้งหมด

ทำไมนี่จึงเป็นรูปแบบค่าตั้งต้นใน Go และ Rust อยู่แล้ว?

ปรับ subclass ให้เป็น strategy โดยอัตโนมัติ ทั้งสองภาษาไม่มีลำดับชั้นของ subclass ดังนั้น behavior จึงถูกทำให้ผันแปรด้วยการถือ interface หรือ trait object ห้ามใช้ interface กำหนดให้ทุก type ต้องเป็น abstract

Submit

Mark as complete