Beneficios de implementar una interfaz.

¿Cuáles son los beneficios de implementar una interfaz en C # 3.5?

Podrá pasar su objeto a un método (o satisfacer una restricción de tipo) que espera la interfaz como un argumento. C # no es compatible con ” escribir pato “. Solo escribiendo los métodos definidos por la interfaz, el objeto no será automáticamente “compatible” con el tipo de interfaz:

public void PrintCollection(IEnumerable collection) { foreach (var x in collection) Console.WriteLine(x); } 

Si la List no implementó la IEnumerable , no podría pasarla como argumento al método PrintCollection (incluso si tuviera un método GetEnumerator ).

Básicamente, una interfaz declara un contrato. La implementación de una interfaz obliga a su clase a estar sujeta al contrato (al proporcionar los miembros apropiados). En consecuencia, todo lo que se basa en ese contrato (un método que se basa en la funcionalidad especificada por la interfaz que proporcionará su objeto) también puede funcionar con su objeto.

El principal beneficio es sobre la legibilidad del código, la capacidad de mantenimiento del código y la “semántica” del código.

  • Código de legibilidad: una interfaz constituye una statement sobre intenciones. Define una capacidad de su clase, lo que su clase es capaz de hacer. Si implementa ISortable, está indicando claramente que su clase se puede clasificar, lo mismo para IRenderable o IConvertible.
  • Código de la semántica: al proporcionar interfaces e implementarlas, se están separando los conceptos de manera similar a como lo hacen HTML y CSS. Una clase es una implementación concreta de una “clase de objeto”, una forma de representar la realidad mediante el modelado de propiedades generales de objetos o conceptos de la vida real. Una interfaz define un modelo de comportamiento, una definición de lo que puede hacer un objeto. Separar esos conceptos mantiene la semántica de su código más clara. De esa manera, algunos métodos pueden necesitar una instancia de una clase animal, mientras que otros pueden aceptar cualquier objeto que les arrojes, siempre que sea compatible con “caminar”.
  • Mantenimiento del código: las interfaces ayudan a reducir el acoplamiento y, por lo tanto, le permiten intercambiar fácilmente implementaciones por el mismo concepto sin que el código subyacente se vea afectado. Puede cambiar la implementación de un IMessage fácilmente definiendo una nueva clase que implementa la interfaz. Compare eso con la sustitución sistemática de todas las referencias de CMessage a CMyNewMessageClass.

Te ayudará cuando trates de:

  • Prueba unitaria con stubs / mocks
  • Implementar dependency injection
  • Resuelve el hambre del mundo (¡aunque esto no probado!)

Amabilidad,

Dan

Las interfaces no proporcionan ninguna ventaja real. Cualquier cosa que se pueda hacer con una interfaz se puede, y se debe hacer usando otras construcciones de lenguaje. La herencia múltiple a menudo se cita como el único beneficio REAL derivado del uso de interfaces, pero puedo hacer la herencia múltiple con bastante facilidad y claridad en C #: lo hago todos los días. Cambiar el código sin “romper” la interfaz es la más tonta de todas las excusas … Eso se aplica a las clases concretas que a las clases o interfaces abstractas. Mientras la firma funcional no cambie, no ha roto la interfaz. No importa donde fue declarado. Simplemente al poner un prototipo funcional en un archivo separado y nombrarlo con una “I” en la parte frontal no se compra nada, excepto que se termina con el doble de archivos de origen para mantener. La suposición de que la interfaz se define antes y luego mantiene el contrato es ridícula. Los métodos de interfaz y sus parámetros cambian TODO el tiempo, porque nunca se conoce todo por adelantado. Es por eso que MicroSof dejó de usarlos hace mucho tiempo. Tenían IUnKnown, IUnknown2, etc. Creó un desastre.

Los principales beneficios de las interfaces están relacionados principalmente con el diseño del proyecto.

