Comment l'utilisation du motif Singleton peut-elle violer les principes de polymorphisme?

Singleton limite la création d'instances d'une classe à un seul objet. Cependant, le polymorphisme implique la capacité de travailler avec des objets de différentes classes via une interface commune ou une classe de base.

La violation se produit lorsque le code client est rigidement lié à une classe Singleton spécifique, au lieu de travailler avec une abstraction (protocole ou classe de base). Dans ce cas, il n'est pas possible de substituer un autre objet alternatif qui implémente la même fonctionnalité, car le client attend précisément une instance de Singleton.

// Mauvaise utilisation - le client dépend directement de ConcreteSingleton
class ConcreteSingleton {
    static let shared = ConcreteSingleton()
    private init() {}

    func performAction() {
        print("Exécution d'une action depuis ConcreteSingleton")
    }
}

// Client
func clientFunction() {
    // Dépendance rigide à ConcreteSingleton
    ConcreteSingleton.shared.performAction()
}

// Bonne utilisation - le client dépend d'un protocole
protocol Service {
    func performAction()
}

class RealService: Service {
    func performAction() {
        print("Exécution d'une action depuis RealService")
    }
}

class MockService: Service {
    func performAction() {
        print("Exécution d'une action depuis MockService")
    }
}

// Singleton pour fournir une implémentation via un protocole (optionnel, peut utiliser DI)
class ServiceProvider {
    static let shared = ServiceProvider()
    private init() {}

    private var currentService: Service = RealService()

    func setService(_ service: Service) {
        currentService = service
    }

    func getService() -> Service {
        return currentService
    }
}

// Client
func flexibleClientFunction() {
    // Travail via l'abstraction (protocole)
    let service = ServiceProvider.shared.getService()
    service.performAction()
}

// Exemples de polymorphisme avec client flexible
// ServiceProvider.shared.setService(MockService())
// flexibleClientFunction() utilisera MockService

Ainsi, l'utilisation directe de la propriété statique shared du Singleton dans le code client réduit la flexibilité et empêche de remplacer les implémentations, ce qui est un aspect clé du polymorphisme lors du travail avec différents types d'objets via une interface commune. La solution consiste à travailler avec l'instance du Singleton via un protocole ou une classe de base.