Discussion :

[roudoudouduo]

J'ouvre un débat (déja vu certes) sur le design-pattern singleton. Le singleton souffre de multiples défauts, et le premier et non des moindres est d'instaurer un système de variable globale avec risque d'accès concurrentiel à une même ressource.

En réalité le pattern singleton peut-être remplacé simplement par deux concepts objet :
- la composition de l'instance (avec un new) dans l'object utilisateur ;
- l'utilisation du pattern util (qui est remplacé à tord par le singleton).

Si une même classe est utilisée d'un bout à l'autre de l'application (à travers le singleton) cela traduit une architecture très mauvaise avec un couplage très fort entre les objets et donc une modularité très faible.

Bref le pattern singleton ne sert à rien.

[djo.mos]

Salut,
Avant de se lancer dans le débat, veux tu s'il te plaît détailler cette partie (un petit exemple serait parfait):

En réalité le pattern singleton peut-être remplacé simplement par deux concepts objet :
- la composition de l'instance (avec un new) dans l'object utilisateur ;
- l'utilisation du pattern util (qui est remplacé à tord par le singleton).

[adiGuba]

Salut,

Le singleton souffre de multiples défauts, et le premier et non des moindres est d'instaurer un système de variable globale avec risque d'accès concurrentiel à une même ressource.

En même temps l'objectif du Singleton est de partager un objet unique et son état pour toute l'application, donc cela peut effectivement poser des problèmes dans un environnement multithread. Mais c'est le cas pour toutes les données partagées entre plusieurs threads...

En réalité le pattern singleton peut-être remplacé simplement par deux concepts objet :
- la composition de l'instance (avec un new) dans l'object utilisateur ;

En créant une instance par utilisateur on perd le suivi de l'état pour toute l'application. Chaque utilisateur utilise une instance avec un état qui lui est propre : c'est l'opposé même du pattern singleton !!!

- l'utilisation du pattern util (qui est remplacé à tord par le singleton).

Je suis d'accord avec toi sur le fait qu'il peut être remplacé à tord par le pattern singleton... mais encore une fois cela n'offre pas les mêmes services ! Il n'y a aucune notion d'état avec le pattern util...




Bref je dirais plutôt : il ne faut pas abuser du Singleton !

a++

[tchize_]

question d'expérience, je fuis les singletons comme la peste. Parmis les problèmes les plus grave que je leur trouve, c'est la possibilité de "traverser" l'isolation entre les webapp en utilisant les singletons système (je pense à l'enregistrement de handlers pour les URL ainsi que l'enregistrement de drivers jdbc). Mais je dois aussi admettre, quand on veux partager un même état avec toute un pan de l'application il n'y a que deux possibilité: çà ou passer l'instance partagée en paramètre de toutes les fonctions. Entre deux maux je choisi le moindre, l'utilisation du singleton avec parcimonie et discernement ^^. Je les aimes pas, mais on a pas toujours la possibilité de faire autrement. Au fait, une chose est sur, un singleton n'a rien à faire dans du code réutilisable d'une librairie

[adiGuba]

Entre deux maux je choisi le moindre, l'utilisation du singleton avec parcimonie et discernement ^^.

Le design pattern du Singleton est de loin le plus connu, et de ce fait le plus (mal) utilisé...

Il doit être utilsé pour accéder à un objet unique, et non pas pour "simplifier" l'appel de méthode...

a++

[ndp]

salut,
un de mes soucis avec le singleton, c'est qu'il se prete moins bien au tests automatises qu'une classe normale...
Ca vient principalement du fait qu'il garde son etat entre les executions, alors que c'est ce qu'on evite de faire pour rendre un code plus testable.

ps: quelqu'un a lien sur le pattern util?

[tchize_]

oui, le unit test est un cas typique où l'on voudrais que le singleton ne le sois pas Pour ces cas là, je surcharge le singleton en fournissant une méthode de nettoyage, ou je la prévois en protection package directement dans le singleton.

[djo.mos]

Salut,
Tout comme l'a dit adiGuba, il faut différencier les deux cas suivants:
Singleton pour exposer des méthodes utilitaires : pas très malin en soi, mais pose pas de problèmes à priori, à moins que ses méthodes agissent sur des champs, ce qui ouvre la porte aux problèmes dans un environnement multi-theradé
Singleton pour partager l'état : là, je ne vois vraiment pas l'inconvénient ni d'autre façon de pour le faire (je suis toujours curieux pour connaitre l'alternative que tu dis avoir . D'autant plus que si le singleton est un objet immuable, ce qui ôte toute contre argument à son utilisation. Je pense notamment à un DataSource initialisé au démarrage de l'application et partagé entre les DAOs ...


