Discussion :

[Aïssa]

Bonjour,

Voilà, j'ai une application qui utilise énormement de DataGridView et de Form, chaque Form possède au minimum un datagridView,et comme vous vous en doutez des opérations qui se répétent. C'est toujours la même histoire , opération pour se connecter à la base, pour remplir le DataSet, opération pour configurer le datagridview etc...
Il est vrai que ces opérations rendent mes Forms extrement longues et complexes, je suis d'accord pour dire qu'il y a un problème de conception et qu'il faut externaliser certaines opérations comme citées ci-dessus...
Alors j'avais pensé au DP Stratégie, on a une classe on va dire dans mon cas cela sera ma Form et on lui passe en argument l'interface de ma stratégie, donc on pourra passer en paramètre toutes les classes qui configure mes dataGridView et qui implément l'interface stratégie...

Qu'en pensez vous chers Architectes????

Merci d'avance pour tous vos conseils...

[pseudocode]

Ca serait pas plutot le "DP Builder" pour ton exemple de Forms ?

Apres tu pourras optimiser en créant une abstract factory de Builder.
Puis encore plus optimiser en utilisant des strategies dans l'abstract factory.

Et puis apres, tu découvres que tu viens de recoder un framework de présentation

[Aïssa]

Tu veux va dire que j'exagère, mais pourquoi le DP Builder??? et comment l'utiliser??

[pseudocode]

Tu veux va dire que j'exagère, mais pourquoi le DP Builder???

Pour pouvoir reutiliser ton code récurrent de remplissage et de configuration

et comment l'utiliser??

un truc du genre

Code :

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

1
2
3
4
5
6
7
8
9
Form form = new MonFormA();
DataSet ds = new MonDataSet1();

FormBuilder fb = new FormBuilder( form );
fb.configureGrid( bla_bla_bla );
fb.fillGrid( ds );

form.show();

[Aïssa]

Et si je faisais :

Code :

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

1
2
Form SaisieDevis = new SaisieDevis( new maStrategie() );

et dans le code de la Form Saisie Devis :

Code :

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

1
2
3
4
5
6
7
8
9
DataSet ds;
DataGridView dgv;
// Constructeur de la fenetre
public void SaisieDevis(Stategie strg)
{
   strg.Init( dgv, ds);
   strg.Configure(dgv);
}

qu'en penses tu???

[pseudocode]

Bah j'en pense que c'est pareil. Ce que j'ai appelé "fb" tu l'as appelé "strg". Donc en fait, c'est un Builder.

Sauf qu'en plus, tu le passes en parametre du constructeur de ta classe. Donc tu l'utilises comme une strategie. Sans doute pour pouvoir changer le contenu ou l'apparence de ta grille sans modifier le code "metier" de SaisieDevis. c'est ca ?

[Aïssa]

oui...Mon but principal est de découpler au maximun et d'externaliser certaines opération afin de rendre mon code plus lisible et compréhensible ...

Si ma mémoire est bonne le DP builder doit à la fin rendre un objet, or dans mon contexte ce n'est pas le cas...

A moins que j'utilise le builder pour construire une form???

J'ajoute aussi qu'en genéral le DataSet est une variable locale à la form...

[pseudocode]

oui...Mon but principal est de découpler au maximun et d'externaliser certaines opération afin de rendre mon code plus lisible et compréhensible ...

Cette technique va te permettre d'externaliser (donc de rendre plus lisible) , mais ca ne découple pas grand chose: SaisieDevis utilise Strategie qui utilise DataSet et DataGrid qui sont contenus dans SaisieDevis. Je dirais meme que c'est du sur-couplage !

Si ma mémoire est bonne le DP builder doit à la fin rendre un objet, or dans mon contexte ce n'est pas le cas...

Heu, non je crois pas. Le builder est juste un objet qui permet de construire simplement (au sens manipuler) un (ou des) autre objet.

A moins que j'utilise le builder pour construire une form???
J'ajoute aussi qu'en genéral le DataSet est une variable locale à la form...

Bah, perso je trouverais ca plus propre. Comme ca ta Strategie n'a pas a connaitre la Form. Il faut juste pouvoir récupérer les DataSet et DataGridView (getters).

Code :

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

1
2
3
4
5
6
7
8
9
10
Form saisieDevis = new SaisieDevis();

DataSet ds = saisieDevis.getDataSet();
DataGridView dgv = saisieDevis.DataGridView();
Stategie strg = new maStrategie();
strg.Init( dgv, ds );
strg.Configure( dgv );

saisieDevis.show();

[Aïssa]

Cette technique va te permettre d'externaliser (donc de rendre plus lisible) , mais ca ne découple pas grand chose: SaisieDevis utilise Strategie qui utilise DataSet et DataGrid qui sont contenus dans SaisieDevis. Je dirais meme que c'est du sur-couplage !

Désolé mais je ne compends pas, pourquoi dis tu que c'est du sur-couplage, puisque je peux changer ma stratégie comme je le souhaite, c'est le principe même du DP stratégie...Si demain mes opérations venaient à changer la form n'en serait pas affecté.

