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.
Je pense que c'est la bonne direction mais l'idee doit etre encore amelioree. Le fait qu'un algorithme fait deux choses:
- Decide s'il est approprie - Implemente l'algorithme
est une infraction au principle de responsabilite ("one class, one responsibility").
Je pense que la decision du meilleur algorithme doit etre effectuee en dehors des algorithmes (la classe que tu as appelee AlgorithmDeterminer, mais je recommande un nom different :-)). Cela dit, cette classe peut tout a fait consulter certaines methodes ou valeurs sur tous les algorithmes qu'elle connait avant de prendre sa decision.
Prenons l'exemple des collections. Il y en a des dizaines et elles ont toutes des caracteristiques differentes. Chaque collection devrait avoir une certaine implementation et aussi un ensemble de valeurs decrivant, par exemple, le cout d'une insertion, le cout d'un effacement, le cout d'un parcours, si elle est balancee, ordonnee, a valeur unique, etc...
Le "CollectionChooser" consultera toutes ces valeurs et retournera une instance de collection qui correspond le mieux aux contraintes fournies.
-- C�dric http://beust.com/weblog
