Discussion :

[dahtah]

Bonjour à tous,
Je sais pas si je suis dans le bon forum, mais ça tient pas de la conception, plus de la POO...
Enfin bref, comment factoriser :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
méthodeA(String a) {
    switch (a) {
        case "a" :
           actionA();
        case "b" :
           actionB();
     }
}
 
méthodeB(String a) {
    switch (a) {
        case "a" :
           actionC();
        case "b" :
           actionD();
     }
}

Les méthodes A et B sont appelées quand des évènements se produisent (ajout, suppression).
J'aimerai factoriser le switch/case dans une méthode, car les valeurs de case sont les mêmes, mais les actions associées changent.
Qu'en pensez-vous? Merci.

[theMonz31]

salut

en utilisant la reflection ou bien en passant une liste de delegate tu pourrais
faire cela

The Monz, Toulouse

[hed62]

Je ne pense pas que cela soit jouable, parceque, en admettant que tu mette le switch dans une classe a part, tu devra refaire un switch selon l'appelant pour savoir quelle méthode appeler... je suis pas convaincu de la faisabilité. Un pattern t'aiderai ptet, mais lequel?..

Edit : comment ferais tu avec un delegate ?

[ced600]

Regarde du coté du design pattern d'état. La dernière fois que je me suis posé une question de ce genre, j'ai constaté que j'avais besoin de gérer les état de mon composant.

[theMonz31]

salut

comment faire avec un delegate , beh, je dirais que tu pourrais faire
un truc du genre :

void MASwitchMachine(Dictionnary<string,delegate>)

et ensuite, suivant le switch appelé le delegate associé à la clé de comparaison
faite dans le switch ?

C'est une idée... ya peut-etre des patterns qui evitent d'avoir à utiliser une telle
situation.... mais bon, on parlait d'une solution pour factoriser un switch, donc j'en "invente" une qui me semble pertinente.... en tout cas adapté suivant le contexte

The Monz, Toulouse

[hed62]

Le pattern etat peut etre en effet la solution.. Mais il risque de revoir la conception de son appli

ok pour theMonz, je ne voyai juste pas comment m'y prendre avec un delegate

[ced600]

Le pattern etat peut etre en effet la solution.. Mais il risque de revoir la conception de son appli

C'est ce qui c'est passé pour moi il y a peu de temps .
1/2 journée (donc 3 heures max ) pour un composant de 1000 de code. Ca va pas très long

[dahtah]

Merci à tous de vos réponses...

void MASwitchMachine(Dictionnary<string,delegate>)

ça semble une solution interessante...
Je vais me pencher du côté du pattern Etat.
Juste pour voir si ça colerai :
Dans une IHM, l'utilisateur déssine des réseaux et des machines associés. En fait, mes switchs correspondent à des évènements (glissé/déposé d'une nouvelle machine, suppression, connexion, déconnexion...).
La forme est associée à une chaîne de caractère générée par Visio (c'est la string a). Je dois savoir de qu'elle string il s'agit pour gérer les évènements sur l'objet correspondant (actionA).
Le pattern état corrspondrai (en très gros) à définir plusieurs états pour une machine ou réseau tels que (crée, supprimée, connectée...), synchronisés sur les évènements utilisateurs? C'est ça?
Dernière question, est-ce compatible avec MVC (j'ai déjà l'architecture en place)? D'ailleurs, un grand merci à Baptiste Witch pour son excellent tutoriel...

[dahtah]

un lien illustrant parfaitement mon problème.
Si quelqu'un à un bon tutoriel, je serai tout fou.
Merci encore.

[ced600]

oui et oui

En gros l'exemple utilisé, pour enseigner le pattern d'état aux futurs ingénieurs, c'est la machine à café.
Une machine peut se trouver dans les états :
En cours d'initialisation.
En attente d'utilisation.
En cours d'utilisation.
En panne -> Etat panique de l'informaticien dans ce cas.
En cours de dépannage. -> Merci au technicien, surtout s'il file un café gratos

Le pattern d'état est tout à fait compatible avec le modèle MVC, puisqu'il concerne un composant et non l'enssemble du programme.
Il est souvent utilisé sur le controleur du modèle MVC.
Concrétement, ce controleur définit un ensemble de méthode qui ne feront qu'appeler les méthode d'une classe abstraite. Tes différents états sont des classes qui héritent de la classe abstraite. Donc elles définissent tous les méthodes appelés par le controleur.
Tes crées les différentes instances de tes classes états.
Tu regroupes les pointeurs de ces instance dans un même conteneur et tu définit une variable comme étant l'état courant (elle pointe sur l'une des valeurs du conteneur).
Ensuite il faut t'assurer de possèder une méthode change état. Elle a pour bout de redéfinir l'état courant à chaque fois qu'elle est appelé.

[dahtah]

En fait après avoir lu ça et ça je suis pas sur que ça corresponde à mon problème. Par exemple, lorsqu'une machine est reliée à une autre, son comportement ne change pas, seule ses prorpiétés changent.
En fait si, en écrivant ça, ça à l'air de correspondre... .
En tout cas la mise en place à pas l'air trop compliquée, même si mon implémentation sera faite au niveau du modèle je pense. Mais le pattern sera géré via le controleur (les évènements).
Merci beaucoup ced600, .
Mon soucis était plus de conception que de code (comme souvent), mais bon, j'apprend .

[ced600]

Deux tutoriels pour le design pattern etat :
http://smeric.developpez.com/java/uml/etat/
http://pcaboche.developpez.com/artic...patterns/etat/

[ced600]

Pour une exemple le premier est peut être trop compliqué, mais bon enfin quand on connais déjà ça va
Le deuxième je le connaissais mais il ne me plaisait pas. Enfin j'ai refait le miens en gérant tout cela par les délégués et les événements. Je ne sais pas s'il est tout à fait conforme au design pattern mais il marche et je gère facilement les états.

[hed62]

Il n'est pas forcément utile de coller parfaitement à un design pattern. Le but premier d'un design pattern n'est surtout pas de proposer un standard, c'est avant tout de proposer une solution élégante, correcte, robuste et évolutive à un problème fréquemment posé. Ensuite il est nécessaire de l'adapter à son propre cas. Mais comme la majorité des cas se déroulent sans réelle adaptation, on considère parfois les design pattern comme des solutions à "faire entrer" dans la conception.
Toutefois un des autres but est d'instauter un vocabulaire et une base commune : il ne faut pas prendre un pattern, le chambouler et toujours l'appeler "pattern X".