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

Répondre à