Discussion :

[Tijee]

Bonjour à tous !

Je fais actuellement face à un dilemne que je m'empresse de vous soumettre :

Dans une fonction d'une de mes classes métier, je dois faire intervenir plusieurs fois l'utilisateur pour un choix que je souhaite traduire par une popup...

Le hic : pour l'instant je m'efforce de séparer IHM et métier dans mon application, donc hors de question de faire appel à l'interface graphique pour la popup dans ma classe métier. Difficile également d'appeler ma fonction métier en plusieurs fois depuis mon interface graphique car c'est un algo complexe. J'ai aussi pensé à une classe intermédiaire de style controleur, mais l'algo me semble avoir sa place dans la partie métier et pas ailleurs...

J'espère avoir été suffisamment clair. Quelle démarche me conseillez-vous ?

[millie]

Dans une fonction d'une de mes classes métier, je dois faire intervenir plusieurs fois l'utilisateur pour un choix que je souhaite traduire par une popup...

Quel type de choix ? Je ne vois pas vraiment le problème. Utilises-tu un pattern MVC pour développer ton application ?

Pourquoi ne pas laisser l'utilisateur tout choisir d'un coup ? Est-ce un formulaire sur plusieurs pages ?

[Tijee]

Deja non, je n'utilise pas un pattern MVC car c'est une petite appli.

Je détaille mon problème... Exemple :

L'utilisateur ajoute une tache qui a pour échéance une date donnée via un formulaire, clique sur OK => l'évènement appelle la méthode addTask() de ma classe métier. S'ensuit un algo qui calcule si la tache peut etre ajoutée avant la date d'échéance. Si ce n'est pas le cas, une popup doit s'afficher qui demande à l'utilisateur si il veut abandonner ou forcer l'ajout.

Et ce n'est qu'un des cas possibles... J'ai d'abord pensé à faire retourner un code d'erreur pour le traiter dans l'IHM puis rappeler la fonction, mais ça oblige à séparer l'algo en plusieurs parties et ce n'est pas possible...

[Gweanel]

La première solution est soit de renvoyer un code erreur ou de lever une exception. Ce qui t'obliges effectivement à décomposer ton code métier. Maiis est ce vraiment mal ? une étape de controle et une étape de traitement.

une autre solution consiste à faire executer une méthode d'ihm à la couche métier. Mais bien sur il faut faire ça proprement, et cela n'est possible que si tout le code se déroule sur la même machine.
Il s'agit simplement de définir une événement dans la couche métier auquel tu vas affecter un gestionnaire de la couche ihm qui peut retourner dans un paramètre (passé en référence) un code de retour pour demander à la couche métier de continuer ou d'abaondonner son traitement.
exemple de signature OnErreurCtrl(object sender, ref bool codeRetour)

[Tijee]

Merci pour ta réponse Gweanel !

La première solution ne m'enchante pas du tout, quant à la seconde elle me plait déjà plus, j'avais pensé à quelque chose comme ça mais ça rend quand même la couche métier un peu dépendante de la couche IHM... Mais je suppose que je n'ai pas le choix et je préfère ça à décomposer mon code pour l'appeler depuis l'IHM ou un controleur...

[souviron34]

moi je dirais :

ihm = INTERFACE vers couche métier

Donc :

Métier :

• Créer tâche -> évènement associé tâche créée
• Modifier tâche -> évènement associé tâche modifiée
• Détruire tâche -> évènement associé tâche détruite

Donc IHM :

• Créer tâche
• Modifier tâche
• Détruire tâche
• Avertissement tâche détruite (éventuellement auto : ton problème)

[Tijee]

C'est ce que je fais mais mon problème c'est que Ajouter tâche =
1- première étape
2- choix utilisateur
3- si choix = choix 1 alors deuxième étape
si choix = choix 2 alors troisième étape
4- 2e choix utilisateur
5- si choix = choix 3 alors etc....
etc...

Mon problème c'est que dans le métier je dois faire intervenir l'IHM pour capter les choix utilisateurs qui doivent intervenir à ces moments là...

[souviron34]

c'est qu'alors l'algo est incorrect

et que la vérification choix1 ou 2 est une fonctionalité métier "indépendante de l'objet, ou alors une propriété "validité"..

Pourquoi pas une méthode "Validité" ( choix ).... ?

Je pense purement et simplement qu'il faut remettre à plat ton analyse...

Imagine que tu fasses appel à un menu déroulant et non pas à une interface graphique .. Que ferais-tu ?

[Tijee]

Pour moi mon analyse est correct dans le sens où je pense que c'est au métier de dérouler l'algo et pas à l'IHM...

En revanche je suis d'accord sur le fait que le choix de l'utilisateur doit certainement être fait par un appel à une fonction de l'IHM... C'est ce qui m'embête un peu dans le sens où j'aurais aimé éviter que le métier fasse appel à l'IHM.

En fait mon problème est simple et se généralise à n'importe quelle appli : on a une fonctionnalité métier qui nécessite éventuellement des interventions de l'utilisateur au cours de l'algo (je veux dire par là que ce n'est pas du au clic sur un bouton, ou n'importe quel autre évènement déclenché par l'interface. Dans mon cas le choix est du à l'algo métier) : comment séparer le plus intelligemment possible métier et IHM ?

[souviron34]

Alors admettons le processus suivant :

Couche métier : Algo

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
Tant que Flag est vrai

   Vérification Choix 1
   Si vrai 
          opération 1
   Fin si

   Vérification Choix 2
   Si Vrai
          opération 2
   Fin si

...
   Corps algo
...
Fin Tant que

Couche IHM

Déclenchement algo

Mise Flag Choix 1

