Classes vs. Modules dans VB.Net

Question

Est-ce considéré comme une pratique acceptable pour utiliser les Modules au lieu de Classes avec un partage des fonctions de membre dans VB.Net?

J'ai tendance à éviter de Modules, parce qu'ils se sentent comme à gauche sur des vestiges de VB6 et n'a pas vraiment l'air de tenir dans de plus. D'autre part, il ne semble pas être beaucoup de différence entre l'utilisation d'un Module et d'une Classe avec seulement Partagé membres. C'est pas souvent que j'ai vraiment besoin de beaucoup pour soit, mais il y a parfois des situations où ils présentent une solution simple.

Je suis curieux de savoir si vous avez des avis ou des préférences d'une façon ou de l'autre.

Answer 1

Modules sont VB homologues C#, static les classes. Lorsque votre classe est conçu exclusivement pour des fonctions d'assistance et les méthodes d'extension, et vous ne voulez autoriser l'héritage et l'instanciation, vous utilisez un Module.

Par la façon dont, à l'aide de Module n'est pas vraiment subjectif et c'est pas obsolète. En effet, vous devez utiliser un Module quand c'est approprié. .NET Framework lui-même n'a de nombreuses reprises (System.Linq.Enumerable, par exemple). Pour déclarer une méthode d'extension, il est nécessaire d'utiliser Modules.

Answer 2

Je pense que c'est une bonne idée de continuer à éviter les modules à moins de les coller dans des espaces de noms distincts. Parce que dans Intellisense, les méthodes des modules seront visibles de partout dans cet espace de noms.

Ainsi, au lieu de ModuleName.MyMethod() vous vous retrouvez avec MyMethod() popups n'importe où et cela invalide l'encapsulation. (au moins au niveau de la programmation).

C'est pour cela que j'essaie toujours de créer Class avec des méthodes partagées, cela semble tellement mieux.

Answer 3

Les Modules sont pas obsolètes et sont utilisés massivement dans les VB langue. C'est le seul moyen par exemple de mettre en œuvre une méthode d'extension dans VB.Net.

Il y a une différence énorme entre les Modules et les Classes avec des Membres Statiques. Toute méthode définie sur un Module est accessible dans le monde entier aussi longtemps que le Module est disponible dans l'espace de noms courant. En effet un Module vous permet de définir des méthodes globales. C'est quelque chose qu'une classe avec seulement partagé les membres ne peuvent pas faire.

Voici un petit exemple que j'utilise beaucoup lors de l'écriture de code visual basic qui interops avec des interfaces COM.

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

Answer 4

Il est acceptable d'utiliser l' Module. Module n'est pas utilisé comme un remplacement pour Class. Module sert à ses propres fins. Le but de l' Module est à utiliser comme un conteneur pour

• les méthodes d'extension,
• les variables qui ne sont pas spécifiques à Class, ou
• les variables qui ne s'adaptent pas correctement dans tous les Class.

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

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

Rien à l'intérieur d'un Module peut être directement accessible au sein de l' Module de l'assemblée, sans référence à l' Module par son nom. Par défaut, le niveau d'accès pour un Module est Friend.

Answer 5

Quand une de mes classes VB.NET a tous les membres partagés, je la convertis en un module avec un espace de noms correspondant (ou 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