Discussion :

[Kropernic]

Alors voici une question toute bête et qui, je pense, sera vite résolue.

Quelle est la différence entre un module et une classe ?

Je me pose la question car j'ai un jour créé un module (pourquoi j'ai fait module et pas class, j'en sais rien ^^) pour traiter tous mes accès DB. C'est lui gère la connexion et toutes les requêtes.

Maintenant, je suis en train de me dire que, comme j'ai rien à faire à mon taf en ce moment, je rendrais bien ce module multi DB car à l'heure actuelle, je dois l'adapter en fonction de la DB que j'utilise. Il s'agit uniquement de changer les types des objets mais bon...

Enfin bon, tout ça pour dire que je me demandais ce qu'il est possible de faire avec un module et que l'on ne pourrait faire avec une classe (et réciproquement).

Merci d'avance.

Griftou.

[Pol63]

un module est un genre de singleton utilisable directement
une classe n'est pas utilisable sans instance

il peut y avoir plusieurs instances d'une classe grace à NEW
chaque instance de classe a ses propres variables privées

il me semble qu'un module ne peut pas avoir de propriétés ni d'évènements aussi

un module fonctionne à peu près comme une classe qui n'a que des membres shared


pour un accès à la db, un module peut suffire en effet, mais des fois un classe est mieux (pour des trucs plus poussés, genre appli multithreadées)

pour faire en sorte que ca soit multi db, tu peux aussi rester sur un module

m'enfin les modules sont très peu utilisés sur .NET

[olsimare]

Bonjour.

une classe n'est pas utilisable sans instance
...
un module fonctionne à peu près comme une classe qui n'a que des membres shared

Hmmm... c'est un peu contradictoire non ? Si j'utilise une méthode shared, je n'instancie pas la class.

Dans un tel cas, ça n'est pas tant la classe qui est importante mais bien le partage de la méthode.

Personnellement, je conseillerai également une classe NotInheritable avec effectivement des méthodes et propriétés shared (genre le TextRenderer) car le module... ça ressemble à de la rémanence de VB.

Autre point, avec un module, on perd vite le fil et ça devient vite fourre tout. La class a un effet structurant (sauf si on même tout dans la même !), on est plus tenter de regrouper les méthodes ou propriétés par fonctionnalité (pour le TextRenderer, c'est tout ce qui permet de gérer le rendu d'un text).

Cdt.

[Pol63]

Bonjour.



Hmmm... c'est un peu contradictoire non ? Si j'utilise une méthode shared, je n'instancie pas la class.

ah oui lol

[Kropernic]

Autant la première réponse de sperot m'avait semblée claire, autant les suivantes m'embrouillent ^^.

Bon, je pense que j'vais essayer de refaire mon machin avec une/des classe/s parce que c'est vrai que mon module est franchement fourre tout. Ca concerne l'accès DB ? Oui --> hop, dans le module

Puis ça me fera un bon exercice. Je n'ai encore jamais créé de classe à moi (enfin si, j'ai fait ça en java pendant mon stage de fin d'étude mais j'me souviens plus comment faut faire )

Vous me conseilleriez de faire une seule classe ou plusieurs (comment les séparer alors ?) ?

Je crois qu'il va falloir que j'acquiers la manière de réfléchir derrière tout ça...
J'ai déjà lu et relu divers texte sur le langage orienté objet donc la théorie j'la connais mais quand on passe à la pratique, c'est autre chose.

Merci quand même !

Griftou.

[Pol63]

quels sont les membres de ton module à peu près ?
(membres = {variable, propriété, sub, fonction, event ...})


un module peut etre utile pour stocker des variables globales à l'application, tout le monde doit nécessairement avoir la meme, peu importe la fenetre à partir de laquelle tu lis les variables

mais là aussi on peut déporter ca dans une classe, par exemple, si tu fais une fenetre de réglages des paramètres, tu peux alors mettre les variables globales en tant que propriétés shared de cette classe Form

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
 
public class FRMparams
 
     ' {code de la fenetre}
 
    private shared _CouleurFond as system.drawing.color
    public shared readonly property CouleurFond as system.drawing.color
        get
            return _CouleurFond
        end get
    end property
 
    public shared sub InitParameters() ' cette sub peut etre appelée au demarrage de l'appli pour initialiser les parametres par exemple
        ' accès à la base de données pour retrouver les paramètres (ou fichier ini)
        _CouleurFond = couleurtrouveedansbase
    end sub
 
end class

comme ca n'importe quand tu peux faire

Code :

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

1
2
dim f as new FRMparams
f.showdialog

l'utilisateur peut changer les paramètres comme la couleur de fond de l'appli dans mon exemple, et tu enregistres ce qu'il fait
et les paramètres sont accessibles depuis toute l'appli

Code :

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

1
2
3
4
5
6
7
public class FRMmenu
    public sub new
        me.backcolor = FRMparams.CouleurFond
    end sub
 
' {code de la fenetre}
end class

FRMparams n'est ici pas une instance mais le nom de la classe, les membres non partagés ne sont pas affichés par l'intellisense, ni utilisable

alors que f plus haut est une instance du type FRMparams
et donc f.CouleurFond sera souligné en erreur car ce n'est pas une propriété d'instance mais de la classe