[VS2003] Module VS Class

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.

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

Bonjour.

Citation:

---

Envoyé par sperot51

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 :lol: ? 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 :lol: !), 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.

Citation:

---

Envoyé par olsimare

Bonjour.



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

---

ah oui lol

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 :mouarf:

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 :aie:)

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.

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:

---

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:

---

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:

---

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

Ah lala... Qu'est-ce que je ferais sans Sperot quand même ! ^^

Merci, ça m'a l'air bien clair.

Je vais travailler là dessus.

Griftou.

P.S. : Je suppose que le f.showdialog suppose qu'une interface graphique soit définie pour cette classe.

Sinon, pour répondre à la question que j'ai totalement zapée dans mon précédent message, il y a dans mon module :

5 variables globales dont 1 publique
12 fonctions publiques

servant à faire des selects, des updates, des deletes, des inserts, checker si une table existe, se connecter, se déconnecter

dans mon exemple, les classes préfixées de FRM sont des fenetre
(inherits system.windows.forms.form)
donc en effet showdialog affiche la fenetre

Voilà, après avoir réfléchi un p'tit peu, je me lance maintenant dans la conception.

J'opte pour une ou plusieurs classes plutot qu'un module.

Déjà, je me pose une première question.

Est-il possible au sein du procédure de déclarer des objets qui soient utilisable dans le reste de la classe ? A ma connaissance, une fois la procédure terminée, les objets sont détruits.

Si c'est possible, une seule classe me suffira. Dans le cas contraire, il me faudra une classe par type de base de données que je compte gérer.

Une autre question sous-jacente. Une fois que j'aurai terminé mon p'tit développement, pour utiliser ces classes, est-il possible de créer une dll qui englobe le tout qu'il suffira que j'ajoute comme référence à mes futurs projet (je suppose que oui ^^) ou bien devrais-je chaque fois ajouter l'ensemble des classes que j'aurai créées ?

Je vais de ce pas checker les différents type de projets que VS propose, ma réponse s'y trouve p-e.

Merci d'avance.

Griftou.

projet application => exe
projet bibliotheque de classe => dll

donc tu pourras mettre ca dans une dll


par contre je vais t'embeter mais y a une autre solution
une interface avec une fabrique de classe

par exemple une interface IData qui comprends executenonquery et plein d'autres trucs utiles
ensuite une classe par type de base de données qui implémente cette interface
et enfin le createur d'instance avec une enum

public shared function CreateInstance(type_de_base enum) as IData
select case type_de_base_enum
case sql server return new machin
case access return new bidule


l'avantage de ca c'est que ton code est pareil peu importe la base
mais aussi que tu peux modifier tous les accès de tout un programme en modifiant très peu de lignes



sinon pour qu'un variable soit accessible d'une sub à l'autre, il suffit qu'elle soit déclarée au niveau de la classe

je t'invite à regarder http://plasserre.developpez.com/vsommair.htm si tu ne l'as pas encore fait, au moins pour la portée des variables

Tu pourrais développer ton histoire de fabrique de classe stp ?

Sinon je fais donc un projet de bibliothèque.

Pour mon histoire de variable utilisable d'une sub à une autre, bien sûr qu'on peut les déclarer globalement à la classe mais mon idée était que ce soit une procédure qui déclare lesdites variables.

Griftou.

Citation:

---

Envoyé par griftou

Tu pourrais développer ton histoire de fabrique de classe stp ?

---

comme je disais, une interface qui contiendra tous les membres public

ensuite une classe par type de base qui implémente cette interface

et enfin une classe de factory

Code:

---

1 2 3 4 5 6 7 8 9 10

Public Class DataFactory public enum type_base sql_server = 1 access = 2 ' ... end enum   public shared function CreateInstance(typedata as type_base) as IData 'select case qui return un new des classes implémentant IData selon le cas end function End Class

---

Citation:

---

