c# - textos - uso de la c s z ejercicios interactivos

¿Mala práctica? Uso no canónico de la declaración de uso de c#

Question

C # tiene la instrucción using , específicamente para objetos IDisposable. Presumiblemente, cualquier objeto especificado en la declaración de using tendrá algún tipo de recurso que debe liberarse de manera determinista.

Sin embargo, me parece que hay muchos diseños en la programación que tienen un principio y un final definidos, pero que carecen de soporte de lenguaje intrínseco. El constructo de using brinda la oportunidad de utilizar las funciones integradas de un editor de código para, al menos, resaltar de manera clara y natural el alcance de dicho diseño u operación.

Lo que tengo en mente es el tipo de operación que frecuentemente comienza con los BeginXXX() y EndXXX() , aunque hay muchos sabores diferentes, como una ejecución de código asíncrono que involucra un "inicio" y una "unión".

Tomemos este ejemplo ingenuo.

webDataOperation.Start();
GetContentFromHardDrive();
webDataOperation.Join();
// Perform operation that requires data from both sources

¿Qué pasa si, en cambio, el método de inicio devolvió un objeto cuyo método IDisposable.Dispose realiza la operación de unión.

using(webDataOperation.Start()) {
GetContentFromHardDrive();
}
// Perform operation that requires data from both sources

O, mejor aún, lo que tenía específicamente en mente: tengo un objeto que hace gráficos altamente especializados y tiene un método Begin() y End() (un diseño también presente en DirectX y XNA). En lugar...

using(blitter.BlitOperation()) {
// Do work
}
// Use result

Parece ser más natural y legible, pero ¿no es aconsejable, ya que utiliza la interfaz IDisposable y la declaración de using para propósitos no intencionados? En otras palabras, ¿estaría esto a la par con la carga de un operador de una manera no intuitiva ?

Answer 1

Creo que deberías usar IDisposable para lo que está destinado, y nada más. Es decir, si la mantenibilidad te importa.

Answer 2

Diría que es aceptable: de hecho, lo he usado en algunos proyectos en los que quería que se activara una acción al final de un bloque de código específico.

Wes Deyer lo usó en su programa LINQ to ASCII Art, lo llamó acción desechable (Wes trabaja en el equipo de compilación de C #. Confiaría en su criterio: D):

http://blogs.msdn.com/wesdyer/archive/2007/02/23/linq-to-ascii-art.aspx

class ActionDisposable: IDisposable
{
Action action;
public ActionDisposable(Action action)
{
this.action = action;
}
#region IDisposable Members
public void Dispose()
{
this.action();
}
#endregion
}

Ahora puedes devolver eso desde una función y hacer algo como esto:

using(ExtendedConsoleWriter.Indent())
{
ExtendedConsoleWriter.Write("This is more indented");
}
ExtendedConsoleWriter.Write("This is less indented");

Answer 3

Es un patrón común, pero personalmente, creo que no hay excusa para abusar de esa manera cuando se puede lograr el mismo efecto de una manera mucho más obvia con delegados y / o lambdas anónimos; es decir:

blitter.BlitOperation(delegate
{
// your code
});

Answer 4

Esta es una práctica perfectamente aceptable. Estos se denominan Tipos de Factores, y las Pautas de Diseño de Marco recomiendan hacer esto.

Básicamente, si el tipo envuelve una operación con un tiempo de vida específico, el uso de IDisposable y la declaración de uso se convierten en algo apropiado a considerar.

De hecho, yo también blogueé sobre este tema específico aquí .

Answer 5

Recomiendo en contra de ello; mi creencia es que el código es para comunicarse efectivamente con el mantenedor del código, no con el compilador, y debe escribirse con la comprensión del mantenedor en mente. Intento usar "usar" solo para eliminar un recurso, generalmente un recurso no administrado.

Estoy en minoría. La mayoría de la gente parece usar el "uso" como propósito general "Quiero que se ejecute un código de limpieza incluso si se produce una excepción" mecanismo.

No me gusta esto porque (1) ya tenemos un mecanismo para eso, llamado "try-finally", (2) utiliza una función para un propósito para el que no estaba destinado, y (3) si la llamada al código de limpieza es importante, entonces ¿por qué no es visible en el punto donde se llama? Si es importante entonces quiero poder verlo.

Answer 6

Solo porque puedes (o porque Phil Haack dice que está bien), no significa que debas.

La regla básica: si puedo leer su código y entender qué está haciendo y cuál fue su intención, entonces es aceptable. Si, por otro lado, necesitas explicar lo que hiciste, o por qué lo hiciste, es probable que los desarrolladores junior mantengan el código al margen.

Hay muchos otros patrones que pueden lograr esto con una mejor encapsulación.

La conclusión: esta "técnica" no le compra nada y solo actúa para confundir a otros desarrolladores.