Pass FileSystemObject existentes o crear varias instancias

Question

que tienen varios procedimientos que utilizan el FileSystemObject. Encuentro que es bastante conveniente.

Pregunta: ¿Es sensato para pasar una instancia de FileSystemObject de un procedimiento "principal" a estos otros procedimientos como argumento, en lugar de tener cada procedimiento de crear su propia instancia de FileSystemObject?

Ejemplo: ¿es mejor en cualquier manera de hacer esto:

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 

que he visto al menos un programador hacer, en lugar de lo siguiente, que es lo que suele hacer:

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 

puedo ver la idea de hacer la primera en que este potencialmente reduce la sobrecarga asociada con tener varias instancias de FileSystemObject. Pero parece terriblemente engorroso tener que aprobar FSO como argumento cada vez. Y en serio, ¿los gastos generales realmente son tan grandes?

Answer 1

En mi opinión, la sobrecarga de crear muchos OIA no es el problema; pero "no debe repetirse" y cada CreateObject("System.FileSystemObject") [oops] aumenta el riesgo de un error de tiempo de ejecución. Debajo del capó hay exactamente un sistema de archivos y un objeto de sistema de archivos, de modo que si los programadores C/C++ pueden usar STDOUT o cerr, un programador de VBScript/VBA tiene derecho a global FSO (no se puede hacer nada a un FSO de singleton que cambia su funcionamiento en otros subs/funciones, excepto el cambio de la variable de retención).

Answer 2

prefiero para envolver las cosas en una clase en lugar de pasar parámetros alrededor de 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 

.

Answer 3

He hecho algo como esto recientemente, y personalmente prefiero usar un único objeto de sistema de archivos siempre que sea posible. Lo considero como pasar identificadores de archivo entre funciones, que a su vez escriben en el manejador de archivo abierto.

Al definir sus funciones/subs, asegúrese de pasar el objeto del sistema de archivos utilizando la palabra clave ByRef.

El único momento en que esto sería inaceptable es si está navegando a través de una jerarquía de archivos, y necesita que el FSO mantenga el mismo directorio. Cabe señalar, sin embargo, que los requisitos de memoria de un solo FSO son insignificantes en los ordenadores de hoy en día, y sólo se dará cuenta de una ganancia de rendimiento si es necesario utilizar una función recursiva o repetidamente llamar a una función que crea/destruye estos objetos.