Singleton

จุดประสงค์

Singleton รับประกันว่า class ถูกสร้าง instance เพียงครั้งเดียวเท่านั้น และเปิดเผย instance เดียวนั้นผ่านจุดเข้าถึงที่แชร์กัน โดยสร้าง instance แบบ lazy ในการใช้งานครั้งแรก

ปัญหา

บางสิ่งในโปรแกรมเป็นเอกพจน์อย่างแท้จริง: configuration ที่ parse แล้ว, connection pool, registry ในหน่วยความจำ, หรือ logger หากทุกส่วนของระบบสร้างสำเนาของตัวเองขึ้นมา สำเนาเหล่านั้นก็จะหลุดออกจากกันและสิ้นเปลืองทรัพยากร คุณต้องการ object เดียว สร้างขึ้นในครั้งแรกที่มีใครร้องขอ และนำกลับมาใช้ซ้ำตลอดไป และคุณต้องการให้การรับประกันนั้นถูกบังคับใช้จริง ไม่ใช่อาศัยแค่ข้อตกลงร่วมกัน

ส่วนที่ละเอียดอ่อนคือ ใคร เป็นผู้บังคับใช้กฎนั้น code ทั่วไปสามารถเรียก constructor ได้กี่ครั้งก็ได้ตามใจ Singleton ย้ายการสร้างไปไว้หลัง accessor ที่ควบคุมได้ เพื่อให้ class เองเป็นเจ้าของกฎ ราคาที่ต้องจ่ายคือ instance นั้นกลายเป็น global state พร้อมกับอันตรายด้านการทดสอบและ concurrency ทั้งหมดที่ตามมา นั่นคือเหตุผลว่าทำไมวินัยของการมี หนึ่งเดียว จึงสำคัญกว่าลูกเล่นของการซ่อน constructor

โครงสร้าง

classDiagram
  class Singleton {
    -instance: Singleton$
    -Singleton()
    +getInstance() Singleton$
    +operation()
  }
  Singleton --> Singleton : holds static reference

Singleton ถือ static reference ไปยัง instance เดียวของตัวเอง

• Singleton — ตัว class เอง ซ่อน constructor ของตัวเอง ถือ private static reference ไปยัง instance เดียวนั้น และเปิดเผย static accessor ที่สร้าง instance ในการเรียกครั้งแรกแล้วคืน reference เดิมกลับมาทุกครั้งหลังจากนั้น
• Client — ผู้เรียกใด ๆ ไม่เคยสร้าง object โดยตรง แต่ขอ instance ที่แชร์กันจาก accessor

ตัวอย่าง

application config แบบอ่านอย่างเดียวขนาดเล็กที่โหลดเพียงครั้งเดียวและถูกแชร์ไปทุกที่ แต่ละภาษาใช้กลไกตามสำนวนของตนเองสำหรับ “สร้างเพียงครั้งเดียวเท่านั้น แบบ lazy และปลอดภัย”

TypeScript

class AppConfig {
  private static instance: AppConfig | null = null;
  readonly env: string;
  readonly maxConnections: number;

  private constructor() {
    // Pretend this reads from disk or the environment once.
    this.env = process.env.APP_ENV ?? 'development';
    this.maxConnections = 10;
  }

  static get(): AppConfig {
    if (AppConfig.instance === null) {
      AppConfig.instance = new AppConfig();
    }
    return AppConfig.instance;
  }
}

const a = AppConfig.get();
const b = AppConfig.get();
console.log(a === b); // true — same shared instance
console.log(a.env, a.maxConnections);

Python

class AppConfig:
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
            # Initialise the single instance exactly once.
            instance = cls._instance
            instance.env = "development"
            instance.max_connections = 10
        return cls._instance


a = AppConfig()
b = AppConfig()
print(a is b)  # True — __new__ returns the same object
print(a.env, a.max_connections)

Go

package main

import (
    "fmt"
    "sync"
)

type AppConfig struct {
    Env            string
    MaxConnections int
}

var (
    instance *AppConfig
    once     sync.Once
)

// Get returns the single AppConfig, building it on first call.
func Get() *AppConfig {
    once.Do(func() {
        instance = &AppConfig{Env: "development", MaxConnections: 10}
    })
    return instance
}

func main() {
    a := Get()
    b := Get()
    fmt.Println(a == b) // true — sync.Once guards construction
    fmt.Println(a.Env, a.MaxConnections)
}

Rust

use std::sync::OnceLock;

