Discussion :

[behess]

Bonjour,

je suis sur un problème de conception sur lequel j'hésite un peu.

J'ai besoin de concevoir un modèle permettant une extensibilité totale.

Par exemple :

j'ai deux pommes, une granny smith et une golden.
j'ai deux instruments : l'un qui découpe en rondelles et l'autre qui pèle les pommes.

Seulement la découpe en rondelle ne fonctionne que sur les granny smith et le pelage que sur les golden.

Comment modéliser cela ?

Et si un jour je veux ajouter une nouvelle pomme et/ou un nouvel instrument, comment modéliser de manière à réduire au maximum l'impact sur l'existant (le réduire à zéro si possible) ?

Basiquement je peux utiliser l'héritage :
- une Granny est une Pomme, mais seules les granny ont une méthode
decouperEnRondelles(),
- une Golden est une Pomme, mais seules les golden ont une méthode peler(),

Si on va plus loin on peut décider que les instruments seront modélisés comme des interfaces :
- une Granny implémente l'interface iPeutEtreDecoupeeEnRondelles,
- une Golden implémente l'interface iPeutEtrePelee.

Mais si je veux rajouter une opération, je serais obligé de modifier les classes en conséquence pour ajouter une implémentation d'interface. Ce n'est donc pas une bonne solution.

Je peux peut-être utiliser le DP "Strategie", mais ce DP evoque une seule strategie. Si je veux pouvoir doter mes Pommes de plusieurs opérations, il faut que je trouve un moyen de l'en doter effectivement mais aussi de "choisir" l'opération à effectuer :
- je peux peut-être "ajouter" des stratégies à ma Pomme en associant chaque stratégie à une clé facilement identifiable comme "PELER" et utiliser simplement une méthode execute(eStrategie) ; rajouter une opération passerait par la modification de l'énumération et la création d'une classe stratégie.

Mais là aussi je me pose une question : ne serait-il pas plus simple de passer par un fichier (XML?) de définition des relations entre les opération et les pommes.

Il faudrait alors que les les opérations sachent décider si elles peuvent être utilisées sur telle ou telle pomme, via la lecture du fichier. Toutes les manipulations de Pomme devront alors passer par une série de méthodes "génériques" permettant de manipuler les attributs de la pomme (getProperty/setProperty).

N'est-ce pas un peu compliqué ? Y a-t-il plus simple (genre réflexivité) ?

[TheLeadingEdge]

Seulement la découpe en rondelle ne fonctionne que sur les granny smith et le pelage que sur les golden.

Essaie de te procurer le livre Design Patterns Head First. Tu devrais y trouver ton bonheur. Ca ne parle pas de pommes mais c'est avec des canards qu'ils ont ce genre de pb. Genre Canard qui vole, canard en bois, canard qui fait coin-coin, canard en plastique qui flotte mais qui vole pas et qui fait coin-coin etc...

[behess]

Merci monsieur

Je pense qu'il doit y avoir du DP tout prêt pour ça, mais si ça inspire quelqu'un qui a déjà eu la même problématique, je veux bien des conseils.

Je vais me plonger dans ce bouquin déjà.

[hed62]

Essaie de rechercher "Patron de méthode", ca peut t'inspirer.

[behess]

Le DP "Template Method" c'est une idée associé notamment au DP "Strategy", mais ça ne permet pas forcément une extensibilité totale.

Je pensais plutôt utiliser un système à messages, comme le DP "Command" ou le DP "Observer", encore que ce ne soit pas tout à fait aussi simple que ça.

Je me suis dit qu'avec une IoD je pourrais "injecter" des "Strategy" à des objets basiques pour les "décorer" (DP "Decorator").

Il faudrait peut-être que mes objets "sachent" ce qu'ils sont capables de faire, ils auraient donc une liste de stratégies à leur disposition et lors de la réception d'un événement, ils tenteraient un mise en relation ; une fois la bonne stratégie trouvée par rapport à l'événement reçu, il suffirait de fournir à la stratégie le contexte apporté par l'événement (comme une sorte de commande en fait).

Ainsi, avec des objets de base je peux agrémenter l'application de comportements au fur et à mesure des besoins.

Qu'en pensez-vous ?

[behess]

