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.

Pourtant le code n’en est pas plus compliqué. Au contraire même :

public final class FileLogger implements Logger {&nbsp;<br />
&nbsp;&nbsp;private static FileLogger logger = new FileLogger();&nbsp;<br />
&nbsp;<br />
&nbsp;&nbsp;// Interdir les objets clients l'utilisation du constructor&nbsp;<br />
&nbsp;&nbsp;private FileLogger() {&nbsp;<br />
&nbsp;&nbsp;}&nbsp;<br />
&nbsp;<br />
&nbsp;&nbsp;public static FileLogger getFileLogger() {&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;return logger;&nbsp;<br />
&nbsp;&nbsp;}&nbsp;<br />
&nbsp;&nbsp;<br />
&nbsp;&nbsp;// Autres méthodes de la classe&nbsp;<br />
}

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++

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

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

– 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.