> From: Herve AGNOUX [mailto:[EMAIL PROTECTED]]
> Le 4 Apr 2002 Yagiz Erkan a �crit : > > Puis-je demander pourquoi? > Les m�thodes statiques supportent mal l'h�ritage. Mal ? Elles ne le supportent pas :-) Mais c'est facile a contourner. L'exemple initial que je donnais n'est pas stricto sensu une "Factory", telle que definie dans Design Patterns. La solution ultime est quelque chose dans le genre: Factory.getUIFactory().getTextField(); La difference repose dans le fait que tu peux egalement faire un Factory.setUIFactory(ta_propre_factory), et ainsi redefinir l'integralite des widgets de ton application. Je pense que c'est que tu voulais en parlant d'heritage et de methode statique, non ? > 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. Certes, mais est-ce un bon argument ? Apres tout, tu peux dire la meme chose de : obj.foo(); Qui peut dire si foo() est invoque sur la classe de declaration de obj ou une sous-classe ? En l'occurrence, je pense que la semantique est devenue un peu plus complexe mais il y a tellement d'avantages qu'il n'y a aucune hesitation a avoir. Je pense que le meme argument s'applique aux factories. -- C�dric
