example - params object[] parameters c#
¿Por qué las directrices del marco.Net recomiendan que no utilice argumentos de ref/out? (10)
Aparentemente, son "confusos". ¿Es eso seriamente la razón? ¿Puedes pensar en otros?
¿Has visto cuántos desarrolladores realmente no entienden ref / out?
Los uso donde realmente son necesarios, pero no de otra manera. Por lo general, solo son útiles si quiere devolver dos o más valores, en cuyo caso vale la pena, al menos, pensar si hay alguna manera de hacer que el método solo haga una cosa. A veces, usar ref / out es el enfoque más apropiado: los diversos métodos TryParse, etc.
¿No es suficiente la complejidad del código? Comparar:
int myValue;
ReadFromSomewhere(ref myValue);
A:
int myValue = ReadFromSomewhere();
Confundir es probablemente la mejor razón. Confundir significa una menor capacidad de mantenimiento y una mayor probabilidad de introducir errores sutiles. Los veo en una vista similar a la declaración de flujo de control "goto". Si bien no es intrínsecamente malo por sí mismo, ha llevado a muchos programas imposibles de leer / comprender a lo largo de las décadas.
Aléjate de todo lo que pueda hacer que tu código sea más confuso de lo necesario.
Una vez dicho esto, esas palabras clave existen probablemente porque los desarrolladores del framework vieron la necesidad de tales cosas. Úselos si no hay una solución adecuada, pero evítelos cuando pueda.
En mi opinión, se consideran un olor de código porque, en general, hay una opción mucho mejor: devolver un objeto.
Si se da cuenta, en la biblioteca .NET solo se usan en algunos casos especiales, a saber, escenarios tipo tryparse donde:
- devolver una clase significaría un tipo de valor de boxeo
- el contrato del método requiere que sea rápido, por lo que el boxeo / desembalaje no es una opción viable.
ref / out significa automáticamente mutabilidad, y la programación funcional con valores inmutables está de moda en estos días. Intente insertar una llamada a Dictionary.TryGetValue en una consulta LINQ. La API requiere declarar variables y arruina cualquier ''fluidez'' en la API.
Eso no quiere decir que este es "el motivo", sino que es un ejemplo de "una razón".
(Ver también
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!181.entry
para comentarios sobre cómo los lenguajes funcionales tratan con tales API.)
ref / out tampoco funciona con los delegados de "Func", por lo que estas API de estilo son menos compostables / reutilizables con algunas otras API que usan delegados.
La razón por la que me dijeron es que el 1.0 GC tuvo problemas cuando se usó ref / out. El GC en 2.0 (y probablemente no 1.1 tampoco) no tiene esos problemas, así que normalmente asumiría que es un legado ahora no útil.
Solo un pensamiento, encuentro que ref / out es útil cuando los argumentos capturan el estado de ejecución en el método objetivo en lugar de capturar datos devueltos. Considere un escenario en el que desee obtener un mensaje de error de un servicio que devuelve un objeto Cliente.
Customer GetCustomerById(int id, out string errorMessage);
Si este método falla, probablemente devolverá un objeto nulo al Cliente o lanzará una excepción. Sin embargo, si quiero saber la causa del error (¿validación? ¿Base de datos?), Utilizaría el argumento out. El argumento errorMessage aquí no tiene nada que ver con los datos, simplemente se usa para capturar lo que está mal con la ejecución del método.
Personalmente, si tengo un método que se espera que devuelva dos o más datos / valores esenciales, reconsideraría el diseño de mi código.
@TraumaPony Estaría bien si nos proporcionara una fuente (URL o algo así) a este .NET framework guidlines.
Deberías devolver objetos. Probablemente sea la razón más probable por la que sugieren no usar ref o out.
"ref" realmente solo se debe usar al pasar valores escalares, pero veo que la gente lo usa a menudo para objetos que se pasan por referencia de todos modos.