Le Lundi 9 Décembre 2002 11:48, Laurent Forêt a écrit : > En clair je ne vois pas l'apport de ce pattern, par rapport à mon ancienne > méthode. >
Pour moi ces deux méthodes sont à réserver au style "je fais comme ça pour aller plus vite et parce que j'ai pas envie / le temps de réfléchir". Et comme le singleton est de base plus compliqué que le static, malgré son coté éléguant et astucieux, j'ai tendance à le rejeter systématiquement. Pour moi, dans une application, l'accés aux objets doit être réglé par le jeux des liens entre objets. Ces liens doivent être stipulés par toutes méthodes à ta convenance - et malheureusement dans ce domaine avec Java c'est un peu le desert, mais tant pis. Cela peut être simplement les références d'attribut, de propriétés, des JNDI, etc. Ce sont ces liens qui determinent si un objet ou une classe est instancié une ou plusieurs fois. Mais la classe elle même n'a pas à determiner le nombre de fois qu'elle doit apparaître. Ce n'est pas son job et c'est une erreur de conception que de le faire à cet endroit là. On m'opposera j'imagine l'exemple de la classe System, prétenduement évidemment en un seul exemplaire. Mais je ne vois pas pourquoi les applis se limiteraient à créer et/ou à être créées par un seul système ? Une classe qui, par conception, est obligée de ne s'instancier qu'en un seul exemplaire est une classe mal conçue. Cela dit, si le concepteur ne sait pas faire autrement, il est bien evident qu'il doit rendre sa classe ou statique ou singleton. Avoir des principes c'est bien, mais point trop n'en faut. Tout cela se defend avec une bonne approche des liens. Tant que les concepteurs de Java se contrefouteront de cette notion, nous seront obligés d'utiliser des ersatz approximatifs. Alors, que ce soit les statics ou les singletons, ces derniers ayant de plus l'avantage de montrer qu'on s'y connait super en paternologie... Hugh ! -- SARL diaam informatique - 04 50 77 12 60 Ingenierie, développements de systèmes d'information http://www.diaam-informatique.com
