VB.NET中的类与模块

Question

在VB.NET中使用模块而不是具有共享成员函数的类是否被认为是可接受的做法？

我倾向于避免使用模块,因为他们觉得像Visual Basic 6.0中剩下的遗留物并不再适合.另一方面,使用模块和仅具有共享成员的类似乎没有太大区别.我不是经常需要它,但有时候它们会提供一个简单的解决方案.

我很想知道你是否有任何意见或偏好.

Answer 1

Modules是C#static类的VB对应物.如果您的类仅为辅助函数和扩展方法而设计,并且您不希望允许继承和实例化,则使用a Module.

顺便说一句,使用Module并不是真正主观的,并没有被弃用.事实上,你必须Module在适当的时候使用..NET Framework本身可以多次执行(System.Linq.Enumerable例如).要声明扩展方法,需要使用Modules.

Answer 2

我认为,除非将它们粘贴到单独的命名空间中,否则继续避免使用模块是一个好主意.因为在Intellisense中,模块中的方法将从该命名空间中的任何位置可见.

因此,不是ModuleName.MyMethod()你最终MyMethod()在任何地方弹出窗口,这种封装无效.(至少在编程层面).

这就是为什么我总是尝试用共享方法创建Class,看起来好多了.

Answer 3

模块绝不是弃用的,并且在VB语言中大量使用.这是在VB.Net中实现扩展方法的唯一方法.

模块和具有静态成员的类之间存在巨大差异.只要模块在当前命名空间中可用,模块上定义的任何方法都是全局可访问的.实际上,模块允许您定义全局方法.这是只有共享成员的类无法做到的事情.

这是一个快速的例子,我在编写与原始COM接口交互的VB代码时经常使用.

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

可以使用Module.Module不用作替代品Class.Module服务于自己的目的.目的Module是用作容器

• 扩展方法,
• 不特定的变量Class,或
• 任何不适合的变量Class.

Module是不是Class因为你不能

• 继承自Module,
• Interface用a 实现一个Module,
• 也不创建一个实例Module.

内部的任何内容Module都可以在Module程序集中直接访问,而无需引用Module其名称.默认情况下,对于一个访问级别Module是Friend.

Answer 5

类

• 类可以实例化为对象
• 对象数据分别存在于每个实例化对象.
• 类可以实现接口.
• 在类中定义的成员在该类的特定实例中作用域,并且仅在该对象的生命周期中存在.
• 要从类外部访问类成员,必须使用Object.Member格式的完全限定名.

模块

• 模块无法实例化为对象,因为标准模块的数据只有一个副本,当程序的一部分更改标准模块中的公共变量时,整个程序都可以看到它.
• 默认情况下,模块内声明的成员可公开访问.
• 任何可以访问模块的代码都可以访问它.
• 这意味着标准模块中的变量实际上是全局变量,因为它们在项目的任何位置都是可见的,并且它们在程序的生命周期中存在.

Answer 6

当我的一个VB.NET类具有所有共享成员时,我将其转换为具有匹配(或其他适当的)命名空间的模块,或者使该类不可继承且不可构造:

Public NotInheritable Class MyClass1

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

End Class