Bah, perso je trouverais ca plus propre. Comme ca ta Strategie n'a pas a connaitre la Form. Il faut juste pouvoir récupérer les DataSet et DataGridView (getters).

Code :

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

1
2
3
4
5
6
7
8
Form saisieDevis = new SaisieDevis();
DataSet ds = saisieDevis.getDataSet();
DataGridView dgv = saisieDevis.DataGridView();
Stategie strg = new maStrategie();
strg.Init( dgv, ds );
strg.Configure( dgv );
saisieDevis.show();

Ce n'est pas pour t'embêter ou juste pour polémiquer, mais peux tu me dire quels sont les avantages de ton code?? je sais je suis chiant
Merci

[pseudocode]

Désolé mais je ne compends pas, pourquoi dis tu que c'est du sur-couplage, puisque je peux changer ma stratégie comme je le souhaite, c'est le principe même du DP stratégie...Si demain mes opérations venaient à changer la form n'en serait pas affecté.

C'est couplé dans le sens "a besoin de connaitre". Si tu changes le nom d'une methode dans ton interface Strategie, il faut repasser dans toutes les Form pour propager les modifs.

Ce n'est pas pour t'embêter ou juste pour polémiquer, mais peux tu me dire quels sont les avantages de ton code?? je sais je suis chiant
Merci

L'avantage de mon code, c'est que:
1. La Form n'est pas au courant de l'existance des strategies
2. corolaire: je ne suis pas forcé de créer des builders qui ont la meme interface (Strategie)

je peux donc faire ca:

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
Form saisieDevis = new SaisieDevis();

DataSet ds = saisieDevis.getDataSet();
DataGridView dgv = saisieDevis.DataGridView();

/*
Stategie strg = new maStrategie();
strg.Init( dgv, ds );
strg.Configure( dgv );
*/

if (ds.size()<100) {
  new SimpleDataGridBuilder(dgv).injectAllData(ds);
} else {
  new MultiplePageDataGridBuilder(dgv,100).injectFirstData(ds,0);
}

saisieDevis.show();

Enfin, bon, ce n'est que mon avis. On fait comme on veux

[Aïssa]

C'est couplé dans le sens "a besoin de connaitre". Si tu changes le nom d'une methode dans ton interface Strategie, il faut repasser dans toutes les Form pour propager les modifs.

Je suis d'accord avec toi, mais si je suis tout raisonnement, cela voudrait dire qu'il ne faut jamais passer un objet en paramètre de peur qu'il y ait un couplage mais cela est un autre débat
Ce qui me gêne un peu, dans l'histoire des accesseurs, c'est que cela entrave un peu le principe de la boite noire et de l'encapsulation, non???

Code :

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

1
2
3
DataSet ds = saisieDevis.getDataSet();
DataGridView dgv = saisieDevis.DataGridView();

L'avantage de mon code, c'est que:
1. La Form n'est pas au courant de l'existance des strategies
2. corolaire: je ne suis pas forcé de créer des builders qui ont la meme interface (Strategie)

J'avoue que c'est vrai et que cette idée me plait bien...
Mais c'est quoi comme DP???? le builder????

Maintenant supposons comme tu dis, que l'on considère un builder et que ce dernier construit par étape un objet complexe une Form...
On sait qu'il y a une multitude de form, chacune ayant une manière bien précise de configurer ses datagridView...
Tu utilises une fabrique abstraite pour construire tous tes builder???

Merci de tes conseils ou de vos conseils si qq souhaiterait s'inviter à notre conversation...

[pseudocode]

Je suis d'accord avec toi, mais si je suis tout raisonnement, cela voudrait dire qu'il ne faut jamais passer un objet en paramètre de peur qu'il y ait un couplage mais cela est un autre débat

Lol. Oui c'est vrai... mais ne sombrons pas dans la paranoia

Je passe en parametres du constucteur les objets dont une classe a VRAIMENT besoin, au sens "metier". Ici, la Form n'a pas besoin du builder, car il n'apporte pas "d'informations" indispensables a la Form.

Ce qui me gêne un peu, dans l'histoire des accesseurs, c'est que cela entrave un peu le principe de la boite noire et de l'encapsulation, non???

Oui, c'est vrai qu'il faut faire attention car des objets "mal-intentionnés" pourraient venir modifier ton DataSet ou ton DataGrid . Si c'est un probleme, tu peux toujour creer et utiliser le builder dans le constructeur de ta Form. Mais bon, on recouple la Form et le Builder. Il faut trouver le juste equilibre entre Decouplage et Encapsulation.

Tu utilises une fabrique abstraite pour construire tous tes builder???

Oui, c'est le plus propre. Tu passes juste un parametre a la factory pour lui indiquer le type de builder que tu veux, et elle te renvoie une interface de builder. La contrainte etant de trouver une interface commune a tous les builder

[Aïssa]

Me revoila

