Creo que el título habla por sí solo chicos: ¿por qué debería escribir una interfaz y luego implementar una clase concreta si solo va a haber una implementación concreta de esa interfaz?¿Debo seguir codificando en la interfaz incluso SI SOLO SOLO tendré UNA implementación?
creo que no se debe;)
No hay necesidad de sombra todas sus clases con las interfaces correspondientes.
Incluso si va a realizar más implementaciones más adelante, siempre puede extraer la interfaz cuando sea necesario.
La pregunta es, si solo va a haber una implementación concreta, ¿debería haber una interfaz?
Correcto, pero eso es una pregunta, no una respuesta. –
@Jason: una buena pregunta es a menudo la mejor respuesta (niño, tuve la tentación de escribir eso como una pregunta ;-)) –
Esta es una pregunta de granularidad. No puede saturar su código con interfaces innecesarias, pero son útiles en los límites entre las capas.
Algún día puede intentar probar una clase que depende de esta interfaz. Entonces es bueno que te puedas burlar.
Estoy constantemente creando y eliminando las interfaces. Algunos no valieron la pena y algunos son realmente necesarios. Mi intuición es en su mayoría correcta, pero son necesarias algunas refactorizaciones.
En estos días usamos Mockito (o marcos de prueba similares) para burlarnos de las clases . ¿Esta práctica de crear interfaces para los días en que tenía que crear manualmente una clase de código auxiliar, e inyectar la dependencia en la prueba de su unidad (en lugar de simplemente usar Mockito) para simular la dependencia? Eso tiene mucho sentido para mí si ese es el caso – Atif
"solamente siempre va a tener una aplicación" == famosas últimas palabras
no cuesta mucho para hacer una interfaz y luego derivar una clase concreta de ella. El proceso de hacerlo puede hacer que reconsidere su diseño y, a menudo, conduce a un mejor producto final. Y una vez que lo hayas hecho, si alguna vez te encuentras comiendo esas palabras, como sucede con frecuencia, no tendrás que preocuparte por ello. Ya estás listo. Mientras que de otra manera tienes que hacer un montón de refactorización y va a ser un dolor.
Editado para aclarar: Estoy trabajando en la suposición de que esta clase se extenderá relativamente por todas partes. Si se trata de una pequeña clase de utilidad utilizada por una o dos clases más en un solo paquete, entonces sí, no te preocupes. Si se trata de una clase que se utilizará en múltiples paquetes por varias otras clases, entonces se aplicará mi respuesta anterior.
Siguiendo tus consejos, tendrás una gran pila de interfaces y fábricas sin sentido, y va a ser un dolor. Triplicar el conteo de tu clase solo por el bien de "programar en una interfaz" * * te costará mucho en mantenimiento. –
@Michael Borgwardt: Sí, me di cuenta de que estaba trabajando en una supuesta suposición falsa de la escala de clase. Las interfaces para * cada * pequeña clase son malas. Pero las interfaces para las más importantes que se difundirán son buenas, incluso si crees que solo tendrás una implementación. Es tan fácil que se demuestre que está equivocado en eso, ni siquiera es gracioso, y la refacturación no siempre es fácil. –
dos respuestas contradictorias a un tanto su pregunta:
La mayoría de los sistemas (incluso el "código desechable") evolucionan y cambian mucho más allá de lo que su diseño original tenía para ellos. Las interfaces les ayudan a crecer de manera flexible al reducir el acoplamiento. En general, estos son los signos de advertencia que debe ser la codificación para una interfaz:
Si honestamente puede responder "no" a todas estas preguntas, entonces una interfaz puede ser excesiva. Podría. Pero, una vez más, las consecuencias imprevistas son el nombre del juego en la programación.
La pregunta debería ser: "¿cómo puede estar seguro alguna vez de que solo habrá una implementación concreta?"
¿Cómo puede estar totalmente seguro?
Cuando hayas pensado en esto, ya habrás creado la interfaz y estarás en camino sin suposiciones que podrían ser incorrectas.
Con las herramientas de codificación actuales (como Resharper), realmente no toma mucho tiempo crear y mantener interfaces junto con sus clases, mientras que descubrir que ahora necesita una implementación adicional y reemplazar todas las referencias concretas puede tomar una mucho tiempo y no es nada divertido, créanme.
Debe decidir qué es la interfaz de programación, especificando las funciones públicas. Si no haces un buen trabajo, la clase sería difícil de usar.
Por lo tanto, si decide más adelante, necesita crear una interfaz formal, debe tener el diseño listo para funcionar.
Por lo tanto, debe diseñar una interfaz, pero no necesita escribirla como interfaz y luego implementarla.
Mucho de esto se toma de una Rainsberger hablar por InfoQ: http://www.infoq.com/presentations/integration-tests-scam
Hay 3 razones para tener una clase:
La mayoría de los servicios deben h ave interfaces. Crea un límite, oculta la implementación y ya tiene un segundo cliente; todas las pruebas que interactúan con ese servicio.
Básicamente, si alguna vez quisieras simular una prueba de unidad, debería tener una interfaz.
YAGNI - No vas a lo necesitan de Wikipedia
De acuerdo con los que abogan por el enfoque YAGNI, la tentación de escribir código que no es necesario en este momento, pero podría ser en el futuro, tiene la siguientes desventajas:
* The time spent is taken from adding, testing or improving necessary functionality.
* The new features must be debugged, documented, and supported.
* Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
* Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
* It leads to code bloat; the software becomes larger and more complicated.
* Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
* Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.
Utilizo un enfoque basado en pruebas para crear mi código. Esto a menudo me llevará a crear interfaces en las que quiero proporcionar una implementación ficticia o ficticia como parte de mi accesorio de prueba.
Normalmente no crearía ningún código a menos que tenga alguna relevancia para mis pruebas, y dado que no puede probar fácilmente una interfaz, solo una implementación, eso me lleva a crear interfaces si las necesito para proporcionar dependencias para un caso de prueba .
A veces también crearé interfaces al refactorizar, para eliminar la duplicación o mejorar la legibilidad del código.
Siempre puede refactorizar su código para introducir una interfaz si descubre que la necesita más adelante.
La única excepción a esto sería si estuviera diseñando una API para su lanzamiento a un tercero, donde el costo de hacer cambios en la API es alto. En este caso, podría tratar de predecir el tipo de cambios que podría tener que hacer en el futuro y encontrar maneras de crear mi API para minimizar futuros cambios incompatibles.
Una cosa que nadie mencionó aún, es que a veces es necesario para evitar problemas de depenencia. puede tener la interfaz en un proyecto común con pocas dependencias y la implementación en un proyecto separado con muchas dependencias.
+100 si pudiera, es contraproducente crear interfaces no utilizadas en todas partes. Cuando (si) lo necesita, es trivial refactorizar y extraer uno. – slf
De acuerdo. Una clase interna con una implementación única no necesita una interfaz. La interfaz * podría * ser interesante si forma parte de una API externa, por lo que las personas que usan la interfaz de formas que no ha pronosticado no están obligadas a extender su implementación ... –
¿Qué tal las pruebas? Quiero decir, EasyMock solo crea burlas para las interfaces. – folone