Le 4 Apr 2002 OLIVIER CAYRON a �crit :
>
> 2 - Tu as utilis� une Factory
> => tu n'as qu'une ligne � ajouter.
>
... et comme en g�n�ral les choses sont plus compliqu�es que �a tu
t'aper�ois qu'il y a 1 ou 2 textes que tu voulais pas qui soient en
vert fluo !
Moi j'aime pas beaucoup les factory. Mais c'est une impression, je
n'ai pas de preuves qui accusent les factory de je ne sais quoi.
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 :-(
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.
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. C'est un
peu plus difficile que la m�thode de cr�ation statique, puisqu'il
faut transmettre l'instance factory, mais je trouve que l'ensemble
est plus �l�guant ; on sait toujours qui cr�� quoi. Et l'ind�pandance
entre les diff�rents modules est beaucoup mieux respect�e, puisque
une factory s'occupe de telle portion de l'appli, telle autre factory
de telle autre portion, etc. Si tel module modifie la Factory parce
qu'il a besoin de telle "feature" (beuark !), il peut le faire sans
avoir a se demander si cela ne va pas g�ner le module voisin.
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,
on est vite amen� � se demander quel objet exactement on manipule. Et
les Factory ajoutent une impr�cision.
Quelles solutions ? Il y en a bien plus que les deux que tu
signales...
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. C'est rarement le cas, tout de m�me. 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.
Une deuxi�me approche est, au lieu de construire tes objets dans ton
appli, de les construire � part de ton appli, et de les s�rializer
dans un espace accessible � ton appli, celle-ci n'ayant plus qu'� les
d�serializer tels que.
Dans cette approche tu as un ensemble d'objets serializ�s que tu as
configur� pr�alablement. Par exemple, tous tes champs textes - ou du
moins une image de ceux-ci.
Dans ton appli, au lieu de faire un new TonChampTexte(), tu fais un
truc du genre recreator.deserialize("champTexteEnHautAGauche"). Moi,
j'utilise beaucoup un truc perso � base de JNDI.
A partir de l� les choses sont simples. Quelqu'un veut des champs
verts ? Tu configures pr�alablement tous tes champs serializ�s de
fa�on � ce qu'ils le soient. Et l� �a fonctionne m�me si tu n'as pas
�t� tr�s malin au niveau de la sp�cialisation des objets. Tu peux
configurer finement tel champ en vert, tel autre en rouge, etc.
Lorsqu'ensuite tu lances ton appli, tu d�s�rializes tous tes champs,
l'appli les trouve donc verts ou rouges (elle s'en fout), et elle les
affiche tels que.
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.
Et pour swing il y a aussi le L&F. J'ai jamais pratiqu� moi m�me,
mais cela viendra un jour...
A+.
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com