2009-06-26 17 views
8

Como norma general, generalmente pongo las clases en un archivo propio. Visual Studio parece alentar esto, pero ¿qué es apropiado con respecto a las interfaces?do interfaces pertenecen a sus propios archivos

p. Ej.

que tienen clase que implementa la interfaz Foo Bar

public interface IBar 
{ 

} 

public class Foo : IBar 
{ 

} 

parece natural grupo de éstos dentro del mismo archivo hasta que otra clase implementa la interfaz, pero para dedicar un archivo de 2 líneas de código parece excesivo, pero es correcto.

¿Qué es apropiado?

Respuesta

26

Los dividiría en 2 archivos. A menudo descubrí que las clases empiezan a ser inmanejables cuando no están en sus propios archivos.

Imagine que intenta encontrar la clase Foo en un archivo llamado IBar.cs o viceversa.

+0

+ Definitivamente es más manejable tanto manualmente como a través de secuencias de comandos. –

+1

Bueno, si todo lo que hago es extraer una interfaz para probarla, entonces hay un buen lugar para ella en la clase. Cuando hay más de una implementación, se vuelve más atractivo separar las dos. –

2

Dependiendo de la situación, o bien dividir cada interfaz en su propio archivo, o alternativamente tener un archivo Interfaces.cs, donde agrupo las interfaces en un espacio de nombres determinado.

Nunca pondría una interfaz en el mismo archivo .cs como una clase que lo implementó.

3

Dado que el propósito de una interfaz es definir un "contrato" para (potencialmente) múltiples clases de implementación, diría que poner la definición de interfaz en su propio archivo tiene más sentido. Es decir, ¿qué sucede si también quiere hacer que Baz implemente Foo?

0

En términos de encapsulación, cada objeto, ya sea una clase o una interfaz, debe estar en su propio archivo. Incluso si la interfaz solo contiene un método abstracto, el hecho de que esté en un archivo diferente permite una mejor organización y una mejor encapsulación. Puede almacenar esas diferentes interfaces en una carpeta, otorgarle un espacio de nombre apropiado y, por lo tanto, una solución más limpia.

+2

Diría que la encapsulación es una propiedad del código en sí misma, independientemente de dónde esté almacenada en el sistema de archivos. En general, es útil colocar cosas en archivos con nombres útiles, pero eso no forma parte de la IMO de encapsulación. –

2

que tienen sólo dos situaciones en las que me encuentro poniendo múltiples tipos de alto nivel en un solo archivo:

  • Si define varios tipos de delegado. Cada una solo será una declaración única, por lo que tiene sentido tener un archivo Delegates.cs.
  • A veces tiene sentido declarar que un montón de tipos parciales autogenerados implementan un conjunto de interfaces. Una vez más, eso es una línea por tipo:

    // Actualy code is in the autogenerated file 
    public partial class Foo : ICommon {} 
    

Aparte de eso, utilizo un archivo por cada tipo de nivel superior, que va por interfaces, clases y enumeraciones.

1

Sí, tener una interfaz implica que va a tener más de una clase con las mismas definiciones de métodos y propiedades. Tenerlo en un archivo por el momento es conveniente, ya que es fácil de modificar sin cambiar los archivos. A medida que pase el tiempo, usted y otras clases lo usarán, y si tiene que hacer un cambio en el camino, tendrá que buscar y buscar el archivo correcto.

2

Sin duda debe poner la interfaz en su propio archivo. Incluso puede considerar poner la interfaz en su propia biblioteca de clases.Si la interfaz será utilizada por dos clases diferentes en dos bibliotecas diferentes, tiene sentido poner la interfaz en una tercera biblioteca, por lo que no tiene que incluir ninguna implementación específica si desea agregar la interfaz a un nuevo proyecto. En la tercera biblioteca también puede colocar clases que funcionen con clases que implementen la interfaz (public void Cook (IBar x), por ejemplo).

1

Siempre los pongo en archivos separados. Tener más de un tipo por archivo distrae a IMO. Sin embargo, podría hacer una carpeta "Interfaces" para ellos. También creo que no debería modificarlos tan a menudo como sus implementaciones reales, de todos modos, por lo que separarlos al menos promueve un poco.

Cuestiones relacionadas