5

我有几个使用 FileSystemObject 的过程。我觉得挺方便的。

问题：将现有的 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 作为参数传递似乎非常麻烦。说真的，开销真的那么大吗？

4

3 回答 3

2

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

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

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

于 2011-06-29T14:46:44.577 回答
1

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

于 2011-06-28T18:46:05.040 回答
1

我更喜欢将东西包装在一个类中，而不是从一个子到另一个传递参数......

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

.

于 2011-06-29T12:57:44.583 回答