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.
Je te suggere le design pattern "Strategy", je pense que c'est exactement ce que tu cherches et tu n'as pas besoin de concept etrange de "statique + heritage" (qui n'a pas de sens).
D'une maniere ou d'une autre, le choix de l'algorithme a utiliser a besoin d'un discriminateur. Tu veux que tes methodes soient statiques, ce qui signifie que l'instance de l'objet ne peut pas servir de discriminateur. Il te suffit donc d'en choisir un autre, probablement sous la forme d'un parametre supplementaire (mais sans precision sur ton probleme, c'est difficile de t'aider davantage).
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.
Tu as tout simplement besoin d'un moteur qui determinera quel est le meilleur algorithme en fonction de certaines contraintes. Ce moteur doit retourner une instance de l'algorithme adequat. Ca me semble plutot simple a implementer...
-- C�dric http://beust.com/weblog
