Ventajas de implementar una interfaz

Question

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

Answer 1

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

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

Si List<T> no implementó la interfaz IEnumerable<T>, no sería capaz de pasarlo como un argumento al método PrintCollection (incluso si tenía un método GetEnumerator).

Básicamente, una interfaz declara un contrato. La implementación de una interfaz obliga a su clase a vincularse al contrato (proporcionando los miembros adecuados). En consecuencia, todo lo que dependa de 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.

Answer 2

Ayudará al intentar:

• Unidad de prueba de colillas/Mocks
• Implementar la inyección de dependencias
• resolver el hambre mundial

Bondad, (aunque esto no probado!)

Dan

Answer 3

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

Answer 4

La principal ventaja es la legibilidad del código, el mantenimiento del código y la semántica del código.

• la legibilidad del código: Una interfaz constituye una declaración acerca de las intenciones. Define la capacidad de tu clase, lo que tu clase es capaz de hacer. Si implementa ISortable, indica claramente que su clase puede clasificarse, lo mismo para IRenderable o IConvertible.
• Semántica de código: Al proporcionar interfaces e implementarlas, se separan los conceptos de forma similar a HTML y CSS. Una clase es una implementación concreta de una "clase de objeto", una forma de representar la realidad modelando propiedades generales de objetos o conceptos de la vida real. Una interfaz define un modelo de comportamiento, una definición de lo que un objeto puede hacer. Separar esos conceptos mantiene más clara la semántica de su código. De esta forma, algunos métodos pueden necesitar una instancia de una clase de animal, mientras que otros pueden aceptar cualquier objeto que les arroje, siempre que sea compatible con "caminar".
• Mantenimiento de código: Las interfaces ayudan a reducir el acoplamiento y, por lo tanto, le permiten intercambiar fácilmente implementaciones para el mismo concepto sin que se vea afectado el código subyacente. Puede cambiar la implementación de un IMessage fácilmente definiendo una nueva clase que implemente la interfaz. Compare eso para reemplazar sistemáticamente todas las referencias de CMessage a CMyNewMessageClass.

Answer 5

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

Por ejemplo, IList es una interfaz, define los métodos que un objeto concreto debe proporcionar para ser utilizado como cualquier otro objeto que implemente IList. En todas partes donde se puede usar un IList, también se puede usar su objeto que implementa IList. La forma en que lo implemente concretamente y la forma en que se comporta su objeto cuando se invocan esos métodos IList le queda a usted.

Answer 6

Una interfaz es un tipo de referencia y contiene solo miembros abstractos. Los miembros de la interfaz pueden ser Eventos, Métodos, Propiedades e Indizadores. Pero la interfaz solo contiene una declaración para sus miembros. Cualquier implementación debe colocarse en la clase que los realiza. 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.

Answer 7

Las interfaces no proporcionan ninguna ventaja real. Todo lo que se puede hacer con una interfaz puede, y debe hacerse utilizando otras construcciones de lenguaje. A menudo se cita la herencia múltiple como el único beneficio REAL derivado del uso de interfaces, pero puedo hacer 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 ... Esto aplica lo mismo a las clases concretas que a las clases o interfaces abstractas. Siempre que la firma funcional no cambie, no ha roto la interfaz. No importa dónde fue declarado. Simplemente colocando un prototipo funcional en un archivo separado y nombrarlo con una "I" en frente no compra nada, excepto que terminas con el doble de archivos fuente para mantener. La suposición de que la interfaz se define temprano y luego mantiene el contrato es ridícula. Los métodos de interfaz y sus parámetros cambian TODO el tiempo, porque nunca se sabe todo de antemano. Es por eso que MicroSof dejó de usarlos hace mucho tiempo. Tenían IUnKnown, IUnknown2, etc. Creó un desastre.

Answer 8

Si trabaja en una gran casa de software comercial, es posible que desee considerar el uso judicial de las interfaces. De lo contrario, debes mantenerte alejado de ellos. Lo mismo para multi-threading. Si veo una aplicación script-kiddie más que engendra 20 hilos para escribir "Hello World" voy a enloquecer. Multi-threading debe reservarse por completo para las aplicaciones que lo requieren, generalmente en un entorno de multiprocesamiento. El 90% de las veces causa más daño que bien. Y no te molestes con los comentarios sobre subprocesos de subprocesos/fuera de tema. No me importa He estado haciendo esto por más tiempo que la mayoría de ustedes han estado vivos. Rank tiene sus privilegios.

Answer 9

Los principales beneficios de las interfaces se relacionan principalmente con el diseño del proyecto.

Si utiliza una interfaz:

1. El consumidor de la interfaz debe implementar la interfaz.
2. Diseñando patrones de puente.
3. Creando un contrato para que el usuario debe cumplir las reglas de la interfaz.
4. Puede tomar solo la parte de interfaz (Object) de la clase principal.
5. Incluso la clase es privada, puede obtener el objeto de interfaz de
6. Estilo de herencia múltiple.
7. No necesita ser implementado, simplemente vaya si los implementos significa que si lo desea puede implementarlo de otra manera puede soltarlo ..
8. Código de limpieza.
9. La implementación que cambia depende de la clase puede continuar con la interfaz.
10. Si cada clase tiene una implementación separada de un método, es mejor utilizar interfaces. Por ejemplo IEnumerable en colecciones.

De acuerdo con C# Architect, en una palabra simple, es un contrato. El consumidor debe cumplirlo.

Answer 10

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

1. Limpiador división del trabajo entre los programadores. El programador principal escribe la interfaz y el programador junior escribe su implementación. Eso tiene perfecto sentido para mí. Sin embargo, el programador líder podría escribir pseudocódigo en lugar de la interfaz.

2. Alguna situación específica, donde necesita 2 o más implementaciones diferentes de la misma clase, por ejemplo, interfaz de animales y clases de 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 que conducen a la duplicación de código, lo cual es malo.

3. Usted escribe una biblioteca y desea que los usuarios la puedan modificar. Entonces usted escribe la interfaz y su implementación de clase. El usuario de su lib todavía tiene la posibilidad de escribir su propia clase de implementación, que puede usar diferentes tecnologías/algoritmos que logren 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 conocemos tantas interfaces en libs que usamos, pero rara vez sentimos la necesidad de escribir nuestras propias interfaces. Porque no escribimos bibliotecas.