net interfaces español asp .net inheritance interface graph-theory composite

.net - interfaces - interface asp net



¿Cuándo se necesitan interfaces? (15)

"El chico de arriba dice que crea otra interfaz para manejar los nuevos miembros. Nada se rompe.

¿No es esa composición? ¿Por qué no usar composición sin interfaces? Mas flexible."

Parece que estás pensando en la composición en términos de herencia, como en "Heredaré todas estas capacidades en este único objeto para hacer este trabajo". Esa es una mala forma de escribir código. Es como decir: "Quiero construir un rascacielos, así aprenderé cada trabajo que hay que saber, desde cómo crear los planos hasta cómo sentar las bases e instalar la iluminación ..."

Piense en la composición en lugar de objetos separados que cada uno realiza una sola tarea. Para hacer un trabajo complejo, ahora puedo confiar en estos objetos separados para realizar sus tareas individuales. Es como contratar al arquitecto y al equipo de construcción para construir el rascacielos. No necesito saber en gran detalle cómo hacen cada uno su trabajo, solo que pueden hacerlo. En el código, esto significa inyectar dependencias en un objeto para realizar tareas complejas en lugar de heredar.

Entonces, ¿dónde encajan las interfaces? Son el contrato entre los objetos individuales. Le permiten la capacidad de no preocuparse por implementaciones individuales y concretas. Le permiten hablar un idioma común con un grupo de objetos que comparten la misma responsabilidad, pero que en realidad pueden tener una implementación diferente. La interfaz se convierte en una abstracción del objeto que realiza la tarea. No necesito saber cómo funciona cada chico con un martillo, solo que sabe cómo HitNail ().

Cuando comienzas a componer un sistema complejo de código con muchas clases pequeñas que tienen responsabilidades únicas, pronto aprendes que puedes enfrentarte a serios problemas si confías demasiado en la implementación concreta de una clase determinada, y esa clase comienza a cambiar. ... Entonces, en lugar de confiar en la implementación concreta, creamos una interfaz, una abstracción. Y decimos: "No me importa cómo trabajas con JobX, solo que lo haces".

Existen otros beneficios para interfaces como pruebas, burlas, etc. Pero esas no son la razón para codificar una interfaz. El motivo es crear un sistema de código que no dependa de detalles y, por lo tanto, esté altamente acoplado entre sí. Esta es la razón por la cual, con su cerebro de pensamiento gráfico, debería tener miedo de juntar un montón de clases concretas. Porque los cambios en una de esas clases causarán un efecto dominó.

Cuando te combinas con una abstracción en lugar de una clase concreta, limitas el acoplamiento. Dices que solo voy a estar unido al contrato en el que ambos estamos de acuerdo, y nada más ". Y si la clase que implementa ese contrato cambia su forma interna de completar su tarea, no le importa, porque no está confiando en una propiedad o método sin contrato. Usted se basa únicamente en el contrato acordado.

(En el contexto de .NET por lo que vale)

Tiendo a no utilizar la herencia y rara vez uso interfaces. Me encontré con alguien que piensa que las interfaces son lo mejor desde Spit. Él los usa en todas partes. No entiendo esto y de ahí las preguntas que siguen. Solo quiero verificar mi comprensión de las interfaces.

Si está utilizando interfaces en todas partes, asumo que puede predecir el futuro, los requisitos de su aplicación están definidos y nada cambiará en su aplicación. Para mí, especialmente durante el desarrollo temprano, las interfaces se vuelven un lastre. La aplicación es muy dinámica a lo largo de su vida. Si necesita restar o agregar miembros a la interfaz, muchas cosas se romperán. El chico de arriba dice que crea otra interfaz para manejar los nuevos miembros. Nada se rompe

¿No es esa composición? ¿Por qué no usar composición sin interfaces? Mas flexible.

¿Cómo maneja el caso donde un miembro debe ser restado de la interfaz? Básicamente no lo hace. Las cosas simplemente se rompen y eso es genial porque ahora puedes ver todas las áreas afectadas y arreglarlas. En lugar de averiguar más elegantemente dónde están todas las rutas de código relacionadas, ¿deberíamos arrancar partes de las clases a través de la fuerza bruta?

