Ouh l� l�, moi qui voulait donner une r�ponse rapide, simple,
sur l'utilisation des Factory, sans extrap�ler, pas de chance.
D'une part, je ne les utilise pas puisque travaillant avec NetBeans
(oui, je sais, bouhou, le pas beau).
D'autre part, tu ne devrais pas dire du mal des Factory. Tu es
tout seul contre la bande des 4, y'a surnombre... :o)
<snip/>
> La premi�re chose est que je crise avec les Factory � la mode Apache
> / Xerc�s / Xalan, je sais jamais exactement ce qui se passe :-(
Je croyais que c'�tait justement le but : que tu n'aie pas � te pr�occupier
du comment, mais simplement du r�sultat.
>
> D'abord, les Factory sont souvent mises en oeuvre � l'aide de
> m�thodes statiques. Je trouve que les m�thodes statiques sont tr�s
> mal implant�es en Java. Donc j'�vite de les utiliser.
Idem que Yagiz, pourquoi ?
>
> Il m'arrive de r�aliser des factory sur la base de m�thodes
> d'instances. Je fais pareil que toi, mais au lieu de faire
> Factory.createObject, je fais instanceFactory.createObject.
Je suis, moi aussi, fervent supporter des Singletons, m�me si j'ai
l�g�rement tendance � trop les utiliser.
<snip/>
> Et en plus, deuxi�me reproche, on ne sait jamais trop quel objet est
> cr�� exactement. Les defenseurs des factory pr�sentent �a comme un
> avantage, je trouve que ce n'est pas vrai : c'est un d�savantage.
> Cela pourrait �tre un avantage dans un monde objet id�al, mais dans
> le r�el, o� les architectures sont loin d'�tre toujours �l�guantes,
Peut-�tre, mais il faut savoir si TU veux avoir une r�elle abstraction
au niveau de la cr�ation de tes objets ou pas. L'utilisation des patterns
ne doit pas, AMHA, �tre syst�matique. Si elles ne r�pondent pas � tes
sp�cifications, il n'y a effectivement aucune raison de les utiliser.
Cependant, il y quand m�me des cas o� l'abstration a du bon.
> on est vite amen� � se demander quel objet exactement on manipule. Et
> les Factory ajoutent une impr�cision.
>
> D'abord, le "new" classique. Dans ton exemple 1, � savoir le new
> JTextField, tu pars de l'id�e qu'il n'y a aucune sp�cialisation des
> champs textes dans ton appli.
J'avais, effectivement, l'id�e d'expliquer cette approche (puisque c'est
celle que j'utilise) mais, comme dit plus haut, je voulais rester cadr�
sur l'utilis� des Factory (au tout au moins du regroupement de cr�ations
d'objets).
> C'est rarement le cas, tout de m�me.
Ah bon ? Je croyais que "dans le monde r�el, o� les architectures sont loin
d'�tre toujours �l�guantes, ... " ...
> Ou m�me, si ce n'est pas fait, la demande utilisateur - mettre "tous"
> les champs en vert - peut �tre une occasion de la faire, puisqu'on
> sait pertinement qu'il ne faudra pas les mettre "tous". Et si la
> sp�cialisation correcte est faite (bravo ! ), tu fais simplement ta
> modif dans le constructeur de l'objet, cela me parait tr�s bien. A
> mon avis, cette approche est excellente, je vois absolument pas ce
> que les factory apportent.
>
> En effet, si la sp�cialisation correcte n'est pas faite, que ce soit
> avec ou sans les factory, tu seras oblig� de revoir tout ton code.
>
Euh, rien n'emp�che ta Factory de faire des chose plus intelligentes qu'un
simple "return new TextField()", non ?
<snip/>
> Cette approche est tr�s �l�guante, si je puis me permettre, parce
> qu'elle permet toutes sortes de configurations, sans toucher un iota
> de l'appli principale, et tout en conservant une excellente
> visibilit� sur le qui fait quoi.
Ton approche (s�rialization), est int�ressante, mais si elle sort du cadre
du message initial.
> Et pour swing il y a aussi le L&F. J'ai jamais pratiqu� moi m�me,
> mais cela viendra un jour...
Oui, mais comme le reste, �a ne r�pond pas � tous les probl�mes.
Olivier
>
> A+.
>
> --
> Sur le Web, tout de suite.
> Herve AGNOUX - diaam informatique
> http://www.diaam-informatique.com
>
