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.

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

[roudoudouduo]

Effectivement quand j'ai crée ce topic je n'aurais pas du mettre qu'il ne sert à rien, car en vérité le singleton est très dangeureux. Il brise toutes les principes des bonnes pratiques.

Lorsque j'ai commencé à développer en C, le premier avertissement fait au débutant était que les variables globales étaient dangereuses car on ne pouvait prévoir leur accessibilité.

Le principe du singleton est de prévoir un point d'accès global à un objet ! Ca ne vous rapelle rien ?

N'en déplaise aux gens de ce forum, le singleton brise le principe d'encapsulation en rendant silencieuses une relation effective entre deux objets.

Il brise également le principe de responsabilité unique d'un objet : l'objet doit gérér sa problématique et en plus sa propre utilisation.

Sans compter bien sur que ce pattern présuppose que jamais dans la durée de vie du soft l'objet ne prendra de parametre, ne varira en fonction d'un contexte. Bref c'est prendre parie de l'immuabilite d'une application !

[wiztricks]

Côté 'conception', le singleton est et reste utile.

La réalisation doit prendre en compte d'autres réalités: multi-threads, langage de programmation, cycle de vie,... qui peuvent rendre assez cauchemardesque son codage.

Maintenant entre la conception de haut niveau ou le singleton reste un pattern utile et la réalisation, il y a une phase de spécifications détaillées qui est à priori là pour essayer de prendre en compte ces autres réalités et être plus précis sur les modalités/contraintes de réalisation.

Note: S'il est possible de faire une conception de haut niveau assez synthétique grâce à l'usage de patterns, dans les spécifications détaillées, on se permet en général d'agréger plusieurs patterns dans un même ensemble de classes. C'est une autre façon de dire que la conception de haut niveau décomposent le problème alors que spécifications détaillées visent à clarifier comment ce sera construit - et on construit toujours de bas en haut!
-W