En cherchant encore un peu j'ai trouvé un article vraiment pas mal :

http://pcaboche.developpez.com/artic...?page=sommaire

Je pense qu'il contient pas mal d'infos qui vont bien m'être utiles.

[behess]

Le DP "Visitor" pourrait également être utilisé, mais le problème c'est qu'il faut prévoir une méthode pour tous les objets à visiter.

Or si on ajouter un objet à la hiérarchie d'objets, mes Visitors ne sauront pas le traiter... il faudra alors tous les modifier et les recompiler.

Je pense qu'il faut que je combine le DP "Visitor" avec le DP "Strategy" et le DP "IoC" :


Un Visitor serait Fabriqué selon un descripteur externe (Xml) en lui injectant (IoC) les Strategies (opérations similaires sur différentes Classes, un peu comme du polymorphisme paramétrique dynamique) qui vont bien. C'est un peu une Décoration de Visitor avec des Strategies, non ?

Ici c'est le Visitor qui saurait sur quels objets il peut effectuer son traitement.

Lors d'un "contact" entre deux objets (on parlera d'événement), l'émetteur de l'événement applique un Visitor sur le receveur. Si le Visitor sait traiter le receveur, alors il effectue le traitement, sinon il renvoit une erreur.

Est-ce une approche "valide" ?
Si oui comment procéder lors de l'implémentation ? (ex : en java).
-> notamment pour que le Visitor "sache" quels objets il peut traiter (ie. de quels stratégies il dispose et comment les lui faire appliquer).

A ce sujet je me dis qu'il faudrait peut-être "injecter" des Classes Stratégie dans le Visitor plutôt que des objets. Ce serait au visitor d'instancier ses stratégies selon les événements.

Mais comment savoir si une stratégie (Classe) donnée peut traiter un type d'objet (Classe) donné ?

Il faudrait que les classes soient instanciées puis que la méthode execute soit tentée sur l'objet à traiter pour voir s'il est rejeté ou pas ? C'est un peu lourd je trouve, non ?

[Phelim]

Je vois 2 étapes pour l'extension et pas une seule :
- nouvelle fonctionnalité independante
- fonctionnalités ou donnée composés

1 fonctionnalité independante n'a pas besoin d'interagir avec d'autres extensions.
1 composition de fonctionnalité et de donnée se font à l'interieur d'une fonctionnalité independante.

Deja une fabrique me parait un point de depart pour la modularité.
Tu vas en fonction du nom du parametre chercher un fichier et charger la class a l interieur.
Un exemple de codage serait :
PrefixeProg_NomClass

Pour etendre ton systeme, 1 methode est : l'observer. Je rajoute a l'objet observable initial la class que tu viens d'instancier. (Extension de nouvelles fonctionnalités independantes).
Pour l'observer, la methode d'appelle doit etre commune à toutes les classes de configuration (non problematique si tes fonctionnalités sont independantes)

On a besoin d'une nouvelle fabrique pour etendre les objets observers.

Le passage des données initiales à l'observer doit se faire a partir de la fabrique.

Pour finir, il te reste à pouvoir composé les fonctionnalités (ça depend de ce que tes utilisateurs vont specifier). Ils peuvent specifier des fonctionnalités ou un comportement, dans ce cas, il faut faire appel à des decorateurs.
Si ils specifient des combinaisons de données, ca sera un simple pattern composite.

Ton systeme sera la parfaitement extensible. Seulement le codage des extensions devra suivre une methode tres particuliere et parfaitement codifié.

Apres tes utilisateurs pourront coder des fichiers textes plus simples (XML ou autre specification) qui feront appel à ce systeme

[behess]

Tu me parles d'une extensibilité "à chaud" si je ne m'abuse...

En gros : on a un système qui tourne et on veut "pluguer" une fonctionnalité en cours de route ?

Sinon je comprends pas l'intérêt de l'observer :

Moi je parle d'une extensibilité "à froid" ; si tu as un système de descripteur Xml, un simple arrêt/relance de ton système te permet de recharger les nouvelles fonctionnalités !

Par contre si c'est bien pour un plugin à chaud, ça m'intéresse aussi et là j'ai envie de dire : sois plus clair, détaille coco

Merci quand même.

[behess]

En restant sur ce cas, Bebe emet des Event qu'il ne sais pas gérer (il émet plain de choses, mais ne sais que recevoir de la nourriture par exemple)

Voila comment je voyais les choses.

Du coup je vois qu'il faut doter les agents d'abilities compatibles avec les behaviors et les autres agents

De ce fait, ce n'est pas nécessaire forcément (enfin là ca dépend, cela demande reflexion)

Je pense qu'il y a différents types de signaux (events) à traiter.

Par exemple :

• les requêtes d'action (ex : interjection "hey ! je veux manger une pomme !!!" qui peut se traduire par : requeteAction("donner la pomme") )
• et les actions proprement dites (ex : realiserAction("donner la pomme") )

L'agent ne peut emettre des requêtes que d'actions qu'il sait traiter (parce qu'il a la capacité personnellement ou parce qu'il connait un agent capable de le traiter).

Toute requête d'action qu'un agent ne peut gérer peut (doit?) être retransmis selon son "caractère" par cet Agent à ses sous-Agents (ex : les outils dont il est doté) ou à des Agents qu'il connaît personnellement (copinage).

En fait je dirais même qu'il doit pouvoir mémoriser les capacités des agents qu'il croise et la dernière position de l'agent considéré. Seuls ses sous-agents - toujours disponibles - n'ont pas besoin d'être mémorisés.

Ainsi en cas de besoin il va pouvoir partir "à la recherche" de l'agent qui peut traiter la requête.

ça me fait penser qu'un autre problème peut apparaitre avec le modèle d'observer : à moins que ce soit un Event "pour tous" (ex : un gaz mortel qui se répand est valable pour tous, pas seulement le premier qui le respire) il faut qu'un Event ne soit traité qu'une seule fois ; si plusieurs observers reçoivent l'Event, il faut qu'il soit "marqué" dès qu'il est traité.

Il se peut aussi qu'un Event ne soit traitable par aucun Agent... qu'en faire dans ce cas ?

1. soit le Monde le conserve pour le réemettre régulièrement
2. soit le "tuer" et le classer sans suite, à la charge de l'émetteur de le réemettre
3. soit un mixe des deux (ex: un affaiblissement progressif dans le cas 1)

Que de questions, que de questions... mais cela n'est plus lié au modèle de conception extensible !

Je m'emporte, je m'emporte...

[hed62]

Effectivement, on s'éloigne du débat initial...

Toutes ces questions sont très interressantes, et méritent réponses, mais pas ici (je te suggère d'ouvrir un post dans un endroit potentiellement adapté, comme IA) et de tenir au courant ceux qui ont participé.

Ici viendront les questions de conception, là bas iront les débats sur les agents et le système.

je suis sur un problème de conception sur lequel j'hésite un peu.

muahaha

[behess]

Ici viendront les questions de conception, là bas iront les débats sur les agents et le système.

Je suis d'accord.

je suis sur un problème de conception sur lequel j'hésite un peu.

muahaha

Oui bah effectivement, c'est un petit euphémisme (et ici une mise en abîme ).

[behess]

En fait je vais chercher si des framework n'existent pas déjà, plutôt que de vraiment commencer à creuser plus profond.

article sur les systèmes multi agents

[behess]

Voilà j'ai créé un fil dans la section IA pour poursuivre cette discussion au niveau de la partie IA pure.

Ici je ne parlerais plus désormais que de conception pure.

[behess]

Voilà j'ai repris mon schéma et j'ai tenté de rajouter quelques petites choses dont on avait parlé.

Je n'ai pas remis les fabriques ni définit tous les attributs/getters/setters, on doit déjà pouvoir saisir l'architecture générale...

EDIT 08/05/08 : Nouvelle version du diagramme suite à la remarque de hed62

[hed62]

Observer et Observable devraient être reliés

[behess]

Exact, un petit oubli qui ne m'a pas sauté au yeux car ça me paraissait évident

Merci beaucoup !

Qu'en penses-tu ? As-tu d'autres suggestions ?

Je vais commencer à faire quelques scénario pour voir comment ça peut tourner.

[hed62]

Tu considère World comme un Agent (heritage?)

J'ai un peu de mal à apréhender le système de Place/linkedPlace. Ce sont les parcelles dont on parlait précédemment ?