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