Envoyé par griftou

Pour mon histoire de variable utilisable d'une sub à une autre, bien sûr qu'on peut les déclarer globalement à la classe mais mon idée était que ce soit une procédure qui déclare lesdites variables.

---

pour qu'une variable soit accessible d'une sub à une autre, il n'y a pas d'autre moyen que de la déclarer au niveau de la classe, et c'est logique

par contre tu peux initialiser tes variables dans une sub, le sub new est généralement fait pour ca

Oui mais c'est quoi ce factory ? Je n'en ai jamais entendu parler :oops:

Sinon pour le reste, je pense que je te suis.

Griftou.

et bien c'est un concept c'est tout

après partout dans ton programme au lieu de faire
dim obj as new DataSqlServer
ou autre

et bien du fait dim obj as IData = DataFactory.Createinstance(sql_server)


et après ca fonctionne pareil

enfin tu mets les noms que tu veux

Ah ok, j'ai cru que c'était un truc technique ^^.

Dans ce cas oui, cela me semble une très bonne idée.

Ca y est, j'ai fini par comprendre. Ca va être bien quand ce sera terminé :mrgreen: .

Mais, à peine que je m'attaque à l'interface que j'ai un soucis. Dans une de mes fonctions, je passe en paramètre la connexion à la DB. Evidemment le type de l'objet à passer dépend du type de la DB. Y a-t-il un moyen de contourner cela avec une espèce de type générique ou bien dois-je faire des surcharge pour cette fonction ?

Griftou.

il existe des classes génériques et des sub génériques
il est aussi possible que ta dll gère l'objet connexion plutot que de le recevoir, ce qui serait mieux à mon avis, le but d'un objet de connexion, et à mon avis d'avoir un code le plus petit possible partout dans l'appli et que ca se débrouille



classe générique : (interface générique possible aussi)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class maclasse (of montype1, autretype)   private var1 as montype1   public sub aaa (param1 as autretype) end sub   end class   (...)   dim var as new maclasse(of integer, image)

---

ici, 2 types sont définis à l'instanciation de la classe, ces types peuvent etre utilisés sans savoir à l'avance ce que ce sera dans la classe



sub générique :

Code:

---

1 2 3 4

public sub aaaaaa (of typeparam) (param1 as typeparam)   end sub

---

ici, param1 est d'un type non défini à l'écriture de la classe, et qui peut etre n'importe quoi
l'appel ne nécessite même pas de spécifier le type
juste instance.aaaaaa(obj_param) et ca se débrouille



dans les 2 cas, les typeof peuvent etre pratique pour tester différents cas


NB: les classes génériques sont aussi utilisées dans le framework
par exemple les system.Collections.Generic (list dictionary etc...) nécessite qu'on spécifie le type
ex : list (of system.windows.forms.control)

Ok, maintenant que je sais que ça existe, j'vais essayer de trouver un tuto là dessus pcq j'pige pas trop avec tes exemples :oops:

Merci beaucoup en tout cas !

Griftou.

EDIT : J'ai oublié de préciser... Je suis donc en train de créer l'interface qui contient les déclaration des méthodes. Ensuite, pour chaque type de DB, je vais créer une classe qui implémente cette interface. C'est donc la classe qui créera la connexion, elle ne la recevra pas. Mais ça n'empêche que pour mon interface, quand j'déclarais ma fonction avec une connexion en param, il me fallait le type de l'objet. D'où mon problème.

:cry: generics is not on framework 1.1 :cry:

I've to bother my boss again and again until he buys VS2005 but he's in holiday right now...

Waitiiiiiiiiiiiing...

Griftou.

EDIT : Mais pourquoi j'ai écris en anglais moi ? :aie: (en fait c'est pcq le site où j'ai lu la doc était en anglais et que je joue sur des portails en anglais depuis mon boulot donc j'ai oublié de refaire le switch vers la langue française mdr)