Discussion :

[Invité]

Bonjour à tous.

Juste une question simple pour ceux qui savent.
Est-ce une bonne pratique d'imbriquer une classe dans un module ou au contraire une mauvaise pratique ?

Idem pour les structures tant qu'on y est.

Namespace.Module.Class.Sub() => Bon ?
Namespace.Module.Structure.Property.Get() => Bon ?

Si c'est déconseillé, pourquoi ?



Merci.

[Pragmateek]

AFAIK les modules n'ont pas grand intérêt et servent juste a agréger des fonctions globales.

D'ailleurs il n'y a pas d'équivalent en C#, le plus proche étant les classes statiques.

Donc met plutôt tes classes dans des namespaces directement.
Et si tu as une classe utilisée uniquement localement par une autre classe tu peux éventuellement la définir au sein de cette classe même.

[Invité]

Salut,

Oui, je sais qu'il n'y a pas d'équivalent en C#.
(Pour du C#, les modules sont des sealed class)

Ma question est plutôt, quel risque puis-je avoir si j'écris du code de temps en temps avec des Structures/Classes/Interface à l'intérieur d'un autre conteneur Module.
J'ai fait un test pour voir si le code été compatible CLS, et cela fonctionne.


Je ne cherche pas spécialement de débat sur les qualités d'un module, mais cherche à savoir les éventuelles dis-fonctionnement qui pourrait arriver dans certaines situations. Je sais que c'est compatible avec Excel VBA par exemple, c'est déjà un bon début (mais il me manque le milieu et la fin on va dire ).


Et si c'est réellement déconseillé de faire ça, quels seraient les arguments ?

[Pragmateek]

AFAIK les modules n'existent pas dans le CLS, ils sont traduits par le compilateur VBC en classes .Net à la génération du CIL.

Donc à priori pas de "dysfonctionnement".

L'argument contre serait cette fonctionnalité d'export automatique des membres du module, donc création de variables/méthodes/types globaux, ce qui est une mauvaise pratique admise depuis au moins 1/4 de siècle.

[Invité]

L'argument contre serait cette fonctionnalité d'export automatique des membres du module, donc création de variables/méthodes/types globaux, ce qui est une mauvaise pratique admise depuis au moins 1/4 de siècle.

Avec COM Interop par exemple, il n'est pas possible de transformer directement un Module VB(7 ou +) en module VBA par exemple. J'aurai bien aimé.
Et les constantes et Variables/Property/Sub etc... Shared ne sont pas (directement) prise en charge.

Et sinon, les modules conteneurs sont transformés en classe non conteneur.

Il n'est pas possible en VBA d'écrire :
Dim a As NomProject.NomModule.NomClasse
comme c'est le cas en VB7.

En revanche, on peut écrire:
Dim a As NomProject.NomModule.NomType

Sinon, pour le 1/4 de siècle, le VBA est assez vieux et il est limité.
Un point d'entrée sous forme d'une propriété Get pour accéder à une hiérarchie est la meilleur solution en VBA comme c'est le cas avec le modèle object d'Excel. Il n'y a pas de Namespace par exemple donc il faut faire avec les moyens du bord. Si on pouvait le faire avec Excel, on utiliserai Imports Namespace comme en VB7 et toutes les Propriétés Get serait contenu dans un Namespace, mais il n'y a pas d'import et le nom du project devant le nom d'une propriété Public n'est que Optionnel ce qui n'est pas le cas des Namespaces en VB7. Le VB7 est une grosse évolution du VB6 où la plupart des défauts du VB6/VBA ont été supprimé un par un.

Mais bon, si il n'y a réellement que ça, OK. J'en prend note, merci.
C'était surtout pour m'informer.


Merci.
@+