Pienso en una aplicación de software como un gráfico. Un gráfico completo es el peor caso, teniendo n (n-1) / 2. Esto significa que cada clase habla a cada clase. Una tela de araña confusa. n-1 es el mejor, en el que se trata de una estricta jerarquía de comunicación. Agregar otra interfaz solo para compensar un nuevo miembro necesario agrega una vertici al gráfico, lo que significa más bordes y una mayor realización de la ecuación n (n-1) / 2. La composición sin interfaces se parece más a mixins. Solo las clases seleccionadas usan métodos particulares. Con una interfaz, todas las clases están obligadas a usar miembros, incluso si no los necesitan. El enfoque composition / mixin no agrega nuevos bordes innecesarios.

De acuerdo con wikipedia ,

El uso principal del polimorfismo en la industria (teoría de programación orientada a objetos) es la capacidad de los objetos pertenecientes a diferentes tipos para responder a llamadas de método, campo o propiedad del mismo nombre, cada una según un comportamiento específico de tipo apropiado. El programador (y el programa) no tiene que saber el tipo exacto del objeto por adelantado, por lo que el comportamiento exacto se determina en tiempo de ejecución (esto se denomina vinculación tardía o vinculación dinámica).

Eso es lo que hace que las interfaces sean tan útiles.

"El chico de arriba dice que crea otra interfaz para manejar los nuevos miembros. Nada se rompe".

Solo estoy adivinando aquí, pero parece que este tipo viene de un fondo COM de la vieja escuela (¡podría estar equivocado, por supuesto!). Me avergüenza pensar en todo el código en el que he trabajado, donde he visto cosas como esta:

  • IWidgetManager
  • IWidgetManager2
  • IWidgetManager3

Esa no es una buena forma de trabajar con interfaces. En mi experiencia, he visto ambos extremos: miedo a cambiar las interfaces hasta el punto en que se crean nuevas interfaces cada vez que se agregan nuevos miembros, o no se usan interfaces en absoluto y se tiene un producto que sufre un alto grado de coupling . Debes encontrar un buen equilibrio. No siempre es el fin del mundo cambiar una interfaz.

¿Cuál es el tamaño del proyecto en el que estás trabajando? Puede ser difícil ver el beneficio de las interfaces si se trata de un proyecto de tamaño relativamente pequeño. Si, por otro lado, es un proyecto con varios cientos de miles de líneas de código y se compone de muchos módulos, los beneficios se vuelven mucho más evidentes.

El uso principal de una interfaz es permitir la variación de la implementación permitiendo el cambio de código en tiempo de ejecución. Hay una serie de razones / razones para hacer esto.

En el pasado, algunos han argumentado que cada clase en el sistema debe tener una interfaz, pero esto es ampliamente reconocido como overkill. Las interfaces se usan ahora donde las instancias de clases pueden cambiar como parte de la operación del sistema (para representar el estado): patrones GoF como Estrategia y Comando capturan este uso, y / o partes del sistema deben ser reemplazadas para pruebas (es decir, dependencia). inyección). Si los desarrolladores siguen las prácticas de desarrollo basadas en pruebas, los objetos clave de la infraestructura tendrán interfaces. Esto permite que las pruebas hagan "burlas" de estos objetos para probar el flujo de control del sistema. Existe una relación entre este uso de la interfaz y el Principio de sustitución de Liskov (uno de los principios del diseño OO)

Un uso adicional para las interfaces que está menos preocupado por lo que está disponible para la persona que llama, es la interfaz de marcador. Que es una forma de asociar metadatos con la definición de clase. Esto puede afectar la forma en que el sistema ve el objeto (por ejemplo, permitir que se serialice) o simplemente puede servir como documentación.

