Design Pattern Singleton : utilité, exemples et bonnes pratiques

Tu veux comprendre le design pattern Singleton sans te noyer dans la théorie ? Bonne nouvelle, c’est l’un des patterns les plus simples à saisir — et l’un des plus utiles dans ta vie de développeur. Voici ce qu’on va explorer ensemble :

Ce qu’est vraiment un Singleton et pourquoi il existe
Les trois règles qui le définissent
Comment l’implémenter concrètement en PHP
Quand l’utiliser (et quand l’éviter absolument)
Les bonnes pratiques pour ne pas en abuser

Prête ? On y va.

Sommaire

Qu’est-ce que le design pattern Singleton ?

Le Singleton est un design pattern créationnel, c’est-à-dire un modèle de conception qui régit la façon dont les objets sont créés. Son rôle est simple mais puissant : garantir qu’une classe n’a qu’une seule instance dans toute l’application, et offrir un point d’accès global à cette instance.

Imagine une application web qui se connecte à une base de données. Si chaque partie du code crée sa propre connexion, tu te retrouves vite avec des dizaines de connexions ouvertes en parallèle — ce qui ralentit tout, peut provoquer des erreurs et gaspille des ressources. Le Singleton règle ce problème : une seule connexion est créée, et tout le monde l’utilise.

Le concept vient du livre de référence “Design Patterns: Elements of Reusable Object-Oriented Software” publié en 1994 par le Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides). Ce livre a posé les bases de la programmation orientée objet moderne, et le Singleton en est l’un des patterns les plus enseignés.

Les trois règles essentielles du Singleton

Le Singleton repose sur trois mécanismes qui travaillent ensemble. Retire l’un d’eux et le pattern s’effondre.

Un constructeur privé : il empêche toute création d’objet avec new depuis l’extérieur de la classe. Personne ne peut instancier la classe directement, ce qui force l’utilisation du point d’accès unique.
Une variable statique : elle stocke l’instance unique. Étant statique, elle est partagée entre tous les appels à la classe, quel que soit l’endroit dans le code.
Une méthode statique getInstance() : c’est le gardien du pattern. Elle vérifie si une instance existe déjà. Si oui, elle la renvoie. Sinon, elle la crée, la stocke dans la variable statique, puis la renvoie. À chaque appel, tu obtiens toujours le même objet.

Ces trois éléments forment un système hermétique : la classe contrôle elle-même son instanciation.

Comment fonctionne le Singleton ? (explication simple)

Voici la logique en pseudo-code, pour que ça soit limpide avant de passer à du vrai code :

classe Database {
  instance privée statique = null

  constructeur privé() {
    // connexion à la BD
  }

  méthode statique getInstance() {
    si instance == null {
      instance = nouveau Database()
    }
    retourner instance
  }
}

À chaque appel de Database::getInstance(), le code vérifie si instance est null. La première fois, elle l’est, donc un objet est créé. Toutes les fois suivantes, l’objet existant est renvoyé directement. Résultat : un seul objet pour toute la durée de vie de l’application.

C’est ce qu’on appelle le lazy loading : l’instance n’est créée que quand elle est réellement demandée, pas dès le démarrage de l’application. C’est économique en ressources.

Implémentation du Singleton en PHP : exemple complet

Voici une implémentation propre et commentée en PHP, avec une classe de connexion à une base de données via PDO :

php

<?php

class Database {
    // Stocke l'unique instance
    private static ?Database $instance = null;

    // Objet PDO pour la connexion
    private PDO $pdo;

