.NET - ¿Puede sobre la interfaz, y cuándo no debe interactuar

Question

¿Es posible sobre la interfaz? cuando diseñe un sistema ahora, comenzaré desde interfaces y escribiré progresivamente pruebas unitarias junto con las interfaces hasta que tenga un patrón que funcione bien ... Pasaré a escribir algunas clases concretas y estableceré las pruebas unitarias contra estas ...

Ahora soy alguien que ama las interfaces, que por lo general terminan solamente nunca pasa/o interfaces de regresar primatives cuando yo controlo el código .. hasta ahora he encontrado que esto es lo ideal, se puede adaptar con facilidad y mejorar un sistema generalmente sin afectar los sistemas dependientes.

Yo, obviamente, no necesito vender las razones para el uso de interfaces, pero estoy preguntando si la borda para interconectar todo, ps. Estoy no hablando de interfaces de blanco como en algo loco como:

interface IStringCollection : ICollection<string> 
{ 
} 

Estoy hablando más algo como:

interface ISomethingProvider 
{ 
    ISomething Provide(ISomethingOptions options); 
} 

Lo que tienes es sobre la parte superior? mi razonamiento es que cualquier tipo podría ganar al interactuar en algún momento ... y el único problema real que he tenido es que he tenido que aprender lo que creo que es una mejor forma de diseñar clases, ya que no tienes tonterías interacciones y 'hacks' pasando.

Me encantaría sus comentarios acerca de si esto es una bomba de tiempo, y cuando se decida a interactuar vs .. no

ps esto no es realmente mucho acerca de cómo escribir interfaces.

Answer 1

ISwissArmyKnife!

Consulte este:

http://thedailywtf.com/Articles/Classic-WTF-Implements-ISwissArmyKnife.aspx

Answer 2

puede ser un verdadero dolor de cabeza para elaborar la pila de llamadas antes de una eventual paso con el depurador si tiene interfaces de todas partes. Yo tiendo a preferir las interfaces sólo cuando:

1. que necesitan los miembros del equipo a un acuerdo sobre quién debe hacer qué antes de empezar a codificar - una interfaz a continuación documenta la frontera exactamente
2. cuando realmente se necesita una interfaz para resolver el problema , por lo que al menos dos implementaciones que no se extienden entre sí
3. Se esperan caso 2

Answer 3

encuentro que complica el diseño de interfaces, especialmente para otras personas a Cowork en su materia. No me malinterpreten, las interfaces son geniales para muchas cosas, pero sobre todo si desea que dos o más clases compartan una interfaz común.

Si usted se encuentra en la situación en la que de repente necesita una interfaz, con herramientas como refactorización ReSharper es una brisa :)

Answer 4

Al igual que con cualquier otra cosa - usar con moderación y, cuando sea necesario. Pregúntese "¿Lo va a necesitar?".

Answer 5

Interfaces describen un contrato de comportamiento. Si necesita abordar un conjunto de objetos de acuerdo con un patrón de comportamiento, las interfaces son útiles, no tanto si simplemente describe la estructura de los objetos.Creo que debe tener una buena razón para usarlos, como usar una fábrica que crea objetos relacionados con el comportamiento o establecer un contrato de comportamiento para parte de una biblioteca. Usar interfaces sin rumbo puede hacer que una biblioteca sea difícil de leer/comprender/mantener.

Answer 6

Esto no es solo algo de .NET, el mismo problema ocurre en Java con bastante frecuencia.

A menos que sea un requisito completamente obvio, yo voto por no usar interfaces y simplemente refactorizar cuando la necesidad se vuelve clara.

El enfoque pragmático dice simplemente hacer el lo más simple que podría funcionar, y no quedar atrapado en la arquitectura astronáutica.

Answer 7

En resumen, sí, es posible sobre la interfaz de un proyecto. Tenga en cuenta que cuando la situación realmente requiere una clase base abstracta y una interfaz, mientras que ambas son similares, existen ventajas claras al usar See Here. Por lo general, he notado que las personas usan interfaces cuando deberían usar clases base abstractas. Desde una perspectiva de OO, las interfaces deben usarse para enumerar comportamientos comunes que pueden abarcar clases muy diferentes. Por ejemplo, puede tener una interfaz IMove con un método llamado Move(). Ahora imagine que tiene una clase de avión, automóvil, persona e insecto. El avión y el coche pueden heredar de una clase de vehículo abstracta, pero todavía necesitan usar IMove y también lo harán Insect y Person, pero todos implementarán el movimiento de manera diferente. Me he dado cuenta, mi yo incluido, las personas tienden a utilizar interfaces para "agrupar" clases juntas cuando realmente eso debería ser manejado por una clase base.

Answer 8

Tiendo a no utilizar demasiadas interfaces para fines de prueba. Prefiero hacer un valor público privado y/o separar las clases y/o los métodos temporales mientras construyo y pruebo hasta que esté en el punto donde construí otros objetos y pruebas que eventualmente ejercerán lo que necesitaba. A veces es un dolor en el trasero hacer cambios de esa manera, pero tus pruebas te dirán cuándo olvidaste cambiar algo.

Answer 9

Es posible hacer una interfaz excesiva. La regla donde trabajo es que si tiene una interfaz en su aplicación, necesita tener al menos dos clases que la implementan (o tiene una expectativa razonable de que agregará clases de implementación en el futuro cercano).

Si necesita crear simulacros de objetos para realizar pruebas, tener la clase simulada y la clase real implementando una interfaz común es una razón válida para usar una interfaz.

No recomendaría automáticamente el uso de interfaces para todo en su aplicación, especialmente porque una sola clase generalmente puede refactorizarse fácilmente en una interfaz si es necesario.

Answer 10

Cada vez que veo o escucho a alguien decir esto

Interfaces describen un contrato para el comportamiento

Sé que he encontrado a alguien que no entiende las interfaces.

Interfaces no hacer eso. Es imposible. Las interfaces no prescriben, fuerzan o de ninguna manera limitan el comportamiento.

Interfaces describen un contrato para un interfaz, de ahí el nombre. Ellos no tienen comportamiento.

Puede esperar que los nombres que le dé a los métodos de su interfaz implicarán un comportamiento obligatorio para cualquiera que lo implemente, pero no es necesario que lo hagan. No hay contrato de comportamiento, ni puede haber uno.

Si requiere un cierto tipo de comportamiento, entonces debe usar clases para aplicarlo (por ejemplo, con el patrón de Plantilla) - ahí es donde está todo el comportamiento.

Las interfaces se abusan regularmente como una construcción de diseño, y una de las razones es debido a la creencia generalizada en esta falacia.