struct AppConfig {
    env: String,
    max_connections: u32,
}

fn config() -> &'static AppConfig {
    static INSTANCE: OnceLock<AppConfig> = OnceLock::new();
    INSTANCE.get_or_init(|| AppConfig {
        env: "development".to_string(),
        max_connections: 10,
    })
}

fn main() {
    let a = config();
    let b = config();
    // Both references point at the same static instance.
    println!("{}", std::ptr::eq(a, b)); // true
    println!("{} {}", a.env, a.max_connections);
}

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

• ข้อดี: รับประกัน instance เดียวและจุดเข้าถึงที่ชัดเจนเพียงจุดเดียวสำหรับ state ที่แชร์กันจริง ๆ
• ข้อดี: instance ถูกสร้างแบบ lazy คุณจึงจ่ายค่าตั้งค่าก็ต่อเมื่อมีการใช้งานจริงเท่านั้น
• ข้อเสีย: นี่คือ global mutable state ที่อำพรางไว้ dependency ที่ซ่อนอยู่ทำให้ code ทำความเข้าใจได้ยากขึ้น
• ข้อเสีย: ทำให้การทดสอบยุ่งยาก เทสต์แชร์ instance เดียวกันและไม่สามารถฉีด fake เข้าไปได้ง่าย ๆ เว้นแต่คุณออกแบบเผื่อไว้
• ข้อเสีย: การทำ lazy initialisation แบบไร้เดียงสาคือ race condition ภายใต้ concurrency คุณต้องป้องกันไว้ (อย่างที่ sync.Once และ OnceLock ทำข้างต้น)

pattern ที่เกี่ยวข้อง

• Abstract Factory มักถูก implement เป็น Singleton เพื่อให้ factory ตัวเดียวถูกแชร์กัน
• Prototype เสนอจุดยืนตรงข้าม — สร้างสำเนาจำนวนมากอย่างประหยัดแทนที่จะแชร์ตัวเดียว

	Singleton	Static Class	Dependency Injection
ทดสอบได้	ยาก (global state)	ยากมาก	ง่าย (inject mock ได้)
lazy init	ได้	ไม่ได้	ขึ้นกับ container
override	ยาก	ไม่ได้	ง่าย
เมื่อใช้	ต้องการ instance เดียวจริง ๆ	utility function ล้วน ๆ	ระบบที่ test ได้สำคัญ

🧩 ใช้อย่างระมัดระวัง

Singleton คือ global state ที่สวมเสื้อคลุมเป็น class ผูกผู้เรียกเข้ากับ instance ตัวหนึ่งโดยเฉพาะ และทำให้เทสต์ขึ้นกับลำดับการรัน เพราะทุกเทสต์ล้วนแตะ object เดียวกัน จงเลือกส่ง dependency เข้าไปอย่างชัดแจ้งดีกว่า แล้วหยิบ Singleton มาใช้ก็ต่อเมื่อสิ่งนั้นเป็นเอกพจน์อย่างแท้จริงและคุณรับต้นทุนของ global state ได้เท่านั้น

Singleton รับประกันอะไร?

instance ใหม่สำหรับผู้เรียกทุกราย instance เพียงหนึ่งเดียวเท่านั้น พร้อมจุดเข้าถึงที่แชร์กัน ว่า class ไม่สามารถถูก subclass ได้ การเข้าถึง field แบบ thread-safe บน object ใด ๆ

ทำไม lazy initialisation แบบไร้เดียงสาจึงต้องระวังเป็นพิเศษภายใต้ concurrency?

constructor ช้าเสมอ สอง thread อาจมองเห็นว่ายังไม่มี instance ทั้งคู่ แล้วต่างฝ่ายต่างสร้างขึ้นมาคนละตัว code แบบ lazy ไม่สามารถรันบนหลายคอร์ได้ garbage collector ลบ singleton ทิ้ง

กลไกใดของ Go ทำให้การสร้าง singleton รันได้มากที่สุดเพียงครั้งเดียว?

sync.Mutex.Lock sync.Once.Do go func() defer close(ch)

ข้อเสียหลักด้านความสามารถในการทดสอบของ Singleton คืออะไร?

Singleton ถือ field ใด ๆ ไม่ได้ Singleton เป็น global state ที่แชร์กัน ซึ่งเทสต์แยกออกหรือทำ fake ได้ยาก Singleton รันเฉพาะใน production build เท่านั้น Singleton ห้ามการใช้ interface

Submit

Mark as complete