Aprés maintes réflexion, je dois avouer que tu as raison, le pattern Builder (Monteur) est bien plus adapté à mon problème. En effet, le pattern stategy ne représente qu'une méthode virtuelle qui est redéfini selon le besoin, or dans mon cas je souhaite construire une form constituée de plusieurs objets et qui necessite dans sa construction plusieurs étapes...
De plus on n'a pas besoin de passer le monteur dans le produit que l'on souhaite construire...
On construit le produit à l'aide du monteur et on le retourne au client il ne me reste plus qu'a coder maintenant...

Je crois que j'ai bien compris la leçon???

[pseudocode]

---> <---

[Aïssa]

Dis moi si je ne me fourvoie pas quelque part ...

J'ai créé mon Builder

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
54
55
56
57
58
59
60
61
using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;
using System.Data;
using Devis;

namespace MesMonteur
{
   public class MonteurSaisieDevis : Monteur, IDisposable
    {
       Form fenetreSaisieDevis = null;
        #region constructeur
        public MonteurSaisieDevis()
        {
        }
        #endregion
        #region Méthodes du monteur
       public override void CreeFenetre()
       {
           fenetreSaisieDevis = FSaisieDevis.GetInstanceFSaisieDevis();
       }

       public override void SetParent(Form parent)
       {
           fenetreSaisieDevis.MdiParent = parent;
       }
        public override void ConfigDgv()
        {

        }

        public override void FillDs()
        {

        }

       public override Form RecupereFenetre()
       {
           return fenetreSaisieDevis;
       }

       public override void AjoutControl(Control ctrl)
       {
           
           fenetreSaisieDevis.Controls.Add(ctrl);

       }
        #endregion
        #region IDisposable Membres

        public void Dispose()
        {
           
        }

        #endregion
     
    }
}

Ensuite je fais comme ça pour l'utiliser :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public void AbonneDevisEvent(object sender, EventArgs e)
        {
            
            Monteur TestMonteur = new MonteurSaisieDevis();
            TestMonteur.CreeFenetre();
            TestMonteur.SetParent(Parametre.ParentAllForm);
            TestMonteur.AjoutControl(new UserControlDetailDevis());
            TestMonteur.FillDs();
            TestMonteur.ConfigDgv();
            TestMonteur.RecupereFenetre().Show();

            
        }

qu'en penses tu????

[pseudocode]

Perso, je prefere quand le Monteur ne crée pas l'objet. J'ai pas confiance (), je sais pas quel constructeur il a utilisé.

Je prefere instancier moi meme l'objet et le passer en parametre du constructeur du monteur:

Code :

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

1
2
3
4
5
6
7
8
public class MonteurSaisieDevis : Monteur, IDisposable {
    Form fenetreSaisieDevis = null;
    public MonteurSaisieDevis(Form f) {
       this.fenetreSaisieDevis = f;
    }
    ...
}

Et apres utiliser le monteur comme tu l'as fait, sans la methode "CreeFenetre"

Code :

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

1
2
3
4
5
6
7
8
9
10
Form f = FSaisieDevis.GetInstanceFSaisieDevis();

Monteur TestMonteur = new MonteurSaisieDevis(f);
TestMonteur.SetParent(Parametre.ParentAllForm);
TestMonteur.AjoutControl(new UserControlDetailDevis());
TestMonteur.FillDs();
TestMonteur.ConfigDgv();

f.Show();

[Aïssa]

ok, merci pour les conseils ;-)

[Aïssa]

Bonjour tt le monde et spécialement pseudocode ;-)

Me revoila avec d'autres questions

Pour ceux qui n'ont pas suivi mon débat philosophique avec pseudoCode, je fais un petit rappel : Mon souci antérieur etait d'alléger le code et de réduire le couplage d'une windowForm contenant un datagridView, suite aux conseils de pseudocode j'ai opté pour le pattern Builder (Monteur pour les puristes).
J'ai donc créer mon builder qui construit étape par étape ma Form. Je la crée, ensuite je lui ajoute un user control qui contient le datagridView, je remplis le dataset etc...
Maintenant comme tous ceux qui on travaillé avec l'évenementiel, je dois répondre à certains clics de souris ....; j'avais donc opté pour un observateur afin d'éviter de trop charger ma form.
Par exemple si l'utilisateur fait un clic droit sur une ligne je veux ajouter automatiquement une ligne en dessous de cette dernière...Pensez vous que le Pattern Observateur soit une bonne idée???

Merci d'avance pour tous ceux qui se donneront la peine d'aider une âme en perdition

[pseudocode]

Re.

Tu ferais mieux de poster un nouveau sujet dans le forum Java, car la gestion evenementielle de Swing est vraiment particuliere... et donc necessite des patterns particuliers (SwingWorker et autres...)

[Aïssa]

Re.

Tu ferais mieux de poster un nouveau sujet dans le forum Java, car la gestion evenementielle de Swing est vraiment particuliere... et donc necessite des patterns particuliers (SwingWorker et autres...)

Je developpe en c# ...