Singleton — คืออะไร อินสแตนซ์เดียวของคลาสใน iOS และ Android

Singleton คืออะไร: แก่นแท้ของรูปแบบซิงเกิลตัน?

Singleton — รูปแบบการออกแบบเชิงสร้างที่อธิบายโดย GoF (Gang of Four) ในปี 1994 รูปแบบนี้แก้ปัญหาสองอย่าง: มันจำกัดการสร้างอินสแตนซ์ของคลาสให้เหลือเพียงวัตถุเดียวและให้การเข้าถึงส่วนกลางไปยังวัตถุนั้น Singleton มีประโยชน์สำหรับทรัพยากรที่ต้องไม่ซ้ำกัน: โรงงานเซสชัน, แคชรูปภาพ, ตัวจัดการการเชื่อมต่อฐานข้อมูล, ไคลเอ็นต์ Crashlytics หรือ Analytics

การนำ Singleton ไปใช้ ต้องการคอนสตรัคเตอร์ส่วนตัว (ป้องกันการสร้างจากภายนอก), ฟิลด์แบบ static พร้อมอินสแตนซ์เดียว, และเมธอดการเข้าถึงแบบ static (shared, instance, getInstance) ไคลเอ็นต์เรียก Singleton.shared.method() โดยไม่ต้องกังวลเกี่ยวกับการสร้างวัตถุ รูปแบบนี้เป็นที่นิยมใน iOS และ Android: URLSession.shared, UserDefaults.standard, FirebaseApp.sharedInstance — ทั้งหมดคือ Singleton อย่างไรก็ตาม การใช้ Singleton มากเกินไปนำไปสู่รูปแบบตรงข้าม Global State

ปัญหา Singleton — การพึ่งพาที่ซ่อนเร้น (คลาสพึ่งพาวัตถุ Singleton อย่างโดยปริยาย), ความซับซ้อนในการทดสอบ (ไม่สามารถแทนที่อินสแตนซ์ในการทดสอบได้โดยไม่ต้องใช้ความพยายามเพิ่มเติม), การละเมิดหลักการความรับผิดชอบเดียว (Singleton จัดการทั้งอินสแตนซ์ของตัวเองและตรรกะทางธุรกิจ) การพัฒนาโมบายล์สมัยใหม่นิยม DI (Dagger, Hilt, Swinject) สำหรับจัดการอินสแตนซ์เดียว — คอนเทนเนอร์ DI สร้างวัตถุหนึ่งครั้งและฉีดผ่านคอนสตรัคเตอร์

Singleton ใน iOS ด้วย Swift: shared และพรอพเพอร์ตี้แบบ static

Swift Singleton ถูกนำไปใช้ผ่านพรอพเพอร์ตี้ static shared พร้อมตัวเริ่มต้นส่วนตัว ตั้งแต่ Swift 3 เป็นต้นมา การเริ่มต้นแบบขี้เกียจของพรอพเพอร์ตี้แบบ static ถูกรับประกันว่าปลอดภัยต่อเธรด — คอมไพเลอร์เพิ่มการซิงโครไนซ์โดยอัตโนมัติผ่าน dispatch_once เพียงแค่ประกาศ static let shared = Class() และทำให้ init() เป็นส่วนตัวก็เพียงพอ Swift ไม่ต้องการการซิงโครไนซ์เพิ่มเติมสำหรับการเข้าถึงแบบเธรดเดียวหลังจากการเริ่มต้น

final class NetworkManager {
    // Singleton ที่ปลอดภัยต่อเธรด
    static let shared = NetworkManager()

    private init() {
        URLSessionConfiguration.default.timeoutIntervalForRequest = 30
    }

    private var cache = NSCache<NSString, NSData>()

    func fetchData(from url: URL) async throws -> Data {
        let key = url.absoluteString as NSString
        if let cached = cache.object(forKey: key) {
            return cached as Data
        }
        let (data, _) = try await URLSession.shared.data(from: url)
        cache.setObject(data as NSData, forKey: key)
        return data
    }
}

// การใช้งาน
let data = try await NetworkManager.shared.fetchData(from: url)

Apple Singleton — วัตถุ iOS SDK จำนวนมากใช้ Singleton: UIApplication.shared, UIScreen.main, FileManager.default, NotificationCenter.default, UserDefaults.standard Apple ใช้ Singleton สำหรับบริการที่ไม่ซ้ำกันทางกายภาพ (หน้าจอเดียว, แอปพลิเคชันเดียว) นักพัฒนาคัดลอกรูปแบบนี้สำหรับบริการของตนเอง ใน SwiftUI การเข้าถึงส่วนกลางไปยัง Singleton ถูกแทนที่ด้วย Environment และ @EnvironmentObject ซึ่งช่วยปรับปรุงความสามารถในการทดสอบ

Singleton ใน Android ด้วย Kotlin: companion object และ object

Kotlin Singleton — วิธีที่ง่ายที่สุด: คำสำคัญ object ประกาศคลาสซิงเกิลตันพร้อมการเริ่มต้นแบบขี้เกียจเมื่อเข้าถึงครั้งแรก Kotlin object ปลอดภัยต่อเธรดและไม่ต้องการการซิงโครไนซ์เพิ่มเติม หากต้องการ Singleton พร้อมพารามิเตอร์ของคอนสตรัคเตอร์ จะใช้ companion object พร้อมตัวแทน lazy ใน Android Singleton มักจำเป็นสำหรับบริบท Application และบริการที่เริ่มต้นผ่าน Application.onCreate()

