Il peut exister une sorte de confusion entre Static et Singleton, pourtant il s’agit de choses bien différentes…
Langage ou architecture ?
La principale différence se cache dans la nature profonde des deux concepts.
- Static est une construction du langage.
- Un Singleton est un design pattern, c’est un concept d’architecture.
Il existe donc déjà à la base une nuance forte entre un simple élément de langage et un pattern qui est une construction intellectuelle visant à proposer une meilleure architecture du code.
On peut réaliser un singleton en utilisant une classe statique (simple possibilité) mais une classe statique n’est pas suffisante pour créer un singleton.
Instances et états
Une classe statique n’est pas instanciée par essence. Dans ce cas elle ne peut pas prétendre sérialiser ses états par exemple.
Mais est-ce une bonne pratique de gérer des états dans une classe statique ? non.
Une classe statique ne doit idéalement faire que proposer des méthodes ou des constantes. Par exemple on créera une classe statique pour regrouper des méthodes d’extension.
En revanche un Singleton peut avoir besoin de maintenir des états durant son fonctionnement.
C’est pour cela que l’implémentation d’un Singleton ne passe pas forcément par une classe statique…
Héritage
On ne peut pas hériter d’une classe statique. On peut avoir besoin d’hériter d’un Singleton.
Encore une nuance qui force à réfléchir !
Thread Safe ?
Par essence ni les classes statiques ni les singletons ne sont thread-safe. Il faut ajouter du code pour cela, il n’y a donc pas de différence sur ce point.
Quand utiliser l’un ou l’autre ?
Typiquement une classe statique s’utilise lorsqu’il n’y a besoin d’aucun héritage, immédiat ou dans le futur, et dans le cas où il n’y aucun état à gérer ni sérialisation de ces derniers (par exemple pour sauvegarde l’état en vue d’une réhydratation ultérieure).
Un Singleton s’utilise lorsque qu’on désire s’assurer de l’unicité d’une instance (service par exemple) tout en pouvant gérer ses états et leur éventuelles sérialisation / réhydratation (directement ou via le design pattern Memo par exemple), ceci en conservant la possibilité d’hériter du Singleton pour le spécialiser dans l’immédiat ou dans le futur (simple possibilité, un Singleton est souvent “sealed”).
Une classe statique n’a pas d’instance alors que le Singleton est un moyen de restreinte des instances (généralement une d’où son nom).
Enfin on notera qu’un singleton, parce qu’il existe une instance, peut être passé en paramètre à une méthode alors qu’une classe statique ne peut pas l’être. Et dans les constructions de type conteneur IoC et Injection de dépendances ce “petit” détail peut s’avérer tout simplement crucial.
Conclusion
Classe statique et Singleton n’ont finalement rien à voir. Il n’y a pas d’équivalence ni relation particulière entre les deux.
On peut utilise une classe statique pour construire un singleton mais cela n’est pas la meilleure solution. Le lien éventuel s’arrête là.
J’espère que ce petit point vous aidera à mieux choisir quand utiliser l’un ou l’autre de ces concepts pour produire un meilleur code !
Stay Tuned !