Autre chose : l'utilisation d'un conteneur comme Spring. Dans ce cas, le fait que l'objet sera déclaré singleton n'influence pas sur son design : tu codes un objet ordinaire, sans de champ statique et final INSTANCE ou de classe interne statique etc.
J'explique encore : si on code explicitement un objet en tant que singleton, ça va influencer sa sémantique et la façon de le coder, de sorte qu'il sera très pénible par la suite de l'adpater à une utilsation non-singleton.
Or, si on utilise un conteneur DI, c'est lui qui va se charger d'enforcer l'état du singelton, pas le programmeur. Il devient ensuite facile de le dé-singletoniser.
Pour revenir à l'exemple du DAO : je le code comme tout autre objet de mon application (avec une dépendance vers un DataSource), et puis c'est via configuration externe que je décide s'il est singleton ou pas.

Bien sûr il faut toujours faire attention au multithreading, mais ça, comme le remarque adiGuba, n'est pas une exclusivité des singletons.

Bref, de là à sauter directement à la conclusion que le Singleton en tant que Design Pattern ne sert à rien ...

[tchize_]

si ma mémoire est bonne, la design pattern explicite bien le fait que tu force l'état de singleton dans la structure meme de la classe. Donc je fait qu'un conteneur quelconque en gère une seule instance n'en fait pas une design pattern singleton.

[djo.mos]

si ma mémoire est bonne, la design pattern explicite bien le fait que tu force l'état de singleton dans la structure meme de la classe. Donc je fait qu'un conteneur quelconque en gère une seule instance n'en fait pas une design pattern singleton.

Je n'en suis pas si sûr

the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object.

Et :

a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code.

Ce qui fait qu'un Design pattern ne s'ocuppe pas des détails de l'implémentations ... Si c'est le conteneur qui enforce l'unicité d'un objet ou la façon de codage de l'objet ne fait pas de différence ...

[tchize_]

sauf que, dans ton cas, c'est pas forcé, on peut créer deux instance, avec un new par exemple.

[hed62]

qu'un Design pattern ne s'ocuppe pas des détails de l'implémentations ...

Effectivement.

on peut créer deux instance, avec un new par exemple

Alors l'implémentation a mal considéré les spécifications.

Dans le cadre du multithread, le livre "Design pattern, la tete la première" propose une bonne solution il me semble.

Bref le pattern singleton ne sert à rien.

Les design pattern sont, je pense, par définition suffisamment éprouvés et réfléchis pour ne pas avoir à justifier de leur existence. Par contre, je vous rejoins sur le fait qu'il est souvent mal employé.

[roudoudouduo]

Le pattern singleton, un peu à la manière des variables globales dans les langages procéduraux, rend implicite la communication entre les objets, et je préféré de loin passer l'instance unique en paramètre fut il immuable.

Voici un exemple qui montre la dangerosité du singleton (qui est certes très théorique, je le rédige en java). Voici une première implementation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public class ClientBaseDeDonnee {
  private final ConnexionBase connexionBase;
 
  public ClientBaseDeDonnee() {
      this.connexionBase = ConnexionPool.getInstance();
  }
}

