Singleton — यह क्या है, iOS और Android में क्लास का एकल इंस्टेंस

Singleton क्या है: सिंगलटन पैटर्न का सार?

Singleton — GoF (Gang of Four) द्वारा 1994 में वर्णित एक क्रिएशनल डिज़ाइन पैटर्न। यह पैटर्न दो समस्याएँ हल करता है: यह क्लास के इंस्टेंसिएशन को एक ऑब्जेक्ट तक सीमित करता है और उस ऑब्जेक्ट तक वैश्विक पहुँच प्रदान करता है। Singleton उन संसाधनों के लिए उपयोगी है जो अद्वितीय होने चाहिए: सेशन फ़ैक्टरी, इमेज कैश, डेटाबेस कनेक्शन मैनेजर, Crashlytics या Analytics क्लाइंट।

Singleton कार्यान्वयन में प्राइवेट कंस्ट्रक्टर (बाहरी निर्माण को रोकता है), एकमात्र इंस्टेंस वाला स्थैतिक फ़ील्ड और स्थैतिक एक्सेस विधि (shared, instance, getInstance) की आवश्यकता होती है। क्लाइंट ऑब्जेक्ट निर्माण की चिंता किए बिना Singleton.shared.method() कॉल करते हैं। यह पैटर्न iOS और Android में लोकप्रिय है: URLSession.shared, UserDefaults.standard, FirebaseApp.sharedInstance — ये सभी Singleton हैं। हालाँकि, Singleton का अत्यधिक उपयोग Global State एंटी-पैटर्न की ओर ले जाता है।

Singleton समस्याएँ — छिपी निर्भरताएँ (क्लासेस अंतर्निहित रूप से Singleton ऑब्जेक्ट पर निर्भर होती हैं), परीक्षण जटिलता (अतिरिक्त प्रयास के बिना परीक्षणों में इंस्टेंस को बदला नहीं जा सकता), Single Responsibility Principle का उल्लंघन (Singleton अपने इंस्टेंस और व्यावसायिक तर्क दोनों का प्रबंधन करता है)। आधुनिक मोबाइल डेवलपमेंट एकल इंस्टेंस के प्रबंधन के लिए DI (Dagger, Hilt, Swinject) पसंद करता है — DI कंटेनर ऑब्जेक्ट को एक बार बनाता है और कंस्ट्रक्टर के माध्यम से इंजेक्ट करता है।

iOS में Swift पर Singleton: shared और स्थैतिक गुण

Swift Singleton प्राइवेट इनिशियलाइज़र के साथ स्थैतिक shared गुण के माध्यम से कार्यान्वित किया जाता है। Swift 3 के बाद से, स्थैतिक गुणों की लेज़ी इनिशियलाइज़ेशन थ्रेड-सेफ़ होने की गारंटी है — कंपाइलर स्वचालित रूप से 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 से बदल दिया जाता है, जिससे परीक्षण क्षमता में सुधार होता है।

Android में Kotlin पर Singleton: companion object और object

Kotlin Singleton — सबसे सरल तरीका: object कीवर्ड पहली पहुँच पर लेज़ी इनिशियलाइज़ेशन के साथ सिंगलटन क्लास घोषित करता है। Kotlin object थ्रेड-सेफ़ है और अतिरिक्त सिंक्रनाइज़ेशन की आवश्यकता नहीं है। यदि कंस्ट्रक्टर पैरामीटर के साथ Singleton की आवश्यकता है, तो lazy डेलिगेट के साथ companion object का उपयोग किया जाता है। Android में, Application कॉन्टेक्स्ट और Application.onCreate() के माध्यम से इनिशियलाइज़ होने वाली सेवाओं के लिए Singleton अक्सर आवश्यक होता है।

// विकल्प 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 { /* ... */ }
}

Android SDK Singleton — 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 let) डिफ़ॉल्ट रूप से थ्रेड-सेफ़ होते हैं। Kotlin में, object थ्रेड-सेफ़ है। Kotlin में Java-शैली के लिए, synchronized या @Volatile + double-check locking का उपयोग किया जाता है।

Double-checked locking — Singleton की लेज़ी इनिशियलाइज़ेशन के लिए एक पैटर्न। पहली जाँच बिना सिंक्रनाइज़ेशन के (तेज़ यदि इंस्टेंस पहले से मौजूद है), दूसरी synchronized के अंदर (केवल एक थ्रेड द्वारा निर्माण)। @Volatile सभी थ्रेड के लिए परिवर्तनों की दृश्यता सुनिश्चित करता है। volatile के बिना, दूसरा थ्रेड आंशिक रूप से निर्मित ऑब्जेक्ट देख सकता है। Kotlin में, LazyThreadSafetyMode.SYNCHRONIZED के साथ lazy डेलिगेट स्वचालित रूप से double-checked locking लागू करता है।

Singleton vs Dependency Injection: कब उपयोग करें

Dependency Injection — एकल इंस्टेंस के प्रबंधन के लिए Singleton का एक विकल्प। DI कंटेनर (Dagger, Hilt, Koin, Swinject) ऑब्जेक्ट को एक बार Singleton स्कोप में बनाता है और कंस्ट्रक्टर के माध्यम से इंजेक्ट करता है। क्लास को अपनी Singleton स्थिति के बारे में पता नहीं होता — कंटेनर निर्णय लेता है। कोड परीक्षण योग्य हो जाता है: परीक्षणों में DI मॉड्यूल को mock मॉड्यूल से बदल दिया जाता है। DI के लाभ: कंस्ट्रक्टर में स्पष्ट निर्भरताएँ, ओवरराइड करने की क्षमता, एकीकृत जीवनचक्र।

Singleton कब उचित है — सिस्टम-स्तरीय ऑब्जेक्ट: Crashlytics, Analytics, Logging। ये सेवाएँ AppDelegate/Application में एक बार इनिशियलाइज़ होती हैं और हर जगह उपयोग की जाती हैं। उनके लिए DI अत्यधिक है। Singleton इमेज कैश (NSCache, Coil, Glide) के लिए भी सुविधाजनक है, जहाँ वैश्विक पहुँच प्रदर्शन द्वारा उचित है। बाकी सबके लिए, DI बेहतर है: यह निर्भरताओं को दृश्यमान बनाता है, परीक्षण और रीफैक्टरिंग को सरल बनाता है।

हाइब्रिड दृष्टिकोण — परीक्षणों के लिए ओवरराइड करने की क्षमता वाला Singleton। Swift में, एक प्रोटोकॉल + स्थैतिक गुण जिसे परीक्षण बदल सकते हैं (उदाहरण के लिए, URLSession के लिए URLProtocol के माध्यम से)। Kotlin में, एक इंजेक्टेबल गुण वाली open क्लास, जहाँ परीक्षण रिफ्लेक्शन या setter के माध्यम से mock सेट करते हैं। यह दृष्टिकोण Singleton की सरलता बनाए रखता है लेकिन परीक्षण क्षमताएँ प्रदान करता है। Google Android के लिए Hilt की सलाह देता है, Apple iOS के लिए DI थोपता नहीं — चुनाव टीम पर निर्भर करता है।