Si usas una interfaz:

  1. El consumidor de la interfaz debe implementar esa interfaz.
  2. Diseño de patrones de puentes.
  3. Creación de un contrato para que el usuario debe cumplir con las reglas de la interfaz.
  4. Solo puede tomar parte de la interfaz ( Object ) de la clase principal.
  5. Incluso la clase es privada, puede obtener el objeto de interfaz de ese
  6. Herencia múltiple tipo de estilo.
  7. No es necesario que se implemente, simplemente opte por implementos, lo que significa que si lo desea, puede implementarlo de otra manera, puede soltarlo.
  8. Código más limpio.
  9. Implementación que cambia dependiendo de la clase puede seguir adelante con la interfaz.
  10. Si cada clase tiene una implementación separada de un método mejor ir para interfaces. Por ejemplo IEnumerable en colecciones.

Según C # Architect, en una palabra simple es un contrato. El consumidor debe adherirse a ella.

Una interfaz define un contrato (cosas que un objeto puede hacer), mientras que una clase concreta (o estructura) define el comportamiento concreto.

Para un ejemplo, IList es una interfaz, define los métodos que debe proporcionar un objeto concreto para ser utilizado como cualquier otro objeto que implemente IList. En cualquier lugar donde se pueda usar un IList, su objeto que implementa IList también se puede usar. La manera concreta de implementarlo y la forma en que se comporta su objeto cuando se llaman a esos métodos de IList es algo que le queda.

Si trabaja en una gran casa de software comercial, es posible que desee considerar el uso judicial de Interfaces. De lo contrario, debe mantenerse alejado de ellos. Lo mismo para multihilo. Si veo una aplicación más de script-kiddie que genera 20 hilos para escribir “Hello World”, voy a enloquecer. Los subprocesos múltiples deben estar completamente reservados para las aplicaciones que lo requieran, generalmente en un entorno de procesamiento múltiple. El 90% de las veces causa más daño que bien. Y no se moleste con el hilo comentarios de highjack / off-topic. No me importa He estado haciendo esto más de lo que la mayoría de ustedes han estado vivos. El rango tiene sus privilegios.

No estás atado a la herencia de clase, puedes aplicar una interfaz a cualquier clase. Cualquier clase puede tener múltiples interfaces: C # no admite la herencia de múltiples clases, es decir, está proporcionando una buena capa de abstracción a través de la interfaz

Una interfaz es un tipo de referencia y contiene solo miembros abstractos. Los miembros de la interfaz pueden ser eventos, métodos, propiedades e indexadores. Pero la interfaz solo contiene statement para sus miembros. Cualquier implementación debe ser colocada en clase que las realice. La interfaz no puede contener constantes, campos de datos, constructores, destructores y miembros estáticos. Todas las declaraciones de miembros dentro de la interfaz son implícitamente públicas.

La forma en que entiendo que las interfaces son más útiles en estos casos:

  1. División más limpia del trabajo entre los progtwigdores. El progtwigdor principal escribe la interfaz y el progtwigdor junior escribe su implementación. Eso tiene mucho sentido para mí. Sin embargo, el progtwigdor líder podría escribir pseudocódigo en lugar de interfaz.

  2. Alguna situación específica, donde necesita 2 o más implementaciones diferentes de la misma clase, por ejemplo, interfaz animal y clases tigre y león que lo utilizan. E incluso aquí no tiene mucho sentido, porque los leones y los tigres comparten algunas cosas en común. La clase abstracta sería mejor, porque si usas la interfaz tienes que escribir funciones comunes en clases separadas, lo que conduce a la duplicación de código, lo cual es malo.

  3. Escribes una biblioteca y quieres que sea modificable por los usuarios. Así que escribes interfaz y su implementación de clase. El usuario de su biblioteca todavía tiene la posibilidad de escribir su propia clase de implementación, que puede usar una tecnología / algoritmo diferente que logra el mismo resultado, pero quizás de una manera más rápida, por ejemplo. Esta es también la razón por la que nos encontramos con tantas interfaces en las bibliotecas que utilizamos, pero rara vez sentimos la necesidad de escribir nuestras propias interfaces. Porque no escribimos bibliotecas.