    // Constructeur privé : interdit l'instanciation directe
    private function __construct() {
        $this->pdo = new PDO(
            'mysql:host=localhost;dbname=mabase;charset=utf8',
            'root',
            'motdepasse',
            [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
        );
    }

    // Empêche le clonage de l'instance
    private function __clone() {}

    // Point d'accès unique
    public static function getInstance(): Database {
        if (self::$instance === null) {
            self::$instance = new Database();
        }
        return self::$instance;
    }

    // Retourne l'objet PDO
    public function getConnection(): PDO {
        return $this->pdo;
    }
}

// Utilisation
$db1 = Database::getInstance();
$db2 = Database::getInstance();

var_dump($db1 === $db2); // bool(true) — c'est bien le même objet

Ce qu’il faut noter ici :

La méthode __clone() est privée pour interdire le clonage, qui créerait une deuxième instance.
Le type ?Database (nullable) signifie que la propriété peut valoir null au départ.
Le test $db1 === $db2 avec true en résultat confirme que les deux variables pointent vers le même objet en mémoire.

Quand faut-il utiliser un Singleton ?

Le Singleton est adapté dans des situations bien précises. Il ne faut pas l’utiliser par habitude ou par flemme, mais parce que la nature de l’objet le justifie réellement.

Cas où le Singleton est pertinent :

Connexion à une base de données : une seule connexion partagée évite la surcharge.
Système de logs : un logger unique centralise tous les messages d’erreurs et d’événements.
Configuration de l’application : charger un fichier de config YAML ou JSON une seule fois et y accéder partout.
Cache en mémoire : un seul objet gère les données mises en cache pour toute l’application.
Gestionnaire d’événements : un bus d’événements unique coordonne les communications entre composants.
Moteur graphique dans un jeu : un seul gestionnaire de rendu, une seule fenêtre principale.

La question à se poser avant d’implémenter un Singleton : “Est-ce que cet objet doit absolument être unique pour des raisons fonctionnelles ?” Si la réponse est oui, le Singleton est une solution propre. Si c’est juste pour éviter de passer l’objet en paramètre, il existe de meilleures approches.

Les limites et risques du design pattern Singleton

Le Singleton a beau être utile, il traîne quelques défauts qu’il faut connaître avant de l’adopter.

Le principal problème : l’état global. En rendant une instance accessible partout dans le code, tu introduis un état global. N’importe quelle partie de l’application peut modifier cet objet, ce qui rend le comportement du programme difficile à prédire et à déboguer.

Les tests unitaires deviennent compliqués. Quand tu testes une classe qui dépend d’un Singleton, tu ne peux pas facilement remplacer ce Singleton par un faux objet (un mock). L’objet est là, bien réel, et il impose ses dépendances. C’est l’un des reproches les plus fréquents faits au Singleton dans les équipes qui pratiquent le TDD (Test-Driven Development).

Le risque en multithreading. En Java notamment (moins en PHP qui est généralement mono-thread par requête), si deux threads appellent getInstance() en même temps alors que l’instance n’existe pas encore, deux objets peuvent être créés. La version thread-safe avec synchronized ou l’initialisation statique finale règle ce problème, mais elle ajoute de la complexité.

Le couplage fort. Utiliser Database::getInstance() directement dans des dizaines de classes crée une dépendance forte et cachée. Si tu veux un jour changer la façon dont la connexion est gérée, tu dois modifier partout. L’injection de dépendances est souvent préférable dans les architectures modernes.

Avantage	Limite
Instance unique garantie	Difficile à tester
Accès global simplifié	Crée un couplage fort
Économie de ressources	Risque en multithreading
Code centralisé	État global difficile à maîtriser

Bonnes pratiques pour un Singleton propre et maintenable

Si tu décides d’utiliser un Singleton, voici comment le faire correctement.

Documente ton intention. Indique dans le code pourquoi cette classe est un Singleton. Sans explication, les autres développeurs (ou toi dans six mois) risquent de ne pas comprendre le choix.
Empêche le clonage et la désérialisation. En PHP, pense à rendre __clone() et __wakeup() privés pour éviter les copies accidentelles.
Ne mets pas de logique métier dans ton Singleton. Il doit rester un simple gardien d’accès. La logique métier appartient à d’autres classes.
Préfère l’injection de dépendances dans les architectures modernes. Des frameworks comme Symfony ou Laravel proposent des conteneurs de services qui gèrent les instances uniques de façon plus propre, plus testable et plus flexible qu’un Singleton fait maison.
Questionne-toi avant d’implémenter. Demande-toi si l’objet doit vraiment être unique, ou si tu l’as rendu Singleton par commodité. La commodité est rarement une bonne raison.

Exemples concrets de Singletons dans des applications réelles

Pour ancrer tout ça dans la réalité, voici des cas où le Singleton est utilisé (ou a été utilisé) dans de vraies applications :

Eclipse IDE : la fenêtre principale de l’application est un Singleton. Il ne peut y avoir qu’une seule fenêtre principale ouverte à la fois, par nature.
Logger dans une application Symfony : Monolog, le système de logs utilisé par Symfony, peut être configuré comme un service unique partagé dans tout le conteneur.
Connexion PDO dans une petite application PHP : dans un projet sans framework, un Singleton Database permet d’éviter de créer plusieurs connexions à la base de données dans différents fichiers.
Gestionnaire de configuration : une classe qui charge un fichier config.json une seule fois au démarrage, et fournit les paramètres à toutes les parties de l’application sans relire le fichier à chaque fois.
Cache en mémoire : dans une application qui effectue des requêtes coûteuses, un Singleton Cache stocke les résultats et les réutilise sans retourner en base.
Moteur de jeu : dans un jeu vidéo, le gestionnaire de scènes, le moteur audio ou le gestionnaire de ressources graphiques sont souvent implémentés comme Singletons pour garantir qu’un seul objet orchestre ces ressources critiques.

Le design pattern Singleton, c’est un outil puissant quand il est utilisé à bon escient. Il répond à un besoin réel — garantir l’unicité d’une ressource partagée — mais il demande de la rigueur pour ne pas devenir une source de problèmes. Retiens les trois règles fondamentales, implémente-le proprement, et surtout, pose-toi toujours la question : est-ce que cet objet doit vraiment être unique ? Si oui, tu tiens la bonne solution.

Zoé

Je suis Zoé, passionnée de décoration, de mode et de tout ce qui met de la couleur dans le quotidien. Sur Zazou, je partage mes inspirations et mes coups de cœur pour transformer la maison, le style et la vie en une bulle joyeuse et créative.