Le 4 Apr 2002 Yagiz Erkan a �crit : > > Puis-je demander pourquoi? >
Les m�thodes statiques supportent mal l'h�ritage. Par exemple si j'ai une classe N qui h�rite de M avec dans toutes les deux une m�thode statique stat ; si je fais M obj = new N(), puis obj.stat(), ce sera la m�thodes M.stat() qui sera appel�e, alors que j'ai un objet de classe N. En plus la syntaxe est assez trompeuse ; quand j'�cris obj.stat() on croit que c'est une m�thode de l'objet "obj" de classe N, alors que c'est une m�thode de la classe M : il faut savoir que je l'ai d�clar� de la classe M, et j'en ai tout � fait le droit bien que ce soit un objet de la classe N. Heureusement, on peut �crire N.stat() ou M.stat(). En se donnant quelques r�gles d'�criture, cela am�liore la situation. > > on est vite amen� � se demander quel objet exactement on manipule. > > Hmmm... Je pense que c'est plut�t un avantage. Factory cr�e un object > de type interface et pas un objet d'une classe concrete, donc �a n'est > pas la peine de savoir quel genre d'objet tu manipules. C'est tout le > principe derri�re le Factory, non?!? En plus c'est d'apr�s la Factory > Method. Les choses se compliquent un peu plus avec Abstract Factory. > Une fois de plus, c'est vrai dans un monde id�al, �a ne l'est pas dans le monde r�el. Le meilleur exemple sont tous les parsers XML, o� fleurissent les factorys. Comme ils ont �t� incapables d'identifier diff�rents types de parsers, ils ont invent� la notion de feature. Un parser donn� est libre d'implanter telle ou telle feature (validation, indentation, DOM, etc...). Chacun est capable de dire s'il r�pond � telle ou telle feature. Quand tu fais un programme, tu es bien oblig� d'utiliser un parser qui a bien les features dont tu as besoin. Donc tu es bien oblig� de savoir quel parser tu utilises. Quand tu fais monParser = new CeParserCi(), tu sais parfaitement quel parser tu utilises. Mais quand tu fais monParser = factory.unParser(), tu ne le sais plus. Et du coup, tu es oblig� de placer dans ton code des tests pour savoir si le parser impl�mente tel ou tel feature pour bien controler que c'est compatible. Quel est le b�n�fice, je te le demande ? Tu te retrouves dans une situation o� c'est comme si tu devais controler que telle classe a bien telle ou telle m�thode, sauf que l�, la m�thode s'appelle "feature" - ou "parameter" ou "option". C'est ridicule. Cela dit, je ne suis pas contre les interfaces et les abstractions, loin de l�. Je suis contre les factory, c'est tout. > > Mes 2 cents, > Mes 2 cents moi aussi, �a fait 4 :-) -- Sur le Web, tout de suite. Herve AGNOUX - diaam informatique http://www.diaam-informatique.com