Esta persona parece haber malinterpretado el concepto de programación en una interfaz. No se refiere a la programación utilizando solo la palabra clave de interface en .Net / Java o clase con nada más que funciones virtuales puras en C ++. La interfaz a la que se hace referencia en ese principio es una construcción de alto nivel que encapsula el bajo nivel unos de un sistema. Al igual que con la multiplicación, encapsula la idea de agregar un número a sí mismo una cantidad específica de repeticiones. Pero cuando decimos 3 * 2 no nos importa si es 3 + 3, 2 + 2 + 2 o (2 + 2) + 2 donde la parte entre paréntesis está en caché. Mientras recibamos un 6 de él.

Como cuestión de hecho, el concepto de interfaces puede ser llenado por una interface o abstract class o una combinación de estos como es el caso con muchos de los patrones GoF. Es solo que la palabra clave de la interface nubla el agua con ambigüedad.

Es gracioso. El tipo de pensamiento de este tipo probablemente sea el que generó comentarios como los que se centran en el episodio # 38 de .

Las interfaces lo ayudan a mantener las dependencias de las abstracciones.

El código que usa la interfaz solo depende de la interfaz, para que sepa que no hay dependencias artificiales en los detalles. Esto le da mucha libertad en cuanto al cambio de código en el futuro, ya que sabe exactamente lo que debe y no debe romperse cuando ''arregla'' un error o refactor.

En mi opinión, es la esencia del buen diseño del código.

Las interfaces no obligan a las clases a usar métodos. Obligan a implementar clases para implementar todos los métodos, pero esa es una cuestión diferente.

Me gusta la forma en que las interfaces separan la API de la implementación. Es cierto que esto también se hace con modificadores de acceso, pero las interfaces lo hacen más claro. Lo que es más importante, las interfaces también facilitan la burla, lo que significa que puede probar las clases en unidades dependientes de la interfaz incluso antes de haberla implementado.

Y sí, esto significa que a menudo termino con una interfaz que solo tiene una implementación de producción única. Eso no es un problema en mi opinión, porque he ganado la capacidad de prueba.

Por otro lado, no escribo una interfaz para cada clase. Me gusta escribir interfaces donde un objeto esencialmente proporciona un servicio : autenticación, acceso a datos, etc. Los objetos de datos simples (incluso con un comportamiento significativo) no son tan útiles en términos de interfaces, IME.

Las interfaces tienen más sentido para mí en el contexto de la inyección de dependencia y los marcos de IoC. Me gusta la idea de que pueda definir un conjunto de comportamientos (métodos) y "garantizar" esos comportamientos a través de la implementación de una interfaz. Ahora puede conectar funciones completamente nuevas en un sistema existente con un solo ensamblaje y una actualización de archivo de configuración.

El diseño eficaz de las interfaces requiere una buena planificación anticipada, y considero que son más útiles en el contexto de sistemas y marcos grandes. Cuando son útiles, son realmente útiles. Algunos de mis favoritos:

  • IComparable (USTED decide cómo se comparan sus objetos entre sí)
  • IQueryable (LINQ ¿alguien?)
  • IDisposable (mantenga su declaración de using mano)

Me referiría a las pautas de diseño .net en esto: http://msdn.microsoft.com/en-us/library/ms229013.aspx

Hay muchas razones para usar interfaces, pero también creo que a menudo se usan en exceso por las razones equivocadas. Las interfaces proporcionan mucha más flexibilidad cuando se trabaja con tipos de valor, y son increíblemente útiles cuando se trabaja con colecciones, etc., pero al diseñar una jerarquía de clases para mis propios proyectos, siempre trato de pensar en la simplicidad primero, y las interfaces a menudo conducen (innecesariamente) situaciones más complejas.

Mi regla general es implementar cada interfaz BCL que tenga sentido, y solo agregar mis propias interfaces en mis diseños cuando en realidad proporciona algo muy valioso. En lugar de tener IWidgetManager, IWidgetManager2, etc ... Preferiría tener WidgetManager de clase abstracta e implementar métodos concretos según sea necesario.

Parece que tu amigo estaba usando mal las interfaces.

