2011-12-23 12 views
19

En C# tenemos que nombrar los parámetros de un método de una interfaz.¿Por qué tenemos que nombrar los parámetros del método de interfaz?

entiendo que incluso si no tenemos que, al hacerlo se ayudar a un lector a comprender el significado, sin embargo en algunos casos no es realmente necesario:

interface IRenderable 
{ 
    void Render(GameTime); 
} 

, diría que lo anterior es tan legible y significativo como el siguiente:

interface IRenderable 
{ 
    void Render(GameTime gameTime); 
} 

¿hay alguna técnica razón por la cual se requieren los nombres de los parámetros de métodos en una interfaz?


Vale la pena señalar que la aplicación del método de interfaz puede utilizar nombres diferentes a aquellos en el método de la interfaz.

+0

creo que haría nombres de los métodos de firma ¡¡¡consistente!!! –

+0

Ver mi último comentario editado. –

+1

a lo que me refiero es que las declaraciones de métodos son consistentes en todas las clases e interfaces ... –

Respuesta

19

Una posible razón podría ser el uso de parámetros opcionales.

Si estuviéramos utilizando 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 utiliza la interfaz, hay parámetros predeterminados en times y lineBreaks, por lo que si se accede a través de la interfaz, es posible utilizar los valores predeterminados, sin los parámetros con nombre, estaríamos no se puede omitir el parámetro times y especificar solo el parámetro lineBreaks.

Solo un FYI, dependiendo de si está accediendo al método Output a través de la interfaz oa través de la clase, determina si los parámetros predeterminados están disponibles y cuál es su valor.

+0

Las interfaces estaban allí antes que los parámetros opcionales y nombrados. :) – CodeCaster

+0

@CodeCaster Buen grito, muy probablemente la razón original, sin embargo, definitivamente es una razón ahora :) Supongo que la posibilidad de características futuras como esta fue la razón por la que los nombraron. – Lukazoid

+0

@Lukazoid, bien hecho. Esa es la respuesta más lógica de cualquier forma que la mires. –

9

No veo ninguna razón que haga de esto un requisito técnico. Pero puedo pensar en una razón particularmente buena:

Como mencionas, los nombres de los parámetros no son necesarios al implementar la interfaz, y se pueden anular fácilmente.
Sin embargo, cuando usando la interfaz, imagine la dificultad si ningún parámetro tiene nombres significativos. Sin inteligencia, sin pistas, nada más que un tipo? Yuck.
Esto tiene que ser la razón principal por la que siempre se requiere un nombre.

+0

además lo hace consistente con las declaraciones de métodos en las clases. – Thilo

+2

"¡imagina la dificultad si ningún parámetro tiene nombres significativos!" - Simplemente escriba algo de Java en Eclipse, la mayoría de los nombres de los parámetros se muestran como "arg0", etc ... – Adam

+1

@codesparkle ¡Suena tan divertido como leer un archivo JavaScript minificado! –

0

Bueno, esta posibilidad casi parece demasiado frívola, pero - tal vez cuando deja que Visual Studio implemente la interfaz y el stub en propiedades y métodos, ¿sabe cómo nombrar los parámetros?

Por otro lado, VS tiene ningún problema genéricamente nombrar controles ...

1

No puedo pensar en ninguna razón técnica válida que las interfaces tienen que tener nombres definidos.

Puedo ver fácilmente una situación en la que los nombres se implementan automáticamente, como los miembros de respaldo para las propiedades implementadas automáticamente en la actualidad.

Sin embargo, creo que probablemente hay 3 razones principales por las que han sido necesarios:

1) Probablemente fue sustancialmente más fácil de implementar la validación de la interfaz en el compilador utilizando las mismas reglas que los métodos actuales. Como solo hace relativamente poco tiempo se introdujeron las propiedades implementadas automáticamente, sospecho que se trata de un cambio de compilador no trivial.

2) Para los idiomas que admiten la auto-creación de los miembros de la interfaz en la clase implementadora (es decir, VB), probablemente sea mucho más fácil crear la implementación de interfaz utilizando nombres predefinidos que tratar de crear nombres sobre la marcha .

3) Como una interfaz puede exponerse fuera de la aplicación de definición, los nombres eliminan la ambigüedad asociada con una interfaz mal definida.

Por ejemplo, el intento de poner en práctica un método de interfaz de:

void Foo(string, string, int) 

lo más probable es que el plomo sustancialmente más confusión que tu ejemplo autodocumentado. Sin embargo, esto es realmente más un problema de usabilidad de interfaz que uno técnico, aunque se podría argumentar que si la interfaz no se puede usar, existe un problema técnico subyacente.

2

Naming método de interfaz parámetros ayuda con la auto-documentación:

Por ejemplo ...

interface IRenderable 
{ 
    void Render(TimeSpan gameTime); 
} 

... dice que más de:

interface IRenderable 
{ 
    void Render(TimeSpan); 
} 
Cuestiones relacionadas