Discussion :

[pot2yaourt]

Bonjour à tous,

Voilà, je bosse sur une appli Winform et j'essaye de faire les choses bien, du coup je sépare mon code au maximum pour que ce soit plus lisible et maintenable. Par contre, j'en viens à me demander s'il n'y a pas un problème de conception...

J'ai donc un fichier Form.cs (un seul écran) et d'autres fichiers .cs contenant mes classes... qui sont d'ailleurs, pour la plupart, des classes statiques renfermant soit des méthodes en tout genre soit des variables qui sont initialisées au chargement de l'application en lisant un App.config.

Voici donc un extrait de mes classes :

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 static class Tools
{
    public static void LoadConfig();
    public static void GetValue();
    public static ....();
}
 
public static class Common
{
    public static int[] myVar1;
    public static int[] myVar2;
    public static int[] myVar3;
}

Du coup, j'aurais quelques questions :

1°) Est-ce que l'utilisation de classes statiques est une bonne chose (la classe Common me permettant de stocker tout un tas de variables "globales" à l'application et la classe Tools de regrouper diverses méthodes sans pour autant que ce soit de la "vraie" programmation objet) ?

2°) Comment gérer les exceptions dans mes classes ? Si dans la classe Tools une Exception est levée lors de la lecture d'une valeur dans le App.config, actuellement voilà comment je procède (et j'imagine qu'il y a un truc qui cloche) :

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
 
public static class Tools
{
    public static void GetValue(xxx)
    {
        try { 
            //lecture de la valeur pour la clée xxx
        } catch(Exception ex) { throw new Exception(ex.Message); }
    }
}
 
//et dans le code de ma Form :
try {
    Toos.GetValue("toto");
} catch(Exception ex) { MessageBox.Show(ex.Message); }

3°) Depuis une classe Database (accès à la base et requétages) est-il possible et/ou judicieux d'accéder directement à un contrôle de ma Form ? Exemple d'un SELECT qui remplirait une ComboBox. Depuis la classe Database je n'arrive pas accéder directement aux contrôles de ma Form même s'ils sont en "Public". Je suis donc obligé de faire comme suit :

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
 
//code dans Database.cs 
public class Database
{
    public List<string> GetList()
    {
        List<string> liste = new List<string>();
        //requête du type: "SELECT nom FROM employes" qui remplit la liste
        return liste;
    }
}
 
// code dans Form.cs :
List<string> maListe = objDatabase.GetList();
//parcours de "maListe" pour remplissage du ComboBox

Voilà, je m'arrête là pour l'instant... si vous êtes arrivés jusque là c'est déjà pas mal !
Si vous avez un peu de temps pour me répondre ça serait cool !
Merci d'avance !
Lionel.

[clochettes]

Bonjour,
1/mettre toutes tes informations ou fonctions en static, ce n'est pas une très bonne idée. C'est un peu dévoyer l'orienté objet!
Rien ne t'empêche de créer une classe normal, de l'instancier au début de ton programme (éventuellement en chargeant un fichier de conf), puis de l'utiliser dans la suite de ton programme. Pas besoin de passer par du static pour cela. Si tu as besoin de ces éléments dans d'autres classes de ton programme, tu passes cette instance en paramètres.

2/Pour les exceptions, pourquoi ne renvois-tu pas un booléen depuis ta fonction de lecture qui indiquerais si la fonction a réussi?

Code :

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

1
2
3
4
5
6
public bool lecture
{
    try {//fonction de lecture}
    catch{ return false;}
    return true;
}

et dans l'appel

Code :

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

1
2
if(!lec.lecture())
    MessageBox.Show("Erreur de lecture");

3/Et non, ce n'est pas très propre d'aller modifier tes controls directement depuis une autre classe. La solution que tu indiques est bien meilleurs!

[oyigit]

1/ Les classes statiques ont leur utilité. Ils sont normalement là pour stocker une information, un comportement identique à toutes les instances de l'application en cours. A toi d'évaluer si un élément est statique, quel que soit l'occurence de l'application en cours.

2/ Petite précision pour les exceptions --> Rien ne sert de catcher l'exception, si c'est pour la remonter telle qu'elle. Le catch te permet d'interception l'erreur. A toi de faire un traitement derrière (typer l'exception, écrire des logs, renvoyer un booléen...). Perso, je ne suis pas très fan du retourn du booléen car cela t'impose un comportement toujours identique et tu n'a jamais l'exception (ni type ni message) en retour. Il me semble évident qu'un jour ou l'autre, tu ait besoin de faire un traitement spécifique sur une exception (tu catch un certain type d'exception, tu affiche un message, tu envoi un mail...). Or dans un contexte ou tu retourne un booléen, tu n'a plus la main sur l'exception retourné.

3/ Normalement, a part ton formulaire, aucune classe ne doit manipuler les contrôles du formulaire. D'ailleurs, lorsqu'on créer un UserControl, le mieux est d'exposer des propriétés ou méthodes public qui vont manipuler les contrôles de ton formulaire plutôt que d'exposer les contrôles du formulaires

[meziantou]

Je suis parfaitement d'accord avec oyigit.

[pot2yaourt]

Salut à tous et merci pour vos réponses !

Du coup, j'ai entièrement revu (et corrigé) mes classes statiques et transformé le tout en vrai objet. Du coup, les objets créés sont plus "logiques" et c'est tant mieux !
Maintenant, je limite donc au minimum les classes / méthodes statiques.

Pour ce qui est de la gestion des exceptions, le but étant d'afficher un message à l'utilisateur (via un MessageBox.Show(ex.Message); dans le formulaire principal) et de logger le message exacte de l'exception (via Log4Net), j'ai créé une classe héritant de Exception et le tour est joué !

Encore merci à tous pour vos réponses détaillées !
Lionel.