También he visto aplicaciones web con interfaces por todos lados. Algunas personas parecen tener la idea de que una interfaz es de alguna manera mejor que solo una firma de método regular. Los parámetros simples ya nos proporcionan un contrato; en la mayoría de los casos, creo que esto es suficiente y hace que el código sea más simple.

Me parece que las interfaces son más útiles en casos como IDisposable o ICollection, donde apuntan a un cierto conjunto de funcionalidades que se esperan de un objeto. En estos casos, parecen ser la herramienta adecuada para el trabajo.

Se trata de dependencias. Desea que su código dependa de los tipos de interfaz en lugar de los tipos concretos cuando corresponda. Por ejemplo, es posible que tenga varios tipos concretos que realizan un comportamiento similar pero que lo implementan de forma diferente. ¿Desea que su base de código tenga dependencias en esos múltiples tipos concretos, o una interfaz? ¿Cuán flexible crees que será tu código base cuando necesites hacer cambios?

A su punto sobre no querer usar miembros públicos mediante el uso de la composición, diría que simplemente está encapsulando dependencias innecesarias. Si desea utilizar la composición, entonces reduce en gran medida las dependencias al componer tipos de interfaz en lugar de tipos concretos.

Para una mejor explicación, intente consultar la literatura sobre la inversión del control .

Si quiere saber cuándo utilizar las interfaces y cuál es su uso, creo que debería echarle un vistazo al libro: Head First Desing Patterns .

Este es el libro que realmente me ayudó a entender qué tiene de genial las interfaces.

Antes de leer este libro, sabía lo que era una interfaz, pero no tenía ni idea de cuándo debería usarla.

Una de las razones más importantes para usar una interfaz es el hecho de que nos permiten escribir pruebas de unidad para nuestras clases y pasar en nuestras propias dependencias. Al poner la dependencia detrás de una interfaz, abrimos "Seams" en nuestro código de aplicación, donde las pruebas unitarias pueden escribirse fácilmente. No veo este ángulo de prueba mencionado en muchas de las respuestas, pero es muy importante entender que sin interfaces, estas dependencias (como un servicio web o una referencia del sistema de archivos) pueden ser muy difíciles de probar o, en el mejor de los casos son bastante condicionales He escrito una publicación aquí: http://jeffronay.com/why-use-an-interface/ que entra en mucho más detalle con ejemplos de código que muestran una clase de servicio sin una interfaz, y luego la misma clase reescrito usando una interfaz para demostrar la flexibilidad de prueba cuando se utilizan interfaces.

Usamos interfaces en elementos de IU personalizados, donde cada uno espera que exista cierto método en otro (y la interfaz fuerza esa existencia).

Las interfaces tienen muchas situaciones útiles. Cuando necesite agregar un comportamiento específico a una clase que se puede encontrar en una amplia variedad de clases, ese es el momento perfecto para una interfaz. Un buen ejemplo es la interfaz IDisposable : tiene algún recurso que, cuando haya terminado, debe desaparecer de manera oportuna. ¿Es una conexión de base de datos? ¿Es un asa de ventana? No importa

Otro ejemplo sería cuando realmente no sabe cómo debe implementarse, como una interfaz para un objeto que aún no existe. Tal vez el objeto debe ser suministrado por un cliente de su biblioteca, o debe ser implementado por un módulo completamente diferente que no esté bajo su control. Básicamente puede diseñar un contrato para los métodos disponibles en la clase.

Dicho esto, solo los uso cuando sea necesario. Si puedo hacerlo con una clase regular, o si es algo intrínseco al objeto en particular, lo convertiré en una clase. El uso de interfaces para cada clase presenta algunas ventajas, como han dicho otros, pero eso implica una sobrecarga adicional de la que no veo una ganancia neta decente. La mayoría de las veces, he diseñado las estructuras de mi clase para que sean planas y anchas, con el menor número de dependencias posible.

En resumen: si necesita una funcionalidad común que se implementa de manera radicalmente diferente, una interfaz es justo lo que necesita.