Discussion :

[Muetdhiver]

Bonjour à tous.

J'ai fait une application dont le noyau et l'IHM sont fortement distincts. En gros le but est de ne pouvoir extraire que le noyau d'un côté, et le recompiler, de façon à le coupler à une autre IHM.
Pour le moment dans l'IHM en question j'appelle quand meme les interfaces de mon noyau, de façon à executer des ordres.

Le but est de n'introduire en aucun cas un objet IHM dans le noyau. (l'IHM est en wxWidget).
Ma question est la suivante :
Imaginons que le noyau doive effectuer une tache lourde, par exemple une boucle avec 100 itérations d'une longueur d'environ 5 secondes. Comme quasi toutes les applications dans ce bas monde, il faut signaler à l'utilisateur la progression par une barre d'avancement, ou progressBar, un objet spécifique à l'IHM... Donc, impossible d'introduire mon objet dans le noyau, en lui disant d'incrémenter graphiquement une petite barre (sur 100) à chaque tour de ma boucle. Par contre, impossible egalement, depuis l'IHM, d'effectuer la boucle de 100 itérations et, dans chaque boucle, d'appeler mes sous-fonctions métiers en plus de la mise a jour de la progress bar ? Genre ce traitement :

Pour i de 1 à ......
|
| Appel des méthodes noyau (découpées pour l'occasion)
| Appel des méthodes de l'IHM (progressBar)
|
Fin Pour

Qu'en pensez vous ? Comme c'est un pb récurrent, tout le monde a deja du se poser la question ? Je sais qu'il n'y a pas de méthode miracle, et comment faites vous, personnellement ?

Merci, a plus.
Alex.

[madfu]

Un moyen simple pour résoudre ce genre de problème est d'envoyer une notification à l'IHM à chaque changement d'état de ton noyau.

Les évènements (en fait des pointeurs sur procédure) sont très utiles pour réaliser ce genre de choses :
1- Tu déclenches les évènements dans tes objets métiers
2- Tu implémentes des gestionnaires d'évènements (handlers) dans ton IHM qui vont traiter ces évènements.

exemple en pseudo-code C#/delphi

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
//ton évènement
type ExecuteEvent = void (object param);

//ta classe métier
Class Noyau{
    //l'évenement en question
    ExecuteEvent Event;

    //Ta méthode métier
    public void execute(){
     i=0;
      while (i<=100){
         Actions();
         if (_execute!=null)
           _execute(this); 
         i++;
      }        
    }
}
class IHM{

  //ton objet métier
  Noyau noy;

  //le constructeur branche le gestionnaire d'évènement HandlerAction
  public IHM(){
    noy.Event = HandlerAction;
  }

  //ton gestionnaire d'évènement reçoit la notification et met à jour la  progressbar
  public void HandlerAction(){
    ProgressBar.Incrementer(1);
  }

  //ta méthode qui appelle l'objet métier
  void ExecuterAction(){
       noy.execute();	
  }

}

L'avantage c'est que ton objet métier reste finalement indépendant de ton IHM.

[Muetdhiver]

Ok, merci pour cette reponse, ca m'aide bien.

1) J'ai compris dans l'ensemble mais par rapport à ton code je ne comprends pas une ptite chose :

Ce code :

Code :

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

1
2
3
     if (_execute!=null)
           _execute(this);

Tu ne voulais pas mettre "Event" à la place, d'où l'objet membre de type ExecuteEvent enregistré depuis l'IHM (noy.Event = HandlerAction.

Et enfin, autre petite question :
2) Passer par des pointeurs de fonction comme ça est très judicieux. C'est un desing pattern ? Cette méthode porte un nom ?

Merci pour ton aide.
A+

[souviron34]

