parameter - default value method c#
¿Parámetros opcionales de C#o sobrecarga del método? (6)
El Análisis de código en Visual Studio y FxCop recomienda que no use argumentos opcionales en las API públicas (regla CA1026: los parámetros predeterminados no deben usarse ). La razón dada es que no todos los lenguajes .NET los admiten.
Sin embargo, creo que una razón mejor para evitarlos es que pueden presentar problemas de tiempo de ejecución o de compilación si agrega más sobrecargas en una versión 2.0 de su API. Phil Haack lo explica aquí .
Voy a adoptar la conclusión de Phil: los parámetros opcionales fueron diseñados para soportar la interoperabilidad COM; Si no estás usando COM, déjalos en paz.
Esta pregunta ya tiene una respuesta aquí:
Dado que los parámetros opcionales agregados de C # se consideran una mejor práctica para usar parámetros opcionales o sobrecargas de métodos o hay un caso particular en el que desearía usar uno sobre el otro. Es decir, ¿una función con muchos parámetros sería mejor adaptada con parámetros opcionales?
En lugar de sobrecargar o nombrar parámetros opcionales, me han gustado mucho los inicializadores de objetos. Todo lo que necesita en la clase es un constructor sin parámetros y propiedades públicas para cualquier cosa que desee establecer en la inicialización.
Suponiendo que la Barra de clase tenga propiedades de cadena públicas "Nombre" y "Mascota", puede construir un nuevo objeto como este.
var foo = new Bar { Name = "Fred", Pet = "Dino" };
La ventaja es que no necesita una sobrecarga separada para cada combinación de valores que desea inicializar.
Los parámetros opcionales están bien, pero deben usarse cuando tenga sentido. Los parámetros opcionales a menudo enturbian la intención del método: si hay otra alternativa, me inclino por la alternativa.
Parte de la necesidad de parámetros opcionales y parámetros con nombre es porque COM permitió parámetros opcionales y de nombre:
MSDN
Algunas API, especialmente las interfaces COM, como las API de automatización de Office, están escritas específicamente con los parámetros nombrados y opcionales en mente. Hasta ahora ha sido muy doloroso llamar a estas API desde C #, ya que a veces se deben pasar explícitamente hasta treinta argumentos, la mayoría de los cuales tienen valores predeterminados razonables y podrían omitirse.
SomeNewKid de forums.asp.net lo pone de manera sucinta:
http://forums.asp.net/t/386604.aspx/1
... los métodos sobrecargados son generalmente preferibles a los parámetros opcionales. ¿Por qué? Para mantener cada uno de sus métodos claros en el propósito. Es decir, cada método debe hacer una cosa bien. Tan pronto como introduce parámetros opcionales, está diluyendo la limpieza de ese método e introduciendo una lógica de bifurcación que probablemente sea mejor mantener fuera de un método. Esta claridad de propósito se vuelve aún más importante cuando empiezas a usar la herencia. Si reemplaza un método que tiene uno o más parámetros opcionales, es más difícil trabajar con ellos. Por lo tanto, sugeriría que para cualquier otra cosa que no sean clases rápidas y sucias, use la sobrecarga en lugar de los parámetros opcionales.
Tenga en cuenta que los parámetros opcionales son un azúcar sintáctico:
Reflector C #:
public class Class1
{
// Methods
public Class1()
{
this.Method1("3", "23");
}
public void Method1(string one, [Optional, DefaultParameterValue("23")] string two)
{
}
}
ILLINOIS:
.class public auto ansi beforefieldinit Class1
extends [mscorlib]System.Object
{
.method public hidebysig specialname rtspecialname instance void .ctor() cil managed
{
.maxstack 8
L_0000: ldarg.0
L_0001: call instance void [mscorlib]System.Object::.ctor()
L_0006: nop
L_0007: nop
L_0008: ldarg.0
L_0009: ldstr "3"
L_000e: ldstr "23"
L_0013: call instance void WebApplication1.Class1::Method1(string, string)
L_0018: nop
L_0019: nop
L_001a: ret
}
.method public hidebysig instance void Method1(string one, [opt] string two) cil managed
{
.param [2] = string(''23'')
.maxstack 8
L_0000: nop
L_0001: ret
}
}
Los parámetros opcionales están destinados a facilitar las interacciones de los objetos COM, ya que los objetos COM usan muchos parámetros opcionales. Así que si estás haciendo cosas de objetos P / Invoke o COM, prefieres parámetros opcionales. De lo contrario, la sobrecarga de métodos es el camino correcto, ya que ahorra mucha confusión.
Los parámetros opcionales requieren un valor predeterminado (solo asumo), y por lo tanto, en algunos casos puede ser difícil proporcionar uno. ¿Por qué? Bueno, algunas clases necesitan información de tiempo de ejecución para inicializarse, lo que puede no estar disponible para el compilador.
Cuando se trata de tipos primitivos, la respuesta puede tener que ver con si se puede asumir un valor predeterminado, o si la ausencia de un parámetro puede significar un comportamiento diferente según el método.
No estoy seguro de que haya una respuesta canónica para esto, es subjetiva y caso por caso. Sin embargo, en mi opinión, los parámetros opcionales crean API más explícitas y, por lo tanto, generalmente los prefiero a las sobrecargas de métodos.
Específicamente, cuando trabajo con Intellisense, prefiero ver esto:
Más allá de esto:
Cuando tenga que adivinar (o buscar documentación) cuál será el valor de param1 y param2 si no especifico.