Interfaz C# e implementación en el mismo archivo - ¿buena idea?

Question

Recientemente he visto algunas código C#, donde la declaración de interfaz y la implementación en la que en el mismo archivo, como este

namespace MyNameSpace.Foo 
{ 
    public interface IFoo{ 
     void DoThis(); 
    } 
    public class Foo : IFoo { 
     public void DoThis(); 
    } 
} 

A primera vista parece mal tener declaración y aplicación en el mismo archivo, pero no son prácticos beneficios. p.ej. Cuando vaya a Definición en Visual Studio, la interfaz y la implementación se encuentran en el mismo archivo. Este enfoque no le impide tener otras implementaciones de la interfaz, como puede ser necesaria para la prueba unitaria. Para las interfaces que tendrán una sola implementación, creo que esto puede ser un enfoque pragmático.

¿Una idea buena o mala?

La extensión de la pregunta: ¿Cómo
qué la gente usa Visual Studio para navegar a una aplicación cuando se tiene una referencia de interfaz IFoo myFoo = FooFactory.getFoo(MY_FOO); Si hago clic derecho en IFoo y seleccione Ir a definición que puedo conseguir la declaración de interfaz. ¿Hay alguna manera de obtener la lista de implementaciones de IFoo ya que eso es a lo que realmente me interesa llegar?

Answer 1

Mi recomendación es seguir siempre una regla de un elemento por archivo .cs, ya sea una declaración de enumeración, interfaz o clase. El nombre del archivo .cs debe coincidir con el nombre de la cosa que contiene.

Regla simple, fácil de seguir. Usamos StyleCop internamente para vigilar esto.

Si combina este enfoque con un uso razonable de los espacios de nombres, entonces debería significar que su vista de explorador de soluciones en Visual Studio hace que sea más fácil navegar por los componentes en sus proyectos. Tenga en cuenta que ReSharper gives an alternative approach a esta navegación, pero usar esto no es para todos los gustos (y no todos pueden tener un complemento como ReSharper).

Travis G ha preguntado acerca de los puntos más finos, como los delegados y las declaraciones de EventArgs personalizadas. Como los EventArgs personalizados son clases, los pondría en sus propios archivos (nuevamente, manteniendo la regla simple). Delegados que declararía con la clase que los usa. Si descubrí que tenía muchos delegados que se utilizaron en muchos lugares, podría considerar colocarlos todos en un archivo Delegates.cs (a veces hago esto con constantes, en un archivo Consts.cs).

Sin embargo, algo de esto es ciertamente subjetivo y entrando en los dominios del software religious wars.

Answer 2

Personalmente ...

Si una interfaz sólo es probable (a corto plazo) que se utilizará para una clase (como cuando se proporciona una interfaz para la inyección de dependencias) entonces voy a ponerlo en la parte superior de la archivo de clase. Durante el desarrollo (cuando la clase puede estar cambiando) es un PITA tener que cambiar dos archivos cada vez que cambia la superficie pública.

Por supuesto, si existe la posibilidad de que la interfaz sea implementada por más de una clase, entonces la coloco en un archivo separado.

Answer 3

Tener la definición e implementación de la interfaz en el mismo archivo no tiene nada que ver con la prueba unitaria, ya que esa interfaz estará disponible de todos modos.

Generalmente comienzo con una interfaz simple e implementación en el mismo archivo. Cuando las cosas crecen, las divido cuando otro código necesita hacer referencia a esa interfaz.

Answer 4

Me limitaría a seguir la regla de "una clase, un archivo".Con clase también me refiero a interfaces, enumeraciones, etc.

¿Y qué hay de malo en poner el cursor sobre el nombre de la interfaz y presionar F12?

Answer 5

Seguro que no hace daño tenerlo así, y las herramientas como resharper colocarán la implementación debajo de la interfaz en el código. Sin embargo, también le dan la opción de mover la implementación a otro archivo.

Tiene razón, no le impide aprovechar los beneficios de las interfaces para la prueba unitaria, pero es posible que desee considerar poner las interfaces en otro ensamblaje por completo. De esta forma, podría programar contra interfaces e intercambiar implementaciones a voluntad, dándole más separación. Como siempre, no hay una respuesta correcta o incorrecta, todo se reduce a lo que estás tratando de lograr.

Answer 6

Hago eso en Java para interfaces pequeñas con pocos métodos. En este caso, proporciono una o más implementaciones básicas en el archivo de interfaz.

Esto evita clases pequeñas dispersas.

Pero no puedo decir si es una mala o las mejores prácticas, aunque mis compañeros de trabajo nunca se quejaron.

Answer 7

Considero que esta es una mala idea.

Mantenga la interfaz y la implementación separadas. De lo contrario, hay posibilidades de desordenar el diseño. Incluya el archivo y obtenga automáticamente la implementación incluso si solo desea la interfaz, luego accidentalmente (porque es conveniente) use el Impl en lugar de la interfaz y, por supuesto, cierre de acoplamiento.