¿Los parámetros de "salida" son algo malo en .NET?

Question

¿Los parámetros de "salida" son algo malo en .NET? ¿Algún buen artículo/discusión sobre este tema?

Answer 1

Bueno, tengo an article on what ref/out do - pero no discute si deberías usarlos o no.

Básicamente out Los parámetros son generalmente un signo de que desea devolver efectivamente dos resultados de un método. Eso es generalmente olor a código, pero hay algunos casos (sobre todo con el patrón TryXXX) en los que realmente desea devolver dos elementos de información por buenas razones y no tiene mucho sentido encapsularlos juntos.

En otras palabras, evite los puntos afuera/ref donde pueda hacerlo fácilmente, pero no se salga de su camino para evitarlos.

Answer 2

En la mayoría de los casos, recomendaría no utilizar los parámetros de Salida. Básicamente, agregan efectos secundarios a su código y podrían ser una pesadilla cuando se trata de depuración.

Hay un artículo en MSDN respecto Sale parámetros disponibles aquí: http://msdn.microsoft.com/en-us/library/t3c3bfhx.aspx

Answer 3

creo que son realmente útiles cuando sea necesario.

Un artículo Msdn para los dos parámetros de ref y out.

Answer 4

Buena pregunta. Mi respuesta es que no me gustan particularmente, pero los uso en uno de mis proyectos donde los valores de devolución múltiples son comunes. Tengo una biblioteca de datos financieros que devuelve el precio real (o nulo/cero), un código de error importante y un código de error menor. La biblioteca tiene de docenas a cientos de métodos, y cada código de error es de un tipo diferente, por lo que crear clases personalizadas para cada uno y devolver una instancia de eso sería muy difícil de manejar.

Answer 5

FxCop no creo que sea una buena idea ...

http://msdn.microsoft.com/en-us/library/ms182146(VS.80).aspx

Answer 6

Sale parámetros son útiles cuando se necesita para devolver más de un objeto como resultado de una función. A mis ojos,

void doSomeThing(Thing toDoItTo, 
       out OtherThing result1, 
       out AnotherThing result2) 
{ 
    ... 
} 

OtherThing y; 
AnotherThing z; 

doSomeThing(x, out y, out z); 

y.method1(); 
z.method2(); 

es mucho más limpio que

struct DoSomeThingResults 
{ 
    public OtherThing Result1; 
    public OtherThing Result2; 
} 

DoSomeThingResults doSomeThing(Thing toDoItTo) 
{ 
    ... 
} 

DoSomethingResults results = doSomeThing(x); 

results.Result1.method1(); 
results.Result2.method2(); 

y, además, el uso de parámetros out significa que los resultados están garantizados para ser asignado.

Answer 7

En ausencia de tuplas, a veces son la forma más limpia de hacer las cosas. En general los odio, sin embargo.

F # tiene un buen azúcar sintáctico para tratar con ellos. En lugar de hacerme lidiar con los parámetros out, los trata como métodos que devuelven tuplas. Los diversos métodos TryParse terminan regresando dos tuplas de elementos:

let success, value = Int32.TryParse("1234") 
(* success is true *) 
(* value is 1234 *) 

Es bastante práctico, y no me hace sentir sucia.

Answer 8

no es del todo malo para utilizar la salida

vamos a tratar debe precisar los beneficios:

using ref force us to initialize it so we are letting the ref variable to place in heap and consume some spaces . 

in most cases we return null if the operation has some none logic conditions 

but with Out we avoid consuming the heap and refspace