Question

我有几个使用FileSystemObject的过程。我发现它很方便。

问题：从＆＃34; main＆＃34;传递FileSystemObject的现有实例是否合理？将这些其他过程作为参数的过程，而不是让每个过程创建自己的FileSystemObject实例？

示例：以任何方式更好地执行此操作：

Sub MainSub()
    Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
    Call OtherSub(FSO, myargs)
    ' call other subs and functions that use FileSystemObject
End Sub

Sub OtherSub(FSO, myargs)
    ' Do stuff with FSO
    ' call other subs and functions that use FileSystemObject
End Sub

我至少看过一个程序员，而不是以下，这是我通常做的事情：

Sub MainSub()
    Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
    Call OtherSub(myargs)
    ' call other subs and functions that use FileSystemObject
End Sub

Sub OtherSub(myargs)
    Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject")
    Call OtherSub(myargs)
    ' Do stuff with FSO
    ' call other subs and functions that use FileSystemObject
End Sub

我可以看到做前者的想法，这可能会减少与拥有多个FileSystemObject实例相关的开销。但每次必须将FSO作为参数传递似乎非常麻烦。而且严重的是，开销真的那么大吗？

Answer 1

我最近做过类似的事情，我个人更喜欢尽可能使用单个文件系统对象。我认为它是在函数之间传递文件句柄，然后写入打开的文件句柄。

定义函数/ subs时，请务必使用ByRef关键字传递文件系统对象。

唯一不可接受的是，如果您在文件层次结构中导航，并且需要FSO来维护同一目录。然而，应该注意的是，单个FSO的内存要求在当今的计算机中可以忽略不计，如果需要使用递归函数或重复调用创建/销毁这些对象的函数，您只会注意到性能提升。 / p>

Answer 2

在我看来，创建许多FSO的开销不是问题;但“你不应该重复自己”，每个CreateObject( "System.FileSystemObject" ) [oops]会增加运行时错误的风险。在引擎盖下只有一个文件系统和一个文件系统对象，所以如果允许C / C ++程序员使用STDOUT或cerr，VBScript / VBA程序员有权使用全局 FSO（你不能对单个FSO做任何事情，改变其在其他子/函数中的工作 - 除了切换保持变量。）

Answer 3

我更喜欢在一个类中包装，而不是将参数从sub传递给sub ...

Set c = New MyClass
c.MainSub

Class MyClass

    Dim fso 

    Sub Class_Initialize
        Set fso = CreateObject("Scripting.FileSystemObject")
    End Sub

    Sub Class_Terminate
        Set fso = Nothing
    End Sub

    Public Sub MainSub()    
        OtherSub myargs
        ' call other subs and functions that use fso
        ' or use fso here
    End Sub

    Public Sub OtherSub myargs
        ' Do stuff with fso here or call another sub in the class
    End Sub 
End Class

传递现有的FileSystemObject或创建多个实例

3 个答案: