Design Pattern pour module de raisonnement

Bonjour,

Pour faire simple disons que je souhaite créer en c++ (même s'il s'agit avant tout d'une problèmatique de conception) un module de raisonnement.
Désolé si pour l'instant le terme est un peu flou (ça l'ai pour moi également) car j'ignore encore dans leur intégralités les fonctions et les limites que je veut apporter à un tel module.

Ce module de raisonnement doit permettre à travers l'évaluation d'un critère de qualité par exemple, de choisir quelle(s) stratégie(s) à adopter (== méthode à exécuter) dans le cadrre d'un problème précis.

Pour résumer, je disposerai donc de plusieurs méthodes pour déterminer une certaine particularité d'un modele 3d (par exemple savoir si le modèle passé en paramètre est un animal, si c'est le cas compter le nombre de pattes, etc pour déterminer s'il s'agit d'un chien ou d'un chat, ...). En cas d'échec sur une méthode, le module choisirai une autre option. Le résultat ne serai validé que si plusieurs stratégies on répondu favorablement au critère.
Et je veux faire ceci en C++ et en laissant la porte ouverte à l'implémentation de nouvelles stratégies d'ou mon soucis de posé des bases souples mais robustes.
Quelqu'un connait-il un Design Pattern ou quelque chose approchant susceptible de m'aider ?

Chain of responsibility dans le bouquin du GoF.

Ok merci.
Je vais regarder ça. L'implémentation dans le reste de mon projet va me prendre un peu de temps, mais je vous tiens au courant de mes avancées.

Je ne suis pas sûr de la pertinence des DPs traditionnels dans le monde de l'IA/du décisionnel.
Les arbres de décision me paraissent être une technique suffisament classique pour pouvoir être tout aussi respectables que n'importe quel design pattern.

Salut,

De prime abord, comme cela, j'aurais préféré m'orienter vers un partern... strategy, vu qu'il s'agit de metre une stratégie au point...

Mais, effectivement, un simple arbre de décison pourrais tres bien aussi faire l'affaire.

Il faut bien rester conscient du fait que les différents DP ne sont, en définitive, que des "canevas" qui permettent de résoudre des problèmes précis dans un contexte précis (parce que la personne qui l'a mis au point s'est rendu compte que ca revenrait régulièrement), mais qu'il n'y a, malgré tout, aucune obligation de l'utiliser si, d'aventure, on n'arrive pas à caller ce que l'on veut faire sur l'un de DP existant ;)

Allez, au passage, un peu de lecture sur les arbres de décision ;)

Merci de vos réponses. Excellent site sur les DPs de koala01.

Sinon j'avais déjà envisager les arbres de décisions mais je ne voyais pas comment l'appliquer à mon scope. En plus, si j'ai bien compris, il faut un ou plusieurs critères discirmants pour construire l'arbre et j'ai du mal à trouver de tels critères. Je pense qu'il conviennent mieux aux applications type AI. Et dernier point, dans mon cas si tout les tests échouent je dois pouvoir en dernier recours demander l'aide de l'utilisateur.

Bref, c'est pourquoi je me suis plutôt orienté sur une solution de type DP mais je peux encore changer d'avis :)

Je pense que le Chain of Responsability combiné à Strategy pourrait sans doute faire l'affaire.

Ps: déplacer moi sur le forum conception si besoin

Perso, moi le pattern Strategy c'est un terme que je trouve vraiment un peu trop pédant, la POO poussé à l'extrême.

Tout ça pour désigner une simple fonction/procédure (dépendant ou non d'un contexte).

On a en C++ a la chance de disposer d'une bonne implémentation de fonctions "first-class citizen" ; un simple boost::function (et bientôt std::function) muni de la bonne signature suffira, implémenté en terme de fonction partielle si nécessaire (closures).
Plus besoin d'héritage ou de classe à écrire.

Sauf si cas particulier...