Ok, lo bueno de programar en una interfaz es que te permite intercambiar clases específicas siempre que las nuevas clases implementen todo en esa interfaz.C# cuándo programar en una interfaz?
p. Ej. programo mi objeto dataSource en una interfaz para poder cambiarlo entre un lector xml y un lector de base de datos sql.
¿Esto significa que idealmente todas las clases deberían programarse en una interfaz? ¿Cuándo no es una buena idea usar una interfaz?
Cuando se aplica el principio YAGNI.
Las interfaces son geniales, pero le corresponde a usted decidir cuándo le va a pagar el tiempo extra necesario para desarrollarlo. He usado interfaces muchas veces, pero hay muchas más situaciones en las que son completamente innecesarias.
No todas las clases deben intercambiarse flexiblemente con otra clase. El diseño de su sistema debe identificar los puntos donde los módulos pueden ser intercambiables, y usar interfaces en consecuencia. Sería una tontería emparejar cada clase con un archivo de interfaz adicional si no hay posibilidad de que esa clase forme parte de algún grupo funcional.
Cada interfaz que agrega a su proyecto agrega complejidad a la base de código. Cuando trabajas con interfaces, la visibilidad de cómo funciona el programa es más difícil, porque no siempre está claro qué IComponent está rellenando para el trabajo cuando el código del consumidor trata la interfaz explícitamente.
La verdadera pregunta es: ¿qué hace su clase? Si está escribiendo una clase que implemente una interfaz en algún lugar del framework .NET, ¡declarelo como tal! Casi todas las clases de biblioteca simples se ajustarán a esa descripción.
Si, por el contrario, está escribiendo una clase esotérica utilizada solo en su aplicación y que no puede tomar ninguna otra forma, entonces no tiene sentido hablar sobre qué interfaces implementa.
Partiendo de la premisa de "¿Debería implementar una interfaz?" Es defectuoso. Usted ni debería ser ni debería ser. Simplemente debe escribir las clases que necesita y declarar lo que hacen sobre la marcha, incluidas las interfaces que implementan.
Use una interfaz cuando necesite comportamientos diferentes en el mismo contexto. Es decir. si su sistema necesita una clase de cliente que esté bien definida, probablemente no necesite usar una interfaz ICustomer. Pero si espera que una clase cumpla con cierto comportamiento en el "object se puede guardar", que se aplica a diferentes knids de objetos, entonces deberás hacer que la clase implemente una interfaz ISavable.
Otra buena razón para usar una interfaz es si espera diferentes implementaciones de un tipo de objeto. Por ejemplo, si planea un SMS-Gateway que enrutará SMS a través de varios servicios de terceros diferentes, sus clases probablemente implementen una interfaz común. ISmsGatewayAdapter para que su sistema central sea independiente de la implementación específica que utilice.
Esto también conduce a la 'inyección dependecy', que es una técnica para desacoplar aún más sus clases y que se implementa mejor mediante el uso de interfaces de
prefiero codificar tanto como sea posible en contra de una interfaz. Me gusta porque puedo usar una herramienta como StructureMap para decir "hey ... consígame una instancia de IWidget" y hace el trabajo por mí. Pero al usar una herramienta como esta puedo programarticamente o por configuración especificar qué instancia se recupera.Esto significa que cuando estoy probando puedo cargar un objeto simulado que se ajusta a una interfaz, en mi entorno de desarrollo puedo cargar un caché local especial, cuando estoy en producción puedo cargar una capa de la granja de almacenamiento en caché, etc. Programación contra una interfaz me proporciona mucha más potencia que no programar contra una interfaz. Es mejor tener y no necesitar que necesitar y no aplicar aquí muy bien. Y si usted está en la programación SÓLIDA, la forma más fácil de lograr muchos de esos principios es comenzar por programar en una interfaz.
En mi humilde opinión, debe intentar usar interfaces mucho. Es más fácil equivocarse al no usar una interfaz que usarla.
Mi principal argumento al respecto es porque las interfaces lo ayudan a crear un código más comprobable. Si un constructor de clase o un método tiene una clase concreta como parámetro, es más difícil (especialmente en C#, donde ningún framework de burlas gratuito permite burlar métodos no virtuales de clases concretas) para realizar pruebas que son pruebas de unidad REAL .
Creo que si tiene un objeto tipo DTO, que usar una interfaz es excesivo, una vez que se burla puede ser incluso más difícil que crear una.
Si no está realizando pruebas, use inyección de dependencia, inversión de control; y espere nunca hacer nada de esto (por favor, evite estar allí, jeje), entonces sugeriría que se usen interfaces cada vez que realmente necesite tener diferentes implementaciones, o si desea limitar la visibilidad que una clase tiene sobre la otra.
Se recomienda como práctica recomendada hacer que los métodos sean virtuales de forma predeterminada en las clases "concretas", que son completamente simulables. – womp
No hay marcos de burla gratuitos? –
@Steven ninguno que permite burlarse de métodos no virtuales –
Como regla general, creo que es mejor utilizar un poco las interfaces que subutilizarlas un poco. Err en el lado del uso de la interfaz.
De lo contrario, se aplica YAGNI.
Si usa Visual Studio, demorar unos dos segundos para tomar su clase y extraer una interfaz (a través del menú contextual). A continuación, puede codificar a esa interfaz, y apenas se gastó tiempo.
Si solo está haciendo un proyecto simple, puede ser excesivo. Pero en los proyectos de tamaño mediano, intento codificar las interfaces a lo largo del proyecto, ya que facilitará el desarrollo futuro.
+1, es muy fácil extraer una interfaz de la clase utilizando las herramientas de refactorización, por lo que no hay ninguna razón para hacerlo de antemano a menos que sepa con certeza que necesita una interfaz. –