// ตัวเลือก 1: object — Singleton ง่าย ๆ ไม่มีพารามิเตอร์
object AppPreferences {
    private val prefs = Application.instance
        .getSharedPreferences("app", Context.MODE_PRIVATE)

    var isFirstLaunch: Boolean
        get() = prefs.getBoolean("first_launch", true)
        set(value) = prefs.edit { putBoolean("first_launch", value) }
}

// ตัวเลือก 2: companion object — Singleton พร้อมพารามิเตอร์
class ApiClient private constructor(baseUrl: String) {
    companion object {
        @Volatile
        private var instance: ApiClient? = null

        fun getInstance(baseUrl: String): ApiClient {
            return instance ?: this.synchronized {
                instance ?: ApiClient(baseUrl).also { instance = it }
            }
        }
    }

    fun request(endpoint: String): String { /* ... */ }
}

Singleton ของ Android SDK — บริการระบบ Android หลายอย่างนำ Singleton ไปใช้: context.getSystemService(), Room.databaseBuilder(), Retrofit.Builder() ตัวอย่างรวมถึง SharedPreferences, MediaPlayer, AudioManager ในแอปพลิเคชัน Android Singleton มักใช้สำหรับพื้นที่เก็บข้อมูล ตัวจัดการ และโรงงาน Google แนะนำให้แทนที่ Singleton ด้วย DI (Hilt, Koin) ซึ่งขอบเขต Singleton (Scope.Singleton หรือ @Singleton) ถูกจัดการโดยคอนเทนเนอร์ในขณะที่คลาสยังคงสามารถทดสอบได้

Thread safety: dispatch_once, synchronized และ lock

Thread safety — ข้อกำหนดที่สำคัญสำหรับ Singleton ในสภาพแวดล้อมแบบหลายเธรด หากไม่มีการซิงโครไนซ์ สองเธรดสามารถตรวจสอบ instance == null พร้อมกันและสร้างสองอินสแตนซ์ได้ วิธีแก้ไขคือล็อกระหว่างการสร้างครั้งแรกและปล่อยหลังจากการเริ่มต้น ใน Swift พรอพเพอร์ตี้แบบ static (static let) ปลอดภัยต่อเธรดตามค่าเริ่มต้น ใน Kotlin object ปลอดภัยต่อเธรด สำหรับสไตล์ Java ใน Kotlin ใช้ synchronized หรือ @Volatile + double-check locking

Double-checked locking — รูปแบบสำหรับการเริ่มต้นแบบขี้เกียจของ Singleton การตรวจสอบครั้งแรกโดยไม่ซิงโครไนซ์ (รวดเร็วหากอินสแตนซ์มีอยู่แล้ว) ครั้งที่สองภายใน synchronized (สร้างโดยเธรดเดียวเท่านั้น) @Volatile รับประกันการมองเห็นการเปลี่ยนแปลงสำหรับทุกเธรด หากไม่มี volatile เธรดอื่นอาจเห็นวัตถุที่สร้างบางส่วน ใน Kotlin ตัวแทน lazy พร้อม LazyThreadSafetyMode.SYNCHRONIZED นำ double-checked locking ไปใช้โดยอัตโนมัติ

Singleton vs Dependency Injection: เมื่อใดควรใช้

Dependency Injection — ทางเลือกแทน Singleton สำหรับจัดการอินสแตนซ์เดียว คอนเทนเนอร์ DI (Dagger, Hilt, Koin, Swinject) สร้างวัตถุหนึ่งครั้งในขอบเขต Singleton และฉีดผ่านคอนสตรัคเตอร์ คลาสไม่ทราบเกี่ยวกับสถานะ Singleton ของมัน — คอนเทนเนอร์เป็นผู้ตัดสินใจ โค้ดสามารถทดสอบได้: โมดูล DI ถูกแทนที่ด้วยโมดูลจำลองในการทดสอบ ข้อดีของ DI: การพึ่งพาที่ชัดเจนในคอนสตรัคเตอร์, ความสามารถในการแทนที่, วงจรชีวิตที่เป็นหนึ่งเดียว

เมื่อใด Singleton สมเหตุสมผล — วัตถุระดับระบบ: Crashlytics, Analytics, Logging บริการเหล่านี้ถูกเริ่มต้นหนึ่งครั้งใน AppDelegate/Application และใช้ทุกที่ DI มากเกินไปสำหรับพวกเขา Singleton ยังสะดวกสำหรับแคชรูปภาพ (NSCache, Coil, Glide) ซึ่งการเข้าถึงส่วนกลางสมเหตุสมผลด้วยประสิทธิภาพ สำหรับสิ่งอื่นทั้งหมด DI ดีกว่า: ทำให้การพึ่งพามองเห็นได้ ช่วยให้การทดสอบและการปรับโครงสร้างง่ายขึ้น

แนวทางแบบผสม — Singleton ที่สามารถแทนที่ได้สำหรับการทดสอบ ใน Swift โปรโตคอล + พรอพเพอร์ตี้แบบ static ที่การทดสอบสามารถแทนที่ได้ (เช่น ผ่าน URLProtocol สำหรับ URLSession) ใน Kotlin คลาสเปิดพร้อมพรอพเพอร์ตี้ที่ฉีดได้ ซึ่งการทดสอบตั้งค่าจำลองผ่านการสะท้อนหรือ setter แนวทางนี้รักษาความเรียบง่ายของ Singleton แต่ให้ความสามารถในการทดสอบ Google แนะนำ Hilt สำหรับ Android Apple ไม่บังคับ DI สำหรับ iOS — การเลือกขึ้นอยู่กับทีม