oop - 在 VBA 中使用类模块作为命名空间有什么陷阱吗

Question

VBA 不支持 namespace (Java 人员的包)。其他语言的命名空间有助于避免歧义和补充工具，如成员名称的自动完成。

在 VBA 中模拟命名空间的一种方法是在 Class 模块中声明事实上的静态方法，然后在标准模块中声明该类的默认实例。这甚至是 pattern followed in some Microsoft documentation .您也可以使用这种方法来嵌套伪命名空间。

我的同行们，您是否预计使用这种方法会出现任何技术问题？

这不是民意调查问题；我不是在问正统或美学吸引力。我在问，“这会引起问题吗？如果会，会怎样？”

例子:

' Class module called clsIOText
Public Function ReadAllText(ByVal FileName As String) As String
    With New FileSystemObject
        With .OpenTextFile(FileName, ForReading)
            ReadAllText = .ReadAll
            .Close
        End With
    End With
End Function

' Class module call clsIO
Public Text As New clsIOText

' In a standard module somewhere
Public IO As New clsIO

' Usage like a namespace
' 1. Fully qualified
Debug.Print IO.Text.ReadAllText("C:\temp\example.txt")

' 2. With a namespace alias-like object
Dim Text As clsIOText
Text = IO.Text
Debug.Print Text.ReadAllText("C:\temp\example.txt")

Answer 1

暂时没有其他答案...

我自己想出的陷阱是更多的限制和陷阱:

您需要将每个类的 Instancing 属性设置为“2 - PublicNotCreatable”。否则，如果项目被编译然后从另一个项目中引用，成员将不会出现在对象浏览器中(尽管它们仍然可用)

您不能将类模块中的外部 API 声明声明为 Public。为了将它们暴露给类外的代码，您必须执行 Declare作为私有(private)，然后制作一个公共(public)包装方法。

这仍然不允许您在命名空间中组织类型——只能是静态方法的集合。

从查询和宏中，您只能调用标准模块中定义的全局方法。因此，要使用包装在命名空间类中的任何函数，您必须在标准模块中定义包装器，重新扁平化层次结构。