Cette classe ClientBaseDeDonnee utilise un singleton pour pouvoir récupérer la connexion à la base de donnée. Plusieurs défauts :
- la classe d'appel à la connexion à la base est implicite, l'utilisateur ne voit pas qu'une connexion à la base est appelée à partir du ConnexionPool;
- il est impossible de faire varier la connexion à la base sans faire varier l'implémentation du singleton (et il parait difficile dans ce contexte de maitriser réellement les impacts de modfication d'un tel objet) ;
- dans un environnement déterministe (c'est a dire dans un environnement ou le getIntance() renvoie toujours la même chose), il sera impossible de créer des clients connectés à différentes base de données.

Conclusion : cette implémentation possède un couplage très fort et est peu évolutif.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public class ClientBaseDeDonnee {
  private final ConnexionBase connexionBase;
 
  public ClientBaseDeDonnee(ConnexionBase connexionBase) {
      if(null == connexionBase) {
          throw new NullPointerException();
      }
      this.connexionBase = connexionBase;
  }
}

Cette implémentation permet plus de souplesse si ConnexionBase est un type abstrait.

Sur ce modèle ce ne sont pas le threads eux même qui doivent aller chercher l'objet, mais l'object responsable de la création des threads.

Le principale reproche que je fais au singleton est de casser la réflexion à faire sur la responsabilité des objets et ainsi de créer des modèles difficilles à maintenir.

L'argument selon lequel "le design pattern singleton a été utilisé régulièrement donc il est bon" ne tient pas debout. Parceque avec la naissance du langage Java et des nombreuses applications crées, il est possible d'avoir maintenant des regards critiques sur les designs patterns (que j'utilise énormément à l'exception du singleton). De plus, je ne suis pas du genre à considérer comme immuable les principes d'aujourd'hui.

[djo.mos]

Salut,

sauf que, dans ton cas, c'est pas forcé, on peut créer deux instance, avec un new par exemple.

Euh ... les attributs privés d'une classe peuvent être manipulés par une classe externe via réflection ... etc.
Les Design Pattern c'est plus une démarche qu'on suit volontairement dans le codage (plutôt le design, mais je parle de l'implémentation) qu'un bout de code bullet-proof ... je serais curieux de voir comment tu pourrais enforcer les principes de quelques Design Pattern (t'avais déjà vu une implémentation correcte du pattern builder où seule les opérations possibles dans un état donné sont accessibles ? http://dow.ngra.de/2008/03/24/typesa...safe-bytecode/), etc.


Euh ... les deux exemples que tu montres ne traitent pas des singleton mais de la DI ... ou du pattern ServiceLocator

Je veux dire, même ton second exemple peut être utilisé avec une connexion définie comme singleton...
Si on va encore plus loin dans l'implémentation (toujours de la second méthode, on pourrait voir une chose du genre :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public class ClientBaseDeDonnee {
  private final ConnexionBase connexionBase;
 
  public ClientBaseDeDonnee(ConnexionBase connexionBase) {
      if(null == connexionBase) {
          throw new NullPointerException();
      }
      this.connexionBase = connexionBase;
  }
}
 
ClientBaseDeDonnee client = new ClientBaseDeDonnee(ConnexionPool.getInstance());//<-- :roll:

A moins que tu ne sois contre l'implémentation du singleton du type "ConnexionPool.getInstance()" plutôt que sur le principe ?

[JeitEmgie]

J'ouvre un débat (déja vu certes) sur le design-pattern singleton. Le singleton souffre de multiples défauts, et le premier et non des moindres est d'instaurer un système de variable globale avec risque d'accès concurrentiel à une même ressource.

En réalité le pattern singleton peut-être remplacé simplement par deux concepts objet :
- la composition de l'instance (avec un new) dans l'object utilisateur ;
- l'utilisation du pattern util (qui est remplacé à tord par le singleton).

Si une même classe est utilisée d'un bout à l'autre de l'application (à travers le singleton) cela traduit une architecture très mauvaise avec un couplage très fort entre les objets et donc une modularité très faible.

Bref le pattern singleton ne sert à rien.

la notion de "design pattern" appartient au conceptuel…
les notions de "variable" et d' "accès concurrentiel" appartiennent au réel…

vous nous dites donc que le concept ne sert à rien parce que souvent les hommes sont incapables de le réaliser correctement… ?

encore un débat "faut-il jetter le bébé avec l'eau du bain ?" …

[roudoudouduo]

Le premier point sur la réflexion est vraie mais je ne vois pas en quoi cela empêche d'avoir une conception de qualité...

Euh ... les deux exemples que tu montres ne traitent pas des singleton mais de la DI ... ou du pattern ServiceLocator

Je veux dire, même ton second exemple peut être utilisé avec une connexion définie comme singleton...
Si on va encore plus loin dans l'implémentation (toujours de la second méthode, on pourrait voir une chose du genre :

Code java :


public class ClientBaseDeDonnee {
private final ConnexionBase connexionBase;

public ClientBaseDeDonnee(ConnexionBase connexionBase) {
if(null == connexionBase) {
throw new NullPointerException();
}
this.connexionBase = connexionBase;
}
}

ClientBaseDeDonnee client = new ClientBaseDeDonnee(ConnexionPool.getInstance());//<--



A moins que tu ne sois contre l'implémentation du singleton du type "ConnexionPool.getInstance()" plutôt que sur le principe ?

Dailleurs dans ton exemple, il ne s'agit plus du pattern singleton mais du pattern state dans ce cas là (dailleurs le constructeur est privée pour ce pattern).

Il n'est pas adapté à la situation puisque dans le pattern state, on ne met que des éléments dont est assuré de l'immuabilité pendant la durée de vie de l'application (et pas seulement d'une instance de l'application bien sur).

Ce que je voulais dire dans mon exemple c'est que la classe client base de donnée n'a aucune raison de connaitre le ConnexionPool, c'est bien le fabriquant de la classe ClientBaseDeDonnee qui doit connaitre cette information.

Pour faire un parrellèle avec une voiture. Une voiture fonctionne avec de l'essence. L'essence peut-être fournis par n'importe quel station service. Hors si j'applique ton implémentation du ClientBaseDeDonne à ce principe, cela revient à dire que ma voiture ne peut se fournir en essence que dans une seule station ce qui en réalité faux.

Et pour aller encore plus loin la voiture a un utilisateur et c'est celui-ci qui va fournir l'essence la voiture et selectionner la station service.

Le problème de ton implémentation est qu'il manque un tiers (l'équivalant de la station d'essence qui fait le lien entre le pool de connexion et de la base de donnée).

Voici une implémentation possible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
final public class ClientBaseDeDonneeFactory() {

   public ClientBaseDeDonnee createNewClientBaseDeDonnee(BaseDeDonnee baseDeDonnee) {
      if(null == baseDeDeonne) {
           throw new NullPointerException(); 
      }
       return new ClientBaseDeDonnee(baseDeDonne.getPoolConnexion());

  }
}

final public class BaseDeDonnee {
     private final Connexion connexionBase;
     private BaseDeDonnee (String  url, String login, String mdp) {
         this.connexionBase = new Connexion(url, login, mdp);
     }

     public ConnexionPool getConnexionPool() {
          this.connexionBase.getPool();
     }

     public static final BaseDeDonne1 = new BaseDeDonnee("url1","","");

    public static final BaseDeDonne2 = new BaseDeDonnee("url2","","");
}

C'est juste un exemple de code dans lequel on n'utilise pas le pattern state bien sur on peut encore le complexifié. La création du client base de donnée est très souple puisque il peut se connecter à n'importe quel base de donnée definis dans la classe base de donnée.

[Hephaistos007]

Si vous trouvez des "défauts" au pattern singleton, alors c'est qu'il est mal utilisé, tout simplement. Les patterns en eux ne promettent que ce qu'ils sont. C'est de votre responsabilité de savoir quand les utiliser. C'est donc un faux débat.

En substance, le pattern singleton est là pour assurer que le mécanisme d'instanciation sur une classe ne soit utilisable qu'une et une seule fois. Rien de plus, rien de moins.

PS : je ne vois pas l'ombre du pattern état dans tout ce que j'ai vu ici
PS2 : si on peu faire des "new" sur une classe singletonisée, alors c'est qu'elle ne l'est pas !

[ndp]

Si vous trouvez des "défauts" au pattern singleton, alors c'est qu'il est mal utilisé, tout simplement. Les patterns en eux ne promettent que ce qu'ils sont. C'est de votre responsabilité de savoir quand les utiliser. C'est donc un faux débat ...

Si un pattern est mal utilise, c'est qu'il est mal documente

J'exagere un peu mais a peine.

Il ne faut pas oublier que les patterns ne sont pas des solutions coules dans le marbre. En parlant de design pattern, on parle bien d'experience,de travail documentaire, et partage de connaissance.

tu es d'accord Hephaistos007, ce n'est pas quelque chose qu'on peut arreter dans le temps, dans la forme et dans le fond, le Singleton ne s'est pas fige a la sortie du livre du GOF.
On prend la description d'un pattern qui a 20 ans, on prend un retour sur experience des debutants qui est principalement "mauvais", et souvent je vois deux attitudes de devs plus confirmes:

1. En premiere reaction: un peu ce que tu dis, c'est-a-dire "il est mal utilisé" point. Mais en ne changant rien, il va y avoir encore un paquet de debutant en conception objet qui vont faire les memes erreurs.
   
2. Ou sinon, tu expliques le pattern, en mettant l'accent sur les defauts (retour sur experience), et la, tu as partage cette idee de conception, avec un peu moins de risque qu'ils ne se plantent.

[Hephaistos007]

Si un pattern est mal utilise, c'est qu'il est mal documente

C'est pas faux.

Je trouve juste "gonflé" de reprocher au pattern singleton de ne pas permettre des connexions à différentes bases de donnée. C'est comme reprocher à une passoire de na pas permettre de servir la soupe. Maintenant, comme tu dis, si la passoire a été mal documentée...

[wiztricks]

C'est pas faux.

Je trouve juste "gonflé" de reprocher au pattern singleton de ne pas permettre des connexions à différentes bases de donnée. C'est comme reprocher à une passoire de na pas permettre de servir la soupe. Maintenant, comme tu dis, si la passoire a été mal documentée...

La difficulté est que des patterns peuvent être utilisés dans les différentes phases du projet pour signifier, imager certaines propriétés, relations.

En tant que pattern de conception une passoire renvoie a un concept illustrant égouter, filtrer, séparer un liquide des morceaux qu'il contient.

Il est possible que lorsqu'on ira préciser le "comment" que la taille des trous de cette passoire doit être suffisamment fine pour que, dans le contexte, l'opération ne soit possible qu'avec un filtre chimique... fort éloignée de la passoire "commune".

Dans le cas contraire, nous nous retrouverons avec une bonne vieille passoire qui pourra être aussi utilisée comme projectile ou comme casque.

Nos malheureux patterns se trouvent embarqués dans différentes représentations où leur signifiant n'a parfois de sens qu'associés à un contexte.

Et il est vrai qu'en faisant abstraction du contexte, ce type de discussion devient souvent un "rat hole".
- W