août
2010
Un article de zerocoolyoussef
Description
Le Pattern singleton est facile à comprendre. Il nous aide à implémenter une classe pour laquel on a besoin q’une seule instance pendant la durée de vie de l’application comme : Connexion à une base de données,….
On pourrait implémenter facilement ce principe en ayant une variable globale pour maintenir une instance unique. Et tous les objets clients pourront l’utiliser. Mais cette approche ne pourra pas prévenir la création d’autres instances sauf que si tous les objets clients contrôleront eux même ses nombres d’instances.
Mais cela transgresse le principe de responsabilité des classe, puisque les objets clients n’ont pas à connaître le détails de création de la classe en question, puisque,c’est elle qui doit s’en charger.
Solution
Une classe qui maintient elle même son instance unique est appelée une classe singleton et le pattern Singleton nous aide à l’implémenter
Exemple
private static FileLogger logger;
//Interdir les objets clients l'utilisation du constructor
private FileLogger()[
}
public static FileLogger getFileLogger(){
if(logger==null) [
logger=new FileLogger();
}
return logger;
}
//Autres méthodes de la classe
}
Salut,
Pourtant le code n’en est pas plus compliqué. Au contraire même :
Pour le reste L’intérêt du singleton est de manipuler un objet avec un état qui pourrait varier pendant la durée de vie de l’application, le tout lié à des Factory par exemple.
Par contre il faut faire extrêmement attention lorsqu’on veut partager des ressources tel que les connections aux BD… Il y a d’autres solution pour cela !
a++
> A part le problème de la connexion de base de données qui est une problématique résolu à mon avis au niveau des serveurs d’application grâce à la notion de DataSource
Non, justement, en implémentant un Singleton sur tes connexions, tu te prives de l’utilisation du pool de connexion, ou tu la rends potentiellement instable (en fonction de la qualité de ton implémentation du singleton)
> Je pense que le Pattern Singleton doit être utilisé chaque fois qu’une seule instance est suffisante que ça serait pour avoir un système plus rapide.
Je crois que tu manques le point que je te levais précédemment…
Si une ressource est couteuse à créer, ok.
Si ta ressource ne coute quasi rien à créer, le fait d’utiliser un singleton va revenir, en terme de design, à l’utilisation d’une variable globale, ce qui est peu recommandé…en plus, implémenter un singleton en te disant que cela va accélérer ton système revient à faire une optimisation prématurée, basée sur de la spéculation plus que sur une mesure objective
Je peux te garantir qu’à l’usage, tu trouveras excessivement peu de cas ou ton Singleton est un vrai plus en terme de design et ne pourrait pas être avantageusement remplacé par une Factory un peu bien pensée…
Maintenant, je ne te demandes pas de me croire, mais de quelques problèmes indirectement ou directement liés à des singletons rencontrés au cours de ma modeste expérience, c’est un pattern que je ne réserverais qu’à des cas ou le besoin d’utiliser un singleton est motivé par une limite technique
A part le problème de la connexion de base de données qui est une problématique résolu à mon avis au niveau des serveurs d’application grâce à la notion de DataSource.Et si on utilise le pattern pour avoir l’instance de connexion à la base de données grâce au pool de connexion fournie par la datasource du serveur d’application je voie pas ou il aura du bug.
A part ca,Je pense que le Pattern Singleton doit être utilisé chaque fois qu’une seule instance est suffisante que ça serait pour avoir un système plus rapide.
C’est pour ça que je dis q’il faut pas utiliser ce pattern juste dans le cas où la création de la ressource est chère où il y’a une limitation matérielle mais à chaque fois q’une seule instance de classe est suffisante.
Toute fois j’ai vu des personnes qu’il utilise à la place des variables globales où pour maintenir l’état d’un objet à travers les différents modules de l’application , ou plus pour ne pas avoir à passer l’objet chaque fois comme paramètre aux fonctions. Ca c’est une mauvaise utilisation du Pattern.
> Il nous aide à implémenter une classe pour laquel on a besoin q’une seule instance pendant la durée de vie de l’application comme : Connexion à une base de données,….
L’exemple de la connexion à la base de données est un très mauvais exemple, en effet, si il est transposé sans réflexion, il peut devenir un point de bug dans une appli (oui, qqun m’à déjà dit que c’était une bonne idée de faire un Singleton pour une connexion à la base de données en web…)
Le pattern singleton est un des plus galvaudé et mal utilisés, il ne devrait avoir de sens que dans le cas ou la construction de la ressource est couteuse, ou qu’une limitation matérielle doit empêcher la création de plusieurs instances (genre, accès à une carte d’interface externe, etc…)
Le problème majeur étant que la plupart du temps, c’est le seul que les lecteurs des livres de design pattern retiennent
Oui exacte , je ne voulais pas trop compliqué les choses. Mais si on veut faire les choses en respectant les règles de l’art je dois rendre mon singleton thread-safe , et interdire le clonage et l’héritage.
Il est important de noter que :
– Dans cette exemple, la création de l’instance n’est pas thread-safe. En effet, il est possible de créer plusieurs instances de la classe FileLogger dans différents thread. (La probabilité que cela arrive est très faible, mais existante !). Dans ce cas, il faut protéger les accès concurrents via un mutex ou un moniteur.
– La durée de vie du singleton dépend du type d’application. Par exemple, en .NET, la durée de vie d’une variable statique (et donc d’un singleton) est celui d’un AppDomain. La durée de vie de ces objets est donc différente dans une application Windows et dans une application Web.