Discussion :

[chris_wafer_2001]

Bonjour,

Je souhaiterais faire un petit soft avec une IHM en MFC.
Néanmoins, j'aimerais complètement séparé l'IHM et le traitement qui est fait derrière.
Comment vous feriez les choses?

[farscape]

salut,
Avec des classes "metiers" utilisées dans les classes liées a l'IHM.
de maniere general tu vas rencontré le probleme de traitement des données issues de l'ihm dans ta classe de traitement .
le probleme risque d'etre plus delicat encore avec des controles comme des ListBox ou ListCtrl vu qu'il peut y avoir interaction forte entre les classes de traitement et l'ihm.

[chris_wafer_2001]

C'est-à-dire "métiers"???

Tu aurais pas un exemple?

[farscape]

"metier" dans le sens classe de traitement qui ne traite que son sujet specialisé.

[r0d]

Salut,

le problème que tu poses ici, je me le suis posé maintes fois. En effet, lorsque l'interface graphique est un peu complexe, je pense qu'il est préférable de bien séparer l'IHM du "corps" du programme.

Cependant, il s'agit là d'un problème de conception. Ma courte expérience dans le domaine m'a amené à concevoir une interface (classe abstraite) qui implémente toute les fonctionnalité dont j'aurais besoin dans mon IHM. Ainsi, la classe qui implémente la partie graphique de mon IHM contiendra une instance de cette interface.

Par ex.

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
 
class IMonInterface
{
[...]
public:
[...]
   virtual int CalculeTaux(int iNb1, int iNb2, int iRange); //là j'ai mis la méthode en virtual, mais dans cet exemple, il ne faudrait pas
[...]
};
 
 
class CMonIHMDlg
{
[...]
CEdit m_edit1, m_edit2, m_edit3;
CButton m_button1;
[...]
IMonInterface m_monInterface;
 
public:
Button1OnClick(...);
};
 
void Button1OnClick(...)
{
   CString strBuf;
   m_edit1.GetWindowText(strBuf);
   int i1 = aoti (strBuf);
   m_edit2.GetWindowText(strBuf);
   int i2 = aoti (strBuf);
   m_edit3.GetWindowText(strBuf);
   int iRange = aoti (strBuf);
 
   int iTaux = m_monInterface.CalculeTaux(i1, i2, iRange);
//etc...
}

Cette façon de procéder comporte les avantages suivants:
* Modularité: si tu change l'IHM, tu n'as pas besoin de toucher au code du "corps" du programme. Les modifications effectuées sur l'une ou l'autre des parties n'induisent pas forcément des modifications sur l'autre partie.
* Clarté: en séparant ainsi l'application, le code est plus clair, donc plus facile à débugger, à améliorer, à maintenir.

Inconvénients:
* Rigueur dans la conception: cette façon de procéder, qui me semble classique dans une approche objet, nécessite un effort minimum de conception.
* Risque de prolifération de classes: idem, c'est classique en dev objet. Attention à ne pas se laisser aller à implémenter trop de classes inutiles.

Voilà. Ceci est issu de mon expérience personnelle, qui n'est pas très étoffée j'en conviens. J'espère donc que les forumeurs plus expérimentés corrigerons mes erreurs

[farscape]

salut,l'exemple de r0d (merci ) illustre ce que je disais :la difficulté de la liaison entre l'ihm et la classe metier .

on voit bien que dans son exemple il est obliger de recuperer les données
puis de les passer en argument a la fonction de l'objet de traitement...
c'est ce coté qui est delicat à gérer et encore plus problematique avec des objets comme des clistctrl ou listbox.

apres c'est un choix : pourquoi bien séparer les traitements ?
portage sur une autre plateforme ? ok .
Uniquement MFC ? alors attention de ne pas compliquer le code à outrance en partant d'une bonne intention...

[la drogue c'est mal]

c'est ce coté qui est delicat à gérer et encore plus problematique avec des objets comme des clistctrl ou listbox.

une CListCtrl ou une CListBox n'est rien d'autre qu'une liste d'objet metier



ce que tu recherches à faire c'est la mise en application d'une architecture MVC (Modele Vue/ Controleur).

pour cela, il faut distinguer 3 gros "composants" :

la vue : l'interface homme/machine (sert à afficher, recuperer et controler les données )

le controleur : les traitement de donnée (sert à faire des calculs, requetes en base de donnée etc...)

l'objet métier : le lien entre les 2 autres (classe relativement simple, reprenant les variables à afficher + accesseurs sur ses variables (getter et setter. On peut lui attribuer des traitements simple mais c'est deconseillé car ce qui est simple aujourd'hui ne se sera pas forcement demain)

la vue sert à afficher les données et déclanche des actions (ou évenements) vers le controleur

le controleur effectue un traitement en fonction des actions et met à jour (ou renvoie) un objet metier correspondant au nouvelles données à afficher

la vue affiche la mise à jour

Annexe : lorsque tu as une IHM complexe, on peut mettre en place un controleur unique d'une l'ihm qui va "rooter" vers des controleurs metiers

pour reprendre l'exemple de "r0d" j'aurais plus fait :

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
42
43
44
45
46
47
48
49
50
51
52
53
 
 
// Objet Metier
class CDonneeTaux
{
private :
int m_nJour;
float m_fTauxActuariel;
float m_fValeurActuel;
float m_fValeurFutur;
etc...
public :
CDonneeTaux()
{
// init des variables
}
float GetTauxActuariel()  { return fTauxActuariel;}
voif SetTauxActuariel(float fTaux)  { fTauxActuariel=fTaux;}
 
// etc...
};
 
// Controleur
CCalculTaux()
{
public:
void TauxActuariel(CDonneeTaux& donnee);
{
}
 
};
 
 
// Vue
class CMonIHMDlg 
{
void Button1OnClick(...)
{
// l'ihm met à jour un objet metier pour un traitement
CDonneeTaux donnee;
donnee.SetNbJour(...);
donnee.SetValeurActuel(...);
....
 
// le controleur réalise le traitement et renvoie une donnée à jour
CCalculTaux Caculateur;
Caculateur.TauxActuariel(donnee);
 
// l'ihm met à jour la nouvelle donnée
// mise à jour de l'ihm avec donnee.GetTauxActuariel();
 
}
};