Introduction

Lorsqu'on découvre la programmation orientée objet, le Singleton est souvent présenté comme un design pattern incontournable. Mais que signifie-t-il réellement ? Est-il vraiment indispensable ou simplement un outil pratique à utiliser avec prudence ?

Dans cet article, nous allons explorer en détail le Design Pattern Singleton avec des exemples concrets et pertinents. Nous aborderons également les erreurs courantes, les situations où il est particulièrement utile, ainsi que ses limites. Enfin, nous discuterons des bonnes pratiques pour l'utiliser efficacement.

Pourquoi avons-nous besoin du Singleton ?

Imaginez que vous développez une application pour gérer un système de logging. Vous souhaitez qu’un seul et unique objet soit responsable de la gestion des logs afin d’éviter les conflits ou les duplications. Créer une nouvelle instance à chaque fois serait inefficace et pourrait entraîner des problèmes de synchronisation. C’est précisément ici que le design pattern Singleton entre en jeu !

Le design pattern Singleton vous permet de :

• Contrôler l'accès à une seule et unique instance.
• Économiser des ressources en évitant des instanciations multiples inutiles.
• Centraliser des opérations critiques comme la configuration ou la gestion de ressources partagées.

Ce qu'il ne faut pas faire

Avant de plonger dans les implémentations correctes, examinons les erreurs courantes qui peuvent rendre le design pattern Singleton inefficace ou même risqué.

Qu'est-ce que c'est ?
Dans cette approche, l'instance du Singleton est créée dès que la classe est chargée en mémoire, même si elle n'est jamais utilisée. Cela peut entraîner un gaspillage de ressources.

public class Singleton
{
    private static readonly Singleton _instance = new Singleton();

    public static Singleton Instance => _instance;

    private Singleton()
    {
        Console.WriteLine("Singleton created!");
    }
}

Pourquoi est-ce un problème ?

• Si l'instance du Singleton n'est jamais utilisée dans l'application, elle occupe inutilement des ressources.
• Dans des applications complexes, diagnostiquer ce type de problème peut s'avérer difficile.

Qu'est-ce que c'est ?
Un constructeur public permet à n'importe qui de créer plusieurs instances de la classe, ce qui contredit le principe fondamental du design pattern Singleton.

public class Singleton
{
    public Singleton() {}
}

var instance1 = new Singleton();
var instance2 = new Singleton();

Pourquoi est-ce un problème ?
Le Singleton repose sur l'existence d'une seule instance. Si plusieurs instances peuvent être créées avec new, le concept même du Singleton est compromis.

Solution :
Rendre le constructeur privé pour empêcher toute instanciation externe.

Qu'est-ce que c'est ?
Si une classe Singleton est héritable, il est possible de créer des sous-classes, chacune ayant ses propres instances, ce qui va à l’encontre de l’objectif du Singleton.

Solution :
Marquer la classe comme sealed pour empêcher l’héritage.

public sealed class Singleton
{
    private static Singleton _instance;

    private Singleton() {}

    public static Singleton Instance
    {
        get
        {
            if (_instance == null)
            {
                _instance = new Singleton();
            }
            return _instance;
        }
    }
}

Comprendre le design pattern Singleton

Définition simple
Le Singleton est un design pattern de création qui garantit :

1. Qu'une classe n'a qu'une seule instance dans toute l'application.
2. Que cette instance est accessible globalement.

Imaginez une salle de concert avec un seul guichet. Chaque spectateur doit passer par ce guichet unique pour obtenir ses billets. Le Singleton agit comme ce guichet unique.

Caractéristiques clés
Unicité : Une seule instance existe.

Accessibilité globale : L'instance est disponible partout dans l'application.

Contrôle strict : La création de l'instance est rigoureusement contrôlée, généralement via un constructeur privé.

Implémentations en C#

Implémentation simple mais non thread-safe

Que fait ce code ?
Cette version crée une instance du Singleton uniquement lorsque la propriété Instance est appelée. Cela évite une instanciation inutile.

public class Singleton
{
    private static Singleton _instance;

    public static Singleton Instance
    {
        get
        {
            if (_instance == null)
            {
                _instance = new Singleton();
            }
            return _instance;
        }
    }

    private Singleton()
    {
        // Initialization.
    }
}

Risques :
Si deux threads accèdent simultanément à la propriété Instance, ils peuvent créer deux instances, ce qui viole le principe du Singleton.

Exemple avancé : Double-Check Locking

Pourquoi l'utiliser ?
Le double-check locking garantit qu'une seule instance est créée, même dans des environnements multithread, tout en réduisant au minimum la surcharge liée aux verrous (locks).

public class DoubleCheckSingleton
{
    private static DoubleCheckSingleton _instance;
    private static readonly object _lock = new object();

    public static DoubleCheckSingleton Instance
    {
        get
        {
            if (_instance == null)
            {
                lock (_lock)
                {
                    if (_instance == null)
                    {
                        _instance = new DoubleCheckSingleton();
                    }
                }
            }
            return _instance;
        }
    }

    private DoubleCheckSingleton()
    {
    }
}

Comment ça fonctionne ?

1. Le premier if évite d'utiliser un verrou inutilement si l'instance existe déjà.
2. Le verrou (lock) garantit qu'un seul thread peut créer l'instance.
3. Le second if vérifie à nouveau que l'instance n'a pas été créée pendant que le thread attendait le verrou.

Avantages :

• Meilleures performances par rapport à un verrou global.
• Thread-safe.

Inconvénient :
Le code est plus complexe et peut être difficile à lire pour les débutants.

Implémentation moderne avec Lazy

Pourquoi utiliser Lazy ?
Lazy<T> garantit que l'instance est créée uniquement lors du premier accès, tout en étant thread-safe par défaut.

public sealed class Singleton
{
    private static readonly Lazy<Singleton> _instance = new Lazy<Singleton>(() => new Singleton());

    public static Singleton Instance => _instance.Value;

    private Singleton()
    {
    }
}

Avantages :

• L'instance est créée uniquement si nécessaire.
• Le code est intrinsèquement thread-safe.
• On tire parti des outils intégrés fournis par .NET.

Limitation :
Cette approche convient dans la plupart des cas, mais si vous avez besoin d'un contrôle précis sur la création de l'instance, vous pourriez envisager une autre méthode.

Conclusion

Le design pattern Singleton est un outil puissant lorsqu'il est utilisé avec discernement. Cependant, il peut rapidement devenir un anti-pattern s'il est mal utilisé. En comprenant ses subtilités et ses pièges courants, les développeurs peuvent éviter d'introduire une complexité inutile ou des dépendances cachées.

Le Singleton n'est pas une solution universelle. Il est particulièrement adapté aux situations où une ressource unique et partagée doit être accessible globalement, comme des paramètres de configuration, des mécanismes de journalisation ou des systèmes de mise en cache. Évaluez toujours si le Singleton convient réellement à votre cas d'utilisation avant de l'intégrer à votre architecture.

Enfin, rappelez-vous que la clarté et la simplicité doivent toujours être prioritaires dans une implémentation. Que vous optiez pour une version thread-safe avec Lazy ou une autre variante, assurez-vous que votre conception est adaptée aux besoins de votre projet et reste maintenable sur le long terme.