De ce este considerat pattern-ul Singleton un anti-pattern?

Singleton încalcă principiile SOLID și complică testarea:

• Încălcarea principiului responsabilității unice (SRP): Clasa răspunde atât de logica sa, cât și de gestionarea ciclului său de viață (creare și acces la instanța unică).
• Încălcarea principiului deschis/închis (OCP): Extinderea funcționalității clasei Singleton poate fi dificilă fără a-i modifica codul.
• Încălcarea principiului substituției lui Liskov (LSP): Subtipurile clasei Singleton pot să nu îndeplinească contractele tipului de bază din cauza particularităților implementării Singleton.
• Încălcarea principiului inversiunii dependențelor (DIP): Modulele depind de o implementare concretă a Singleton, nu de abstracții. Acest lucru face dificilă înlocuirea obiectului Singleton cu un mock sau stub pentru testare.
• Probleme la testare: Instanța Singleton este o stare globală, ceea ce face dificilă executarea paralelă a testelor și izolarea scenariilor de testare. Este dificil să înlocuiți dependențele obiectului Singleton.
• Dependențe ascunse: Utilizarea Singleton ascunde dependențele între module, deoarece acestea nu sunt transmise explicit.
• Probleme cu multi-threading-ul: Necesitatea sincronizării accesului la instanța Singleton în mediile multi-thread poate duce la complicarea codului și la erori potențiale.
• Complexitatea gestionării: Gestionarea ciclului de viață al obiectului Singleton și eliminarea sa pot fi neclare.

În loc să folosiți Singleton, este adesea mai bine să utilizați injecția de dependență sau Service Locator pentru gestionarea ciclului de viață și accesul la obiecte.

Un exemplu de implementare tipică a Singleton în Swift care demonstrează problemele menționate:

// Singleton.swift
class DataManager {
    static let shared = DataManager() // Punct de acces global, ascunde dependența
    
    private init() { // Constructor privat, face dificilă crearea de mock-uri
        // Inițializarea resurselor sau stării
    }
    
    func fetchData() -> [String] {
        // Logica de obținere a datelor (de exemplu, din rețea sau bază de date)
        // Această logică este legată de gestionarea stării și de acces, încălcând SRP
        return ["Item 1", "Item 2"]
    }
}

// Exemplu de utilizare
// Modul care depinde direct de DataManager.shared
class ViewController {
    func displayData() {
        let data = DataManager.shared.fetchData() // Dependență ascunsă
        print(data)
    }
}

// Testarea ViewController devine dificilă:
// Cum înlocuiesc DataManager.shared cu un mock?
// Cum izolez testele dacă DataManager.shared este global?