2012-09-04 11 views
11

No estoy seguro si esto es una pregunta tonta, pero simplemente se dio cuenta de esto:¿Por qué son necesarios los nombres de parámetros en una definición de interfaz? Se me permite elegir nuevos nombres de los parámetros durante la ejecución

public interface IActivityDao : IDao<Activity> 
{ 
    IList<Activity> GetAllSinceSequence(long sequence, int count); 
} 

public class ActivityDao : AbstractNHibernateDao<Core.Domain.Activity>, IActivityDao 
{   
    public IList<Activity> GetAllSinceSequence(long sequence, int maxRecords) 
    { 

    } 
} 

Dentro de mi aplicación que he llamado mi segundo parámetro 'maxRecords.' Sin embargo, en la interfaz, se define como 'conteo'. El compilador aún considera la interfaz implementada, lo cual es bueno, pero puede generar cierta ambigüedad. Claramente, debería cambiar el nombre de uno de los parámetros para que coincida con el otro.

Jugué un poco antes de hacer el cambio de nombre y noté algo interesante. No estoy autorizado para declarar mi interfaz como:

public interface IActivityDao : IDao<Activity> 
{ 
    IList<Activity> GetAllSinceSequence(long, int); 
} 

¿Es sólo el compilador ser excesivamente protector contra symantics C#? ¿Para qué sirven los nombres de los parámetros en el método de una interfaz, aparte de hacer que el código sea más legible? Me parece que invita a la ambigüedad si los nombres de los parámetros no se fuerzan en las implementaciones.

Respuesta

19

Los nombres de parámetros son necesarios en una declaración de interfaz para mayor claridad de implementación y para referencia. Si alguien estaba usando su interfaz, los nombres de los parámetros del método deben documentarse automáticamente para que el consumidor de la interfaz sepa qué pasar al método (por ejemplo, al ver la descripción del método a través de IntelliSense)

Y sí, cuando implemente la interfaz puede nombrar los parámetros como lo desee.

+0

Usted merece más votos favorables. Tienes la mejor respuesta de lejos. Respondió la pregunta del OP de manera muy sucinta. – Enigmativity

+2

Bueno, más o menos. La respuesta, aunque clara, realmente no aborda la última frase de mi publicación. ¿Por qué no hay garantía de que los parámetros se llamarán igual durante la implementación? Si la única intención es auto-documentarse y ser claro, ¿por qué no llevar esa claridad hasta las implementaciones? No quiero anunciar accidentalmente mi método como aceptar 'contar' cuando realmente espero 'maxResults'. –

+3

Porque es posible que desee auto-documentación más específica en el nivel de implementación. Digamos que creó una interfaz IBinaryMathOperation, con un método Execute (int operand1, int operand2). Luego implementó una clase AddOperation implementando la interfaz. Los "operandos" de un método add se conocen más específicamente como "sumandos", y es posible que desee llamarlos en la implementación específica de Execute(). – KeithS

2

Me imagino que esto se debe a la característica de parámetros nombrados en C#. Es decir, tiene que ser capaz de especificar los parámetros por su nombre, no sólo en el orden predeterminado:

IActivityDao dao; 
dao.GetAllSinceSequence(count: 1, sequence: 2); 

Por supuesto, los nombres de los parámetros sería diferente si el objeto se presenta como la instancia.

var concreteDao = (ActivityDao) dao; 
concreteDao.GetAllSinceSequence(maxRecords: 1, sequence: 2); 
+2

Excepto que dicha característica data interfaces de fechas por más de una década. –

+0

@KirkWoll ha ... buen punto. – McGarnagle

2

Déjeme preguntarle esto, ¿hay algún otro lugar en el framework .net que le permita definir una firma de método sin nombres de parámetros?

Al final del día, todo es posible pero la mayoría de las cosas están ahí por algún motivo, en este caso me imagino que este es un límite del diseño del marco y compilador, ¿realmente importa?

Después de todo, está definiendo un contrato de uso, uno esperaría que estuvieran allí realmente.

+0

+1 por mencionar contratos –

1

Muchos idiomas como C# y VB admiten named and option arguments to methods. Sin los nombres de los argumentos en la interfaz, no sería posible usar argumentos nombrados y opcionales. Nombrar los argumentos también ayuda al lector a comprender la intención y la función de la interfaz.

8

Historia. Esto se remonta a los primeros días de .NET, cuando COM gobernaba el mundo. Poder interoperar con COM fue muy importante en ese entonces, nadie tira todo para adoptar un estilo de programación completamente nuevo.

Lo que hace que la interoperabilidad COM sea totalmente compatible con .NET en general. Además de la necesidad de tener argumentos con nombre para los métodos de interfaz, las bibliotecas de tipo los requieren.

El caso de esquina interesante es siempre el lenguaje C++/CLI.Adoptó muchas reglas de sintaxis de C++, incluida la capacidad de omitir nombres de parámetros en declaraciones. En otras palabras, esto es legal:

public interface class IFoo 
    { 
     void bar(int, long, double); 
    }; 

El tipo de biblioteca exportador genera esta declaración:

HRESULT bar(
        [in] long p1, 
        [in] long p2, 
        [in] double p3); 

resultado muy similar si se implementa la interfaz en una clase C#, como autogenerado por IntelliSense:

class FooImpl : cpptemp36.IFoo { 
    public void foo(int __p1, int __p2, double __p3) { 
     throw new NotImplementedException(); 
    } 
} 

Esto no hace feliz a nadie.

Cuestiones relacionadas