¿Deberían pasar objetos desechables?

Question

En una revisión del código, un compañero de trabajo cambió mi código para pasarlo en un flujo como parámetro. Dijo que esto era para asegurar que la responsabilidad de deshacerse del objeto sea clara para la persona que llama. En cierto sentido, puedo empatizar. Preferiría que el creador del objeto también sea responsable de la limpieza.

Por otro lado, ninguno de los métodos hace que la necesidad de un using sea más clara. Prefiero la llamada al método más simple también.

Take

public static TextReader Serialize<T>(T obj) where T: new() 
    { 
     if (obj == null) throw new ArgumentNullException("obj"); 
     return Serialize<T>(obj, null); 
    } 

VS

public static void Serialize<T>(T obj, TextWriter outbound) where T : new() 
    { 
     if (obj == null) throw new ArgumentNullException("obj"); 
     Serialize<T>(obj, outbound, null); 
    } 

¿Hay alguna razón técnica para añadir el parámetro adicional?

Answer 1

Depende estrictamente de la arquitectura de su código.

Yo, personalmente, al igual que el segundo enfoque (incluso si se añade un argumento más), donde definición de la función estados que no se cierra/disponer de un arroyo, pero depende de la llamada.

Esto es muy útil en caso de que vaya a llamar a las mismas funciones en la misma secuencia, porque si imagina que cada llamada de función se cerrará y volverá a abrir la secuencia, se convertirá en una operación que consume muchos recursos.

Answer 2

Es posible que ya tengas un TextWriter abierto. Es por eso que preferiría la segunda versión. Además, reduce el alcance de lo que hace el método Serialize: se serializa, pero no abre nada. La apertura es una preocupación diferente.

Answer 3

El método Serialize-T sobrecargado ¿CREA la secuencia? Si ese es el caso, yo prefiero # 1 becuase que hace que el 'utilizar' más simple:

using (var stream = Serialize(a_T))) 
{ 
    // Do something else with the stream? 
} 

Por otro lado, podría ser mejor para la persona que llama para suministrar la corriente, en cuyo caso se desea transmitir uno en la opción 2.

Answer 4

A medida que el proyecto evoluciona, los programadores que mantienen el código en el primer enfoque pueden no recordar que es responsabilidad del código de llamada cerrar la secuencia (especialmente en casos no triviales) . Las personas que llaman tendrían que depender de la documentación para hacer lo correcto y todo el mundo lee la documentación, ¿verdad? ;)

El segundo enfoque mejor "balances" resources. Lo hace mucho más claro donde radica la separación de responsabilidades.