..... ( -> algo s'exécute en tenant compte de ce choix )


Mise Flag Choix 2

..... ( -> ............................................................. )

etc....


jusqu'à Mise Fin boucle infinie métier..

[trolldom]

Salut,
Il me semble ton problème est un probleme d'état (State) et que le patron State (GoF) peut être adapté à ton cas.
une bonne doc en plus de Google (avec GoF state): http://www.ibm.com/developerworks/ra...y/may06/krebs/)
Ton algoritme peut être reduit à une séquence de changement d'état, où un action de l'utilisateur déclenche une transition.
Dans l'UI tu as seulement un objet métier à qui tu envoie des messages.
Exemple avec un choix (screenshot):
etat initial: choix 1
choix 1 peut aller à choix 2 ou 3
choix 2 peut aller à choix 1 ou 3
choix 3 c'est finit, peut aller nullepart :-)
La classe choix se contente de gérer son état et d'envoyer les commandes à son objet State
En java ca peux ressembler à (lien vers le projet à la fin):

Code java :

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
19
20
21
 
public class Choix {
    List<String> parametreListe; // faineant: laisse visibilité package
    String nom;
    String selectedParam;
    IChoixState state;
    /** Creates a new instance of Choix */
    public Choix() {
        if (state == null)
            state = new Choix1State(this); //etat initial de la sequence de choix
    }
    public void moveOn(){
        state.MoveNext(this);
    }
    public boolean isOkToMove() {
      return  state.isOkToMove(this);
    }
    public boolean isFinit() {
    return state.isFinit(this);    
    }
 }

Assez simple non , tu peux remarquer que le constructeur choisit son état initial.
du coup l'UI est facile a développer vu que tu as juste à t'occuper d'un objet Choix.
Par exemple un click sur le bouton peut être alors:

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 private void jButton1ActionPerformed(java.awt.event.ActionEvent evt)
         {NextChoixRequest();}
 private void NextChoixRequest() {
        if (currentChoix.isOkToMove()) {
            currentChoix.moveOn();
            if(currentChoix.isFinit())
                showFinitView();
            else
                DoDataBinding();
        } else
            showAlert();
    }

Là c'est un rôle de controlleur, ca manipule le métier et choisit la vue en fontion du métier. tom objet métier a juste besoin d'implementer les métode qui vont bien.
Donc qui fait le boulot? et bien ce sont des classes "state" qui implémentent l'interface IChoixState

Code java :

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

1
2
3
4
5
6
 
public interface IChoixState {
    public void MoveNext(Choix c);
    public boolean isOkToMove(Choix c);
    public boolean isFinit(Choix c);
}

tu as alors une classe concrète par état (d'où l'intérêt de faire un petit dessin)
par exemple

Code java :

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
public class Choix1State implements IChoixState {
 
    /** Creates a new instance of Choix1State */
    public Choix1State(Choix c) {
        setInitialValueForThisState(c); 
    }
 
    private void setInitialValueForThisState(final Choix c) {
        List<String> paramListe = new ArrayList<String>(3);
        paramListe.add("goto 2");
        paramListe.add("goto 3");
        paramListe.add("no go");
        c.nom = "Choix initial";
        c.parametreListe =  paramListe;
        c.selectedParam = "goto 2"; //default
    }
 
    public void MoveNext(Choix c) {
        if (c.selectedParam == "goto 2") {
            c.state = new Choix2State(c); //il y a moyen de faire plus propre mais bon
            return;
        }
                if (c.selectedParam == "goto 3") {
            c.state = new Choix3State(c);
            return;
        }
 
    }
 
    public boolean isOkToMove(Choix c) {
        boolean nextIs2 = c.selectedParam.equalsIgnoreCase("goto 2");
        boolean nextIs3 = c.selectedParam.equalsIgnoreCase("goto 3");
        return (nextIs2 || nextIs3);
    }
 
    public boolean isFinit(Choix c) {
        return false;
    }
}

l'intéret est que:
1> il y a moins de branchement conditionnel vu que chaque classe ne s'occupe que d'un seul état
2> il est enfantin d'ajouter des états supplémentaire après coup.

voilà j'espère que ca t'aidera, en tous cas c'était un bon exercice pour moi... surtout l'UI en java (en trichant honteusement avec le generateur de netbeans)

code source (ZIP du projet netbeans)

Dom

[Tijee]

Salut trolldom et merci beaucoup pour ta réponse !

Je fouillais depuis plusieurs jours dans les patterns pour trouver chaussure à mon pied mais tu viens de m'y enlever l'épine (du pied ).

Maintenant que tu en parles, je pense effectivement qu'un pattern State est le bienvenu, même si mon problème est un poil plus complexe que ça... En tout cas c'est dans l'idée et c'est le principal !

En tout cas merci d'y avoir réfléchi à ce point !!!

Je vais essayer de peaufiner tout ça pour que ça corresponde à mon algo... Dev must go on !

[trolldom]

Salut,
Je viens en fait d'utiliser le pattern State dans l'appli sur laquelle je travaille. Ce n'est pas exactement le même problème que toi vu que je n'ai pas besoin d'input de l'utilisateur mais je voulais montrer la progression d'une tache de fond complexe à l'utilisateur (je gère les résolutions de conflits automatiquement mais il est pas impossible qu'il soit demandé plus tard que l'utilisateur puisse le faire lui même).
Je trouve que ca fonctionne bien vu que chaque etappe du traitement se concentre sur son boulot et rien d'autre.
Dom
le pire c'est que j'ai du m'aidé de mon post en java pour écrire mon programme en dotnet

[Tijee]

Comme quoi !

En tout cas c'est un pattern très utile ! Je t'avoue que mon problème est plus compliqué que ce que j'ai résumé donc son application n'est pas évidente que ça mais je vais avoir à l'utiliser quand même...