Le 4 Apr 2002 OLIVIER CAYRON a �crit :
> Ouh l� l�, moi qui voulait donner une r�ponse rapide, simple,
> sur l'utilisation des Factory, sans extrap�ler, pas de chance.
>
D�sol� :-) Je lutte contre l'imp�rialisme des Factory :-)
> [...]
> Je suis, moi aussi, fervent supporter des Singletons, m�me si j'ai
> l�g�rement tendance � trop les utiliser.
>
Dans mon esprit, la factory ne devrait pas �tre un singleton, mais
devrait vraiment �tre un objet absolument comme les autres, c'est �
dire un truc que tu devrais pouvoir instancier autant de fois que tu
le voudrais.
Un truc approchant c'est le Document des objets DOM. DOM n'est peut
�tre pas un bon exemple, puisque c'est assez lourd � manipuler, mais
bon... Dans cette interface, tu as des tas de m�thodes de cr�ation
d'�l�ments divers. Ainsi, lorsque tu cr�es un �l�ment, c'est toujours
par rapport � un document. Et pourtant, Document n'est pas une
Factory au sens classique du terme, ou du moins de la mise en oeuvre
qu'on en fait : c'est juste une interface.
Note que tu ne sais jamais de quelles classes sont exactement ces
Document et ces Element, mais ils sont cr��s les uns par rapport aux
autres, tu sais qui manipule quoi. Le DOM n'est pas toujours bien
fait, d'ailleurs, parce que quelques fois on aimerait bien cr�er des
Element en dehors d'un Document, mais c'est une autre histoire.
Je ne suis, � la limite, par contre le mod�le des Factory, mais
contre leur mise en oeuvre par des m�thodes statiques ou m�me par des
singletons.
> [...]
> 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.
>
Je ne suis pas contre l'abstraction. Je dis que, la plupart du temps,
les Factory ne sont pas un bon moyen d'y arriver.
> [...]
> > 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).
>
Lorsque l'on veut regrouper la cr�ation d'objets, pourquoi passer par
des m�thodes statiques ? Tu peux tr�s bien te donner une instance
d'un objet � partir duquel tu regroupes les cr�ations d'autant
d'autres objets que tu veux.
La difficult� est que cette approche complique l'�criture du code,
puisqu'il faut passer l'instance cr�atrice, alors qu'une classe
cr�atrice est une sorte de variable globale accessible de partout.
Donc, dans certains cas, je comprends l'utilisation de Factory, pour
des trucs tr�s habituels et courants. Par exemple, si tu connais
log4j (un paquage de log pour java), on acc�de � une instance de log
par une m�thode statique d'une factory. C'est une des rares bonnes
application de la factory classique que je connaisse.
>
> > 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 ?
>
Et pourquoi le ferait-elle mieux que le new XX() ?
Admettons que tu es dans ta Factory, au d�part, un truc du genre
JTextField createTextField()
{
return new JTextField();
}
Suite � une demande client * non pr�vue *, tu vas vouloir les mettre
en vert, et tu vas donc faire :
JTextField createTextField()
{
JTextField jtf;
jtf = new JTextField();
jtf.setColor(Color.green);
return jtf;
}
Manque de chance, tu t'aper�ois que la demande d'origine est mal
formul�e, et que quelques champs ne devraient pas �tre en vert. Il
s'agit des champs, mettons, facultatifs (c'est un exemple). Tu vas
donc mettre dans ta m�thode de cr�ation quelque chose qui distingue
les champs facultatifs des autres.
Mais comment le feras-tu ? A quel moment mettras-tu "if (facultatif)"
? Comme tu n'as aucun param�tre � ta m�thode de cr�ation, tu ne peux
pas savoir si on te demande de cr�er un champ facultatif ou non. Tu
vas donc devoir cr�er une nouvelle m�thode type
"createOptionalTextField", et donc tu vas �tre oblig� de modifier
tout ton code applicatif !
Quel est l'avantage entre changer tf = Factory.createTextField() par
tf = Factory.createOptionalTextField, et changer tf = new
JTextField() par tf = new JOptionalTextField ?
Tu aurais d'autres solutions avec tes factory (mettre un param�tre,
bien s�r), mais toutes aboutissent � l'obligation de changer le code
de ta partie applicative. Donc, quel est l'avantage ?
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com
