Singleton — ce este, instanța unică a clasei în iOS și Android

Ce este Singleton: esența modelului singleton?

Singleton — model constructiv descris de GoF (Gang of Four) în 1994. Modelul rezolvă două sarcini: limitează crearea instanței clasei la un singur obiect și oferă acces global la acest obiect. Singleton este util pentru resurse care trebuie să fie unice: fabrică de sesiuni, cache de imagini, manager de conexiune la baza de date, client Crashlytics sau Analytics.

Implementarea Singleton necesită un constructor privat (interzice crearea externă), un câmp static cu o singură instanță și o metodă statică de acces (shared, instance, getInstance). Clienții apelează Singleton.shared.method() fără a-și face griji despre crearea obiectului. Modelul este popular în iOS și Android: URLSession.shared, UserDefaults.standard, FirebaseApp.sharedInstance — toate sunt Singleton. Cu toate acestea, utilizarea excesivă a Singleton duce la anti-modelul Global State.

Problemele Singleton — dependențe ascunse (clasele depind implicit de obiectul Singleton), dificultatea testării (nu se poate înlocui instanța în test fără efort suplimentar), încălcarea Single Responsibility Principle (Singleton gestionează atât instanța sa, cât și logica de afaceri). Dezvoltarea mobilă modernă preferă DI (Dagger, Hilt, Swinject) pentru gestionarea instanțelor unice — containerul DI creează obiectul o dată și îl injectează prin constructor.

Singleton în iOS pe Swift: shared și proprietăți statice

Swift Singleton este implementat prin proprietatea statică shared cu un inițializator privat. Începând cu Swift 3, inițializarea lenesă a proprietăților statice este garantată ca sigură pentru fire — compilatorul adaugă automat sincronizare prin dispatch_once. Este suficient să declarați static let shared = Class() și să faceți init() privat. Swift nu necesită sincronizare suplimentară pentru accesul cu un singur fir după inițializare.

final class NetworkManager {
    // Thread-safe 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
    }
}

// Utilizare
let data = try await NetworkManager.shared.fetchData(from: url)

Apple Singleton — în iOS SDK multe obiecte folosesc Singleton: UIApplication.shared, UIScreen.main, FileManager.default, NotificationCenter.default, UserDefaults.standard. Apple folosește Singleton pentru servicii care sunt fizic unice (un ecran, o aplicație). Dezvoltatorii copiază acest model pentru serviciile lor. În SwiftUI accesul global la Singleton este înlocuit de Environment și @EnvironmentObject, ceea ce îmbunătățește testabilitatea.

Singleton în Android pe Kotlin: companion object și object

Kotlin Singleton — cel mai simplu mod: cuvântul cheie object declară o clasă-singleton cu inițializare lenesă la prima accesare. Kotlin object este sigur pentru fire și nu necesită sincronizare suplimentară. Dacă este necesar un Singleton cu parametri de constructor, se folosește companion object cu delegat lazy. În Android Singleton este adesea necesar pentru contextul Application și serviciile care sunt inițializate prin Application.onCreate().

// Varianta 1: object — Singleton simplu fără parametri
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) }
}

// Varianta 2: companion object — Singleton cu parametri
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 — multe servicii de sistem Android implementează Singleton: context.getSystemService(), Room.databaseBuilder(), Retrofit.Builder(). Exemplele includ SharedPreferences, MediaPlayer, AudioManager. În aplicațiile Android Singleton este adesea folosit pentru repository-uri, manageri și fabrici. Google recomandă înlocuirea Singleton cu DI (Hilt, Koin), unde domeniul Singleton (Scope.Singleton sau @Singleton) este gestionat de container, iar clasa rămâne testabilă.

Thread safety: dispatch_once, synchronized și lock

Thread safety — cerință critică pentru Singleton în mediul multi-thread. Fără sincronizare, două fire pot verifica simultan instance == null și crea două instanțe. Soluția — blocare la prima creare și eliberare după inițializare. În Swift proprietățile statice (static let) sunt sigure pentru fire în mod implicit. În Kotlin object este sigur pentru fire. Pentru stilul Java în Kotlin se folosește synchronized sau @Volatile + double-check locking.

Double-checked locking — model pentru inițializarea lenesă a Singleton. Prima verificare fără sincronizare (rapidă, dacă instanța este deja creată), a doua — în interiorul synchronized (crearea doar de un singur fir). @Volatile garantează vizibilitatea modificărilor pentru toate firele. Fără volatile un alt fir poate vedea un obiect parțial creat. În Kotlin delegatul lazy cu LazyThreadSafetyMode.SYNCHRONIZED implementează automat double-checked locking.

Singleton vs Dependency Injection: când să folosim

Dependency Injection — alternativă la Singleton pentru gestionarea instanței unice. Containerul DI (Dagger, Hilt, Koin, Swinject) creează obiectul o dată în domeniul Singleton și îl injectează prin constructor. Clasa nu știe despre starea sa de Singleton — aceasta este decisă de container. Codul devine testabil: în test modulul DI este înlocuit cu un modul mock. Avantajele DI: dependențe explicite în constructor, posibilitatea de suprascriere, ciclu de viață unitar.

Când Singleton este justificat — obiecte la nivel de sistem: Crashlytics, Analytics, Logging. Aceste servicii sunt inițializate o dată în AppDelegate/Application și utilizate peste tot. DI este excesiv pentru ele. Singleton este, de asemenea, convenabil pentru cache-uri de imagini (NSCache, Coil, Glide), unde accesul global este justificat de performanță. Pentru orice altceva DI este preferabil: face dependențele vizibile, simplifică testarea și refactorizarea.

Abordarea hibridă — Singleton cu posibilitatea de suprascriere pentru teste. În Swift se folosește un protocol + o proprietate statică pe care testul o poate înlocui (de exemplu, prin URLProtocol pentru URLSession). În Kotlin — o clasă deschisă cu proprietate injectabilă, unde testul setează mock prin reflexie sau setter. Această abordare păstrează simplitatea Singleton, dar oferă instrumente pentru testare. Google recomandă Hilt pentru Android, Apple nu impune DI pentru iOS — alegerea depinde de echipă.