Réponse.

Le modèle singleton (unique) est une technique populaire pour créer un objet qui existe en une seule instance dans une application. En Swift, l'implémentation du modèle a été simplifiée grâce à la prise en charge des propriétés statiques et de la sécurité des threads.

Historique de la question :

En Objective-C, l'implémentation du Singleton nécessitait un code long et non trivial lié à la sécurité des threads. En Swift, ce problème est résolu grâce à l'initialisation paresseuse des propriétés statiques.

Problème :

Le Singleton est souvent utilisé pour un accès centralisé à l'état de l'application (par exemple, Session, configurations, services), mais une mauvaise utilisation peut entraîner des dépendances implicites et une baisse de la testabilité du code.

Solution :

En Swift, le modèle est réalisé via une constante statique de type. Cela garantit la sécurité des threads et la clarté :

Exemple de code :

final class Logger {
    static let shared = Logger()
    private init() {}

    func log(_ message: String) {
        print(message)
    }
}

Logger.shared.log("Exemple de fonctionnement du Singleton")

Caractéristiques clés :

L'utilisation de static let garantit la sécurité des threads (créé une fois)
private init() empêche la création d'une instance directement
A une portée globale

Questions pièges.

Peut-on (et doit-on) toujours utiliser le singleton pour tous les services de l'application ?

Non. Le singleton est justifié pour un état véritablement global (par exemple, ApplicationSettings), mais l'utiliser pour les services de logique métier est incorrect : cela entraîne un couplage étroit et des problèmes de tests unitaires.

Le static let garantit-il une initialisation sécurisée des threads pour le Singleton en Swift ?

Oui, à partir de Swift 1.2 (et en raison de l'architecture runtime), static let est thread-safe par nature — il est initialisé une seule fois même en cas de concurrence entre les threads.

Un singleton peut-il être hérité ?

Non. Il vaut mieux déclarer la classe comme finale pour éviter l'héritage — sinon, il est possible de créer deux instances de singletons de classes héritées différentes, ce qui contredit l'idée même du modèle.

Erreurs typiques et anti-modèles

Utilisation de singleton pour tout et n'importe quoi, ce qui conduit à une mauvaise architecture
Violation de l'encapsulation des données dans le singleton
Initialisation implicite non via static let, création manuelle de singletons

Exemple de la vie réelle

Cas négatif

Un service de travail avec le réseau est réalisé via un singleton, et les méthodes utilisent un état global. Dans les tests unitaires, une dépendance implicite apparaît, la réutilisation du service est impossible.

Avantages :

Intégration simple, connexion rapide

Inconvénients :

Pas de testabilité, difficile à maintenir, dépendances « magiques »

Cas positif

Le Singleton est utilisé uniquement pour une entité véritablement globale — par exemple, ApplicationConfig. Tous les services reçoivent des dépendances via un injecteur explicite.