Singleton — co to jest, pojedyncza instancja klasy w iOS i Android

Czym jest Singleton: istota wzorca singleton?

Singleton — wzorzec konstrukcyjny opisany przez GoF (Gang of Four) w 1994 roku. Wzorzec rozwiązuje dwa zadania: ogranicza tworzenie instancji klasy do jednego obiektu i zapewnia globalny dostęp do tego obiektu. Singleton jest przydatny dla zasobów, które muszą być unikalne: fabryka sesji, pamięć podręczna obrazów, menedżer połączeń z bazą danych, klient Crashlytics lub Analytics.

Implementacja Singleton wymaga prywatnego konstruktora (zabrania zewnętrznego tworzenia), statycznego pola z pojedynczą instancją i statycznej metody dostępu (shared, instance, getInstance). Klienci wywołują Singleton.shared.method(), nie martwiąc się o tworzenie obiektu. Wzorzec jest popularny w iOS i Android: URLSession.shared, UserDefaults.standard, FirebaseApp.sharedInstance — wszystko to Singleton. Jednak nadmierne użycie Singleton prowadzi do antywzorca Global State.

Problemy Singleton — ukryte zależności (klasy niejawnie zależą od obiektu Singleton), trudność testowania (nie można zastąpić instancji w teście bez dodatkowego wysiłku), naruszenie Single Responsibility Principle (Singleton zarządza zarówno swoją instancją, jak i logiką biznesową). Współczesne programowanie mobilne preferuje DI (Dagger, Hilt, Swinject) do zarządzania pojedynczymi instancjami — kontener DI tworzy obiekt raz i wstrzykuje go przez konstruktor.

Singleton w iOS na Swift: shared i właściwości statyczne

Swift Singleton jest implementowany przez statyczną właściwość shared z prywatnym inicjalizatorem. Od Swift 3, leniwa inicjalizacja właściwości statycznych jest gwarantowana jako bezpieczna wątkowo — kompilator automatycznie dodaje synchronizację przez dispatch_once. Wystarczy zadeklarować static let shared = Class() i ustawić init() jako prywatny. Swift nie wymaga dodatkowej synchronizacji dla dostępu jednowątkowego po inicjalizacji.

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
    }
}

// Użycie
let data = try await NetworkManager.shared.fetchData(from: url)

Apple Singleton — w iOS SDK wiele obiektów używa Singleton: UIApplication.shared, UIScreen.main, FileManager.default, NotificationCenter.default, UserDefaults.standard. Apple używa Singleton dla usług, które są fizycznie unikalne (jeden ekran, jedna aplikacja). Deweloperzy kopiują ten wzorzec dla swoich usług. W SwiftUI globalny dostęp do Singleton jest zastępowany przez Environment i @EnvironmentObject, co poprawia testowalność.

Singleton w Android na Kotlin: companion object i object

Kotlin Singleton — najprostszy sposób: słowo kluczowe object deklaruje klasę-singleton z leniwą inicjalizacją przy pierwszym dostępie. Kotlin object jest bezpieczny wątkowo i nie wymaga dodatkowej synchronizacji. Jeśli potrzebny jest Singleton z parametrami konstruktora, używany jest companion object z delegatem lazy. W Android Singleton jest często niezbędny dla kontekstu Application i usług inicjalizowanych przez Application.onCreate().

// Wariant 1: object — prosty Singleton bez parametrów
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) }
}

// Wariant 2: companion object — Singleton z parametrami
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 — wiele systemowych usług Androida implementuje Singleton: context.getSystemService(), Room.databaseBuilder(), Retrofit.Builder(). Przykłady obejmują SharedPreferences, MediaPlayer, AudioManager. W aplikacjach Android Singleton jest często używany dla repozytoriów, menedżerów i fabryk. Google zaleca zastępowanie Singleton na DI (Hilt, Koin), gdzie zakres Singleton (Scope.Singleton lub @Singleton) jest zarządzany przez kontener, a klasa pozostaje testowalna.

Thread safety: dispatch_once, synchronized i lock

Thread safety — krytyczny wymóg dla Singleton w środowisku wielowątkowym. Bez synchronizacji dwa wątki mogą jednocześnie sprawdzić instance == null i utworzyć dwie instancje. Rozwiązanie — blokada przy pierwszym tworzeniu i zwolnienie po inicjalizacji. W Swift właściwości statyczne (static let) są bezpieczne wątkowo domyślnie. W Kotlin object jest bezpieczny wątkowo. Dla stylu Java w Kotlin używany jest synchronized lub @Volatile z double-check locking.

Double-checked locking — wzorzec dla leniwej inicjalizacji Singleton. Pierwsze sprawdzenie bez synchronizacji (szybkie, jeśli instancja już istnieje), drugie — wewnątrz synchronized (tworzenie tylko przez jeden wątek). @Volatile gwarantuje widoczność zmian dla wszystkich wątków. Bez volatile inny wątek może zobaczyć częściowo utworzony obiekt. W Kotlin delegat lazy z LazyThreadSafetyMode.SYNCHRONIZED automatycznie implementuje double-checked locking.

Singleton vs Dependency Injection: kiedy używać

Dependency Injection — alternatywa dla Singleton do zarządzania pojedynczą instancją. Kontener DI (Dagger, Hilt, Koin, Swinject) tworzy obiekt raz w zakresie Singleton i wstrzykuje go przez konstruktor. Klasa nie wie o swoim statusie Singleton — decyduje o tym kontener. Kod staje się testowalny: w teście moduł DI jest zastępowany przez moduł mock. Zalety DI: jawne zależności w konstruktorze, możliwość nadpisania, jednolity cykl życia.

Kiedy Singleton jest uzasadniony — obiekty systemowe: Crashlytics, Analytics, Logging. Te usługi są inicjalizowane raz w AppDelegate/Application i używane wszędzie. DI jest dla nich nadmiarowy. Singleton jest również wygodny dla pamięci podręcznych obrazów (NSCache, Coil, Glide), gdzie globalny dostęp jest uzasadniony wydajnością. Dla wszystkiego innego preferowany jest DI: czyni zależności widocznymi, upraszcza testowanie i refaktoryzację.

Podejście hybrydowe — Singleton z możliwością nadpisania dla testów. W Swift używany jest protokół + właściwość statyczna, którą test może zastąpić (np. przez URLProtocol dla URLSession). W Kotlin — open class z właściwością injectable, gdzie test ustawia mock przez refleksję lub setter. Takie podejście zachowuje prostotę Singleton, ale daje narzędzia do testowania. Google zaleca Hilt dla Android, Apple nie narzuca DI dla iOS — wybór zależy od zespołu.