Discussion :

[Air P-E]

Bonjour,

Je souhaite réaliser une appli qui est capable d'exécuter une suite de commandes sous forme d'arborescence suivant le contexte dans lequel je suis.
Pour faire plus simple, avec un exemple un peu banal mais qui a le mérite d'être clair :
Je souhaite :
- lancer une recherche sur mon poste pour trouver des fichiers musicaux
-- pouvoir renommer le deuxième fichier de la liste retournée précédemment si je le souhaite
-- ET/OU je souhaite ouvrir un lecteur pour lire la troisième piste des résultats retournés
--- En parallèle je veux peut-être lancer une recherche sur l'artiste que je suis en train d'écouter...
* Possiblement d'autres actions si je le souhaite...

J'ai commencé par mettre en place une solution avec le pattern commande étant donné que ça n'est que ça finalement. Seulement je ne sait pas trop comment exécuter une "sous-commande" dès lors que j'ai ma liste de résultats retournées.
Je ne suis pas certain d'être parti sur la bonne piste. J'ai également pensé au pattern Etat ou chaque Etat serait une action exécutée et me permettrait de passer à un état suivant, là encore je ne sais pas si c'est une bonne piste.
Sinon j'ai pensé au pattern chaine de responsabilité.

Bref, je ne sais pas trop sur quelle solution partir, sachant que je souhaite un code facilement évolutif pour pouvoir insérer des actions ou les modifier...
Que pensez-vous de mes propositions ? Quels sont les avantages et les inconvénients de chacun dans le temps ?
Avez-vous d'autres propositions ?

Merci par avance pour vos aides.

[theMonz31]

salut

moi, les patterns s'est pour les gens intelligents... et comme je suis un peu con..

Si j'avais à faire ce que tu essayes de faire (ou ce que j'en ai compris), j'aurais tendance à avoir une classe Action() qui aurait une action Fille et une méthode execute() retournant
un object et l'envoyant au suivant.

JE me demande si celà n'est pas le pattern "chain"... mais bon...

après, c'est à chaque action de savoir en quoi caster son entrée pour vérifier que le type est bon et que son action peut s'exécuter.

Moi, je le ferais comme ça...

(le pattern serait proche du "chain of responsibility" je crois).

[Air P-E]

Bonjour,

Merci de ta réponse.
L'idée que tu énonces ressemble à un début de mix entre le pattern Command et chaine de responsabilité.
Si j'ai bien compris, tu proposes une classe de base Action qui sera héritée par une classe fille ?

J'y vois des inconvénients, l'héritage, j'évite au maximum dans le sens ou on devient fortement couplé donc devient difficilement maintenable et testable. Précisément dans ce cas-là ma classe qui gérerait le renommage de mon fichier serait fortement couplée à ma classe de recherche, alors que ce n'est pas forcément lié.
De cette manière comment choisir si telle ou telle action doit être lancée ? Aussi de cette manière comment je gère le fait que mon appli attend une entrée utilisateur ? Il ne faudrait pas que tout le code s'exécute suivant une seule entrée utilisateur mais potentiellement une suite d'entrées utilisateur : "Lancer recherche" > "Renommer" , si je veux lancer le lecteur "lancer le lecteur" ou alors lancer directement la "recherche sur internet".

Pour le moment je suis resté sur mon implémentation avec le pattern Command car Etat était totalement une mauvaise idée étant donnée que chaque classe d'action devrait implémenter les autres action pour passer d'un état à un autre ce qui deviendrait très rapidement ingérable !
Le pattern chaîne de responsabilité ne convient pas forcément car je serai obligé d'effectuer plusieurs vérifications pour savoir si je dois lancer une action ou la suivante ou la suivante... Alors qu'on s'en fiche de ces actions !
Ou alors j'ai mal réfléchi à la question.

[theMonz31]

Pour moi, tu aurais une interface du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
interface IAction
    {
            void Execute(object obj);
            IAction NewAction;
    }

Après, tu n'as qu'à créer des classes X implémentant ton interface... et le tour est joué... ensuite, c'est juste au niveau de la création des classes qui font
le boulot que tu gères l'action... et dans ton éditeur, tu crées ton enchainement d'action en fonction de ton besoin...

Après, tu peux ajouter un type pour tes actions afin de savoir quelles actions sont autorisées à être enchainées avec une autre action...

[Air P-E]

A vrai dire je suis parti sur une solution similaire avec le pattern Commande.
J'ai une interface ICommand qui contient une méthode Executer(), par contre au lieu d'avoir une propriété ICommand pour déclarer ma future commande à exécuter j'ai à la place une méthode qui me permet de récupérer la liste des commandes possibles ensuite.
En effet au moment ou j'instancie ma classe qui implémente l'interface ICommand, je ne sais pas encore quelle est la commande suivante n'ayant pas encore eu le traitement d'effectuer ni la nouvelle entrée utilisateur, donc je ne peux pas définir ma future commande à exécuter. C'est au moment ou j'ai ma nouvelle entrée utilisateur que je récupère ma liste de commandes disponible.

Qu'en penses-tu ?

Je n'ai pas encore réussi à avoir quelque chose de fonctionnel. Je ne sais pas comment passer mes paramètres à ma nouvelle commande. C'est ma commande rechercher qui contient ma liste des commandes suivantes possibles mais lorsque j'instancie mes commande suivantes je n'ai pas moyen de récupérer mes paramètres à fournir. Je ne sais pas si je suis clair.

[theMonz31]

pas très clair mais je pense comprendre quand même...

Par défaut, une commande, si elle implémente une interface ne peut pas simplement avoir la liste des paramètres typés directement dans l'interface.

Ma méthode Executer(object obj) permet à une commande d'appeler une commande en passant comme argument un objet.

Bien sur, c'est la commande qui va s'exécuter qui saura quel doit être le type de l'objet qu'on lui passe en argument.

Du coup, il paraitrait logique d'ajouter un Get/set dans ta classe commande pour qu'un objet extérieur puisse récupérer l'objet élaborer (si il y en a un) dans une commande.

Après, c'est quoi la finalité du logiciel que tu veux faire et qui a ce besoin ?