usan - porque usar interfaces c#
¿Por qué tenemos que nombrar los parámetros del método de interfaz? (5)
La parametrización del método de interfaz de nombres ayuda con la auto documentación:
Por ejemplo ...
interface IRenderable
{
void Render(TimeSpan gameTime);
}
... dice más que
interface IRenderable
{
void Render(TimeSpan);
}
En C # tenemos que nombrar los parámetros de un método de una interfaz.
Entiendo que incluso si no tuviéramos que hacerlo, hacerlo ayudaría a un lector a comprender el significado, sin embargo, en algunos casos no es realmente necesario:
interface IRenderable
{
void Render(GameTime);
}
Yo diría que lo anterior es tan legible y significativo como lo siguiente:
interface IRenderable
{
void Render(GameTime gameTime);
}
¿Hay alguna razón técnica por la que se requieren nombres para los parámetros de los métodos en una interfaz?
Vale la pena señalar que la implementación del método de interfaz puede usar nombres diferentes a los del método de la interfaz.
No se me ocurre ninguna razón técnica válida para que las interfaces tengan nombres definidos.
Puedo ver fácilmente una situación en la que los nombres se implementan automáticamente, como lo son los miembros de respaldo para las propiedades implementadas automáticamente.
Sin embargo, creo que probablemente hay 3 razones principales por las que se han necesitado:
1) Probablemente fue mucho más fácil implementar la validación de la interfaz en el compilador utilizando las mismas reglas que los métodos reales. Como solo hace relativamente poco tiempo que se introdujeron las propiedades implementadas automáticamente, sospecho que este es un cambio de compilador no trivial.
2) Para aquellos idiomas que admiten la creación automática de los miembros de la interfaz en la clase de implementación (es decir, VB), probablemente sea mucho más fácil crear la implementación de la interfaz utilizando nombres predefinidos que intentar crear nombres sobre la marcha.
3) Dado que una interfaz puede estar expuesta fuera de la aplicación de definición, los nombres eliminan la ambigüedad asociada con una interfaz mal definida.
Por ejemplo, intentar implementar un método de interfaz de:
void Foo(string, string, int)
Lo más probable es que conduzca a una confusión sustancialmente mayor que su ejemplo de auto-documentación. Sin embargo, esto es realmente más un problema de usabilidad de la interfaz que uno técnico, aunque se podría argumentar que si la interfaz es inutilizable, existe un problema técnico subyacente.
No veo ninguna razón para que esto sea un requisito técnico. Pero puedo pensar en una razón particularmente buena:
Como mencionó, los nombres de los parámetros no son necesarios cuando se implementa la interfaz, y se pueden anular fácilmente.
Sin embargo, cuando use la interfaz , imagine la dificultad si ningún parámetro tiene nombres significativos. Sin inteligencia, sin pistas, ¿nada más que un tipo? Puaj
Esta tiene que ser la razón principal por la que siempre se requiere un nombre.
Ok, esta posibilidad casi parece demasiado frívola, pero, tal vez sea así, cuando deja que Visual Studio implemente la interfaz y el apéndice en propiedades y métodos, ¿sabe cómo nombrar los parámetros?
Por otro lado, VS no tiene problemas para nombrar genéricamente los controles ...
Una posible razón podría ser el uso de parámetros opcionales.
Si estuviéramos usando una interfaz, sería imposible especificar valores de parámetros con nombre. Un ejemplo:
interface ITest
{
void Output(string message, int times = 1, int lineBreaks = 1);
}
class Test : ITest
{
public void Output(string message, int numTimes, int numLineBreaks)
{
for (int i = 0; i < numTimes; ++i)
{
Console.Write(message);
for (int lb = 0; lb < numLineBreaks; ++lb )
Console.WriteLine();
}
}
}
class Program
{
static void Main(string[] args)
{
ITest testInterface = new Test();
testInterface.Output("ABC", lineBreaks : 3);
}
}
En esta implementación, cuando se usa la interfaz, hay parámetros predeterminados en times
y lineBreaks
, por lo que si se accede a través de la interfaz, es posible usar valores predeterminados, sin los parámetros nombrados, no podríamos omitir el parámetro de times
y especificar solo el Parámetro de lineBreaks
.
Solo un FYI, dependiendo de si está accediendo al método de Output
través de la interfaz o a través de la clase, determina si los parámetros predeterminados están disponibles y cuál es su valor.