Merci pour ta r�ponse.
L'exemple 1 que je donnais �tait avant tout un cas "d'�cole" que j'ai rencontr� il y a peu. Effectivement, je n'avais pas pens� � la solution que tu donnes, qui est, somme toutes, assez simple conceptuellement.
Pour l'exemple 2, qui me pr�occupe actuellement, le contexte est grosso-modo l'utilisation de diff�rents algorithmes pour r�soudre un m�me probl�me. J'ai le choix entre des algos volumineux, poussifs, ou des algos rapides et peux volumineux qui ne fonctionnent que pour des conditions initiales particuli�res. Comme cet algo est appel� r�cursivement, j'ai un grand nombre d'instances simultan�ment en m�moire.
Il est vrai que le choix de la m�thode � utiliser peut-�tre fait au niveau de ma classe m�re (qui, fonction de l'analyse des param�tres, renverra une instance de l'une ou l'autre de ses classes filles). N�anmoins, le probl�me ne se pr�sente pas tout � fait sous cet angle : plus qu'une connaissance globale de l'ensemble de mes algos, j'ai surtout une connaissance locale : si j'estime, dans un premier temps, que B est la classe qui impl�mente l'algo qu'il me faut, je sais, apr�s analyse de mes param�tres (dans B), que j'ai tout � gagner � utiliser C. D'autre part, j'aimerais pouvoir ajouter d'autres algos, sans devoir faire d'ajouts � ma classe m�re (que je consid�re surtout comme une interface).
Voici pourquoi je pensais instancier mes classes � partir d'une m�thode statique et non via les constructeurs : Si je veux utiliser la m�thode impl�ment�e dans B, mais qu'� l'analyse des param�tres, B consid�re qu'il vaut mieux utiliser un C, je r�cup�re une instance de C.
Je ne connaissais pas le pattern Delegate (mais �a me para�t lourd, je vais n�anmoins essayer de me documenter l�-dessus).
chaine de responsabilites (chain of responsability) semble plus indiqu� ou encore un visiteur
Jerome
