Merci pour ta r�ponse.
L'exemple 1 que je donnais �tait <...> somme toutes, assez simple conceptuellement.
Oui, c'est souvent avec des solutions simples qu'il faut chercher � r�pondre.
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).
Tu viens e te vendre, l� ! Si ta classe m�re est l� pour fournir un contrat, alors elle *doit* �tre une interface, et non une classe, car tu seras alors libre de fournir l'impl�mentation qui convient.
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.
La cha�ne de responsabilit� est alors le pattern le plus adapt� : tu disposes d'un "AlgorithmDeterminer" qui est une classe analogue au ValRepository de tout � l'heure.
Dans cette classe, tu disposes d'une m�thode getBestAlgo, qui va te retourner une classe impl�mentant A, et correspondant au probl�me pr�cis.
Initialement, l'AlgorithmDeterminer r�cup�re une instance de B gr�ce � une b�te association. Mais rien n'emp�che B de v�rifier s'il est le bon algorithme, et sinon de retourner un meilleur algorithme. En revanche, dans ce cas, la d�termination du meilleur algorithme que B ne peut se faire que dans ton instance de B.
Finallement, un bon mod�le conceptuel pour trouver la meilleure impl�mentation reviendrait � d�finir ton jeu d'algos comme une machine � �tat, o� chaque �tat est un algorithme particulier.
Et ce probl�me l� peut �tre r�solu de mani�re particuli�rement �l�gante en Java, en utilisant justement un bon m�lange d'interfaces et de classes ... mais je te laisse le soin de d�terminer la meilleure impl�mentation.
Je ne connaissais pas le pattern Delegate (mais �a me para�t lourd, je vais n�anmoins essayer de me documenter l�-dessus).
Lourd ? Ca revient juste � �crire tes m�thodes sous la forme : public void do() { delegate.do(); } Alors effectivement, si tu as des tonnes de m�thodes, c'est lourd ;-)
Je ne comprend pas bien ce que tu entends par pattern repository (tu veux dire quelquechose d'�quivalent � ValRepository ?) O� puis-je trouver de la doc ?
Aucune id�e
Merci encore. St�phan BERNARD
-- Nicolas Delsaux "Dans l'espace, personne ne vous entend crier"