il y a beaucoup plus élégant, et qui est la façon de faire des "gros" outils graphiques (comme X par exemple, ou le principe même de l'appel des DLLs).

Tu fais un module indépendant ET de l'IHM ET du noyau, du style (en C) :

Code :

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

1
2
3
4
5
Enregistre_Fonction_Evenement ( int Type_Evenement, void *Fct )

Fonction_Existe_Pour_Evenement ( int Type_Evenement )

Appelle_Fonction_Evenement ( int Type_Evenement )

Et là, dans ton noyau, tu fais :

Code :

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

1
2
if ( Fonction_Existe_Pour_Evenement ( MISE_A_JOUR_TACHE ) )
    Appelle_Fonction_Evenement ( MISE_A_JOUR_TACHE ) ;

et dans ton IHM tu auras fait :

Code :

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

1
2
Enregistre_Fonction_Evenement ( MISE_A_JOUR_TACHE, (void *), 
                                &Fonction_Update_GUI );

où MISE_A_JOUR_TACHE est un entier (#define), par exemple....

Mais ce peut-être simplement DISPLAY_WORK_IN_PROGRESS, qui si il y a une IHM affichera ton échelle, si c'est en mode console affichera juste "work in progress..."...

L'important c'est que le noyau ne soit pas au courant de quel outil tu utilises pour l'IHM, et que par contre il prévoit tous les types d'événement qu'une IHM pourrait demander...

(c'est ce qui se passe avec n'importe quel outil de développement d'IHM (Delphi, VC++, Eclipse, X/Motif, etc...) quand tu places un bouton sur une fenêtre : tu as le choix de mettre des routines pour plusieurs types d'action (tu passes dessus (arm), tu cliques (OnClick), etc.. : le gestionnaire derrière à ce genre de routine :

Code :

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

1
2
if ( Existe_Fonction(Objet, ON_CLICK) )
    Appelle_Fonction ( Objet, ON_CLICK);

)



Note : en général, on ajoute un pointeur vers une structure comme paramètre, qui dans le module indépendant est void*, et qui dans le noyau ET dans l'IHM sera castée avec le bon type, afin de pouvoir se passer des paramètres...

Exemple :

Indépendant :

Code :

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

1
2
Enregistre_Fonction_Evenement ( int Type_Evenement, 
                                void *Fct, void *Data )

Noyau :

Code :

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

1
2
3
if ( Fonction_Existe_Pour_Evenement ( MISE_A_JOUR_TACHE ) )
    Appelle_Fonction_Evenement ( MISE_A_JOUR_TACHE, 
                                 (void *)&MaStructure );

IHM :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
static int Fonction_Update_GUI ( void *Data )
{
      MaStruct *pstruct = (MaStruct *)Data ;
...
}

.......

/* Quelque part dans le code au départ */

Enregistre_Fonction_Evenement ( MISE_A_JOUR_TACHE, (void *), 
                                &Fonction_Update_GUI );
...

[Muetdhiver]

Merci bcp pour cette réponse de laquelle je vais m'inspirer. C'est vrai que tout ça c'est bien pratique et interessant quand on se penche dessus.

A plus et encore merci d'avoir passé du temps pour me répondre.
++
Alex.

PS derniere question : cette methodologie est un design pattern ? Ca porte un nom ?

Merci.

[pseudocode]

PS derniere question : cette methodologie est un design pattern ? Ca porte un nom ?

Le paradigme s'appelle "event driven"
Le design pattern de souviron34 s'appelle "mediator".

A+

[souviron34]

Le paradigme s'appelle "event driven"
Le design pattern de souviron34 s'appelle "mediator".

A+

Merci.. Je suis comme Mr Jourdain.... Je pratiquais sans connaître le nom (ou la classe) attachée à ces concepts...

[pseudocode]

Merci.. Je suis comme Mr Jourdain.... Je pratiquais sans connaître le nom (ou la classe) attachée à ces concepts...

Les concepts existaient avant que le GoF ou Shaw & Garlan les baptisent.

Connaitre les noms de ces concepts n'a pas d'autre interet que de simplifier les explications... ou de se la péter sur les forums !

[Muetdhiver]

Les concepts existaient avant que le GoF ou Shaw & Garlan les baptisent.

Connaitre les noms de ces concepts n'a pas d'autre interet que de simplifier les explications... ou de se la péter sur les forums !

Lol !!! En tout cas merci les mecs.
A plus.
Alex.