Classes vs Modules dans VB.NET

Je pense que c'est une bonne idée de continuer à éviter les modules sauf si vous les collez dans des espaces de noms séparés. Parce que dans Intellisense les méthodes dans les modules seront visibles de partout dans cet espace de noms.

Donc, au lieu de ModuleName.MyMethod() Vous vous retrouvez avec MyMethod() popups dans n'importe où et ce genre d'invalide l'encapsulation. (au moins au niveau de la programmation).

C'est pourquoi j'essaie toujours de créer une Classe avec des méthodes partagées, semble tellement mieux.

Les Modules ne sont en aucun cas obsolètes et sont fortement utilisés dans le langage VB. C'est le seul moyen par exemple d'implémenter une méthode d'extension dans VB.Net.

Il y a une énorme différence entre les Modules et les Classes avec des membres statiques. Toute méthode définie sur un Module est globalement accessible tant que le Module est disponible dans l'espace de noms actuel. En effet un Module vous permet de définir des méthodes globales. C'est quelque chose qu'une classe avec seulement des membres partagés ne peut pas faire.

Voici un exemple rapide que j'utilise beaucoup lors de l'écriture de code VB qui interops avec des interfaces COM brutes.

Module Interop
  Public Function Succeeded(ByVal hr as Integer) As Boolean
    ...
  End Function

  Public Function Failed(ByVal hr As Integer) As Boolean
    ...
  End Function
End Module

Class SomeClass
  Sub Foo()
    Dim hr = CallSomeHrMethod()
    if Succeeded(hr) then
      ..
    End If
  End Sub
End Class

, Il est acceptable d'utiliser Module. Module n'est pas utilisé en remplacement de Class. Module sert son propre but. Le but de Module est d'utiliser comme conteneur pour

• méthodes d'extension,
• variables qui ne sont spécifiques à aucun Class, ou
• variables qui ne correspondent pas correctement à tout Class.

Module ce n'est pas comme un Class puisque vous ne pouvez pas

• hériter d'un Module,
• mettre en œuvre un Interface avec Module,
• ni créer une instance de Module.

Tout ce qui se trouve dans un Module peut être directement accessible dans l'assembly Module sans faire référence au Module par son nom. Par défaut, le niveau d'accès pour un Module est Friend.

Les Classes

• classes peuvent être instancié comme objets
• les données D'objet existent séparément pour chaque objet instancié.
• Les classes peuvent implémenter des interfaces .
• les membres définis dans une classe sont étendus dans une instance spécifique de la classe et n'existent que pour la durée de vie de l'objet.
• pour accéder aux membres d'une classe depuis l'extérieur d'une classe, vous devez utiliser noms complets au format de objet.Membre .

Les Modules

• les Modules ne peuvent pas être instanciés en tant qu'objets, car il n'y a qu'une seule copie des données d'un module standard, lorsqu'une partie de votre programme modifie une variable publique dans un module standard, elle sera visible pour l'ensemble du programme.
• les membres déclarés dans un module sont accessibles au public par défaut.
• il est accessible par n'importe quel code qui peut accéder au module.
• Cela signifie que les variables d'un module standard sont effectivement des variables globales car elles sont visibles de n'importe où dans votre projet, et elles existent pour la durée de vie du programme.

Quand l'un de mes VB.NET classes a tous les membres partagés je le convertit en un Module avec un espace de noms correspondant (ou autrement approprié) ou je rends la classe non héritable et non constructible:

Public NotInheritable Class MyClass1

   Private Sub New()
      'Contains only shared members.
      'Private constructor means the class cannot be instantiated.
   End Sub

End Class

Les Modules sont parfaits pour stocker des énumérations et certaines variables globales, constantes et fonctions partagées. c'est très bonne chose et je l'utilise souvent. Les variables déclarées sont visibles Acros ensemble du projet.

Vous devez utiliser un Module (plutôt qu'une classe) si vous créez des méthodes D'Extension. Dans VB.NET Je ne suis pas au courant d'une autre option.

Étant moi-même résistant aux Modules, je viens de passer quelques heures sans valeur à essayer de trouver comment ajouter du code standard pour résoudre les assemblages intégrés en un seul, seulement pour découvrir que Sub New() (Module) et Shared Sub New() (Classe) sont équivalents. (Je ne savais même pas qu'il y avait {[8] } un appelable Sub New() dans un Module!)

Donc je viens de jeter le EmbeddedAssembly.Load et AddHandler AppDomain.CurrentDomain.AssemblyResolve lignes là-dedans et Bob est devenu mon oncle.

Addendum : Je ne l'ai pas encore vérifié à 100%, mais j'ai une idée que Sub New() s'exécute dans un ordre différent dans un Module qu'une classe, juste en fonction du fait que j'ai dû déplacer certaines déclarations vers des méthodes internes de l'extérieur pour éviter les erreurs.