java - que - Programación contra interfaces: ¿Escribes interfaces para todas tus clases de dominio?
public interface java (15)
Creo que la razón principal para programar contra las interfaces es la capacidad de prueba. Por lo tanto, para los objetos de dominio, simplemente adhiérase a POJO o POC # Os :) etc., es decir, evite que sus clases agreguen un marco específico para evitar que tengan diferentes dependencias de compilación y tiempo de ejecución, y eso es todo. Sin embargo, crear interfaces para DAO es una buena idea.
Estoy de acuerdo con que la programación contra interfaces es una buena práctica. En la mayoría de los casos, en Java, la "interfaz" en este sentido significa la interfaz de construcción del lenguaje, de modo que usted escribe una interfaz y una clase de implementación, y que utiliza la interfaz en lugar de la clase de implementación la mayor parte del tiempo.
Me pregunto si esta es una buena práctica para escribir modelos de dominio también. Entonces, por ejemplo, si tiene una clase de dominio Cliente y cada cliente puede tener una lista de Pedidos, generalmente también podría escribir interfaces ICustomer y IOrder. ¿Y también tendría el Cliente una lista de IOrders en lugar de Orders? ¿O usaría interfaces en el modelo de dominio, solo si está realmente impulsado por el dominio, por ejemplo, tiene al menos dos tipos diferentes de pedidos? En otras palabras, ¿usaría interfaces solo por necesidades técnicas en el modelo de dominio, o solo cuando sea realmente apropiado con respecto al dominio real?
Es otra cosa a tener en cuenta que he corrido, especialmente con objetos generados de dominio y DAO. Muchas de las interfaces son demasiado específicas. Digamos que muchos objetos de dominio tienen una ID y un campo de estado. ¿Por qué no comparten una interfaz común? Esto me ha causado frustración, un modelo de dominio innecesariamente plano (basado en la herencia).
Escribir interfaces "solo porque" me parece una pérdida de tiempo y energía, sin mencionar una violación del principio KISS.
Los escribo cuando son realmente útiles para representar el comportamiento común de las clases relacionadas, no solo como un elegante archivo de encabezado.
Extraemos interfaces de todo solo porque ayuda a probar (burlarse) y cosas como AOP. Eclipse puede hacer esto automáticamente: Refactor-> Extraer interfaz.
Y si necesita modificar la clase más tarde, puede usar Refactor-> Pull Up ... para desplegar los métodos que necesita en la interfaz.
Incluso si está seguro de que solo habrá un tipo concreto de objeto modelo, el uso de interfaces hace que las burlas y las pruebas sean algo más fáciles (pero en estos días hay estructuras que pueden ayudarlo a generar clases simuladas automáticamente, incluso para clases concretas de Java). Mockito, JTestR, Spring, Groovy ...)
Pero aún más a menudo uso interfaces para servicios, ya que es aún más importante burlarse de ellos durante las pruebas, y programar contra interfaces lo ayuda a pensar en cosas como la encapsulación.
La interfaz de escritura antes de que se necesite (ya sea para pruebas o arquitectura) es una exageración.
Además, escribir una interfaz manualmente es una pérdida de tiempo. Puede usar la refactorización de Resharper "Pull Members" para dejar que cree una nueva interfaz fuera de la clase específica en cuestión de segundos. Otras herramientas de refactorización que se integran con IDE también deberían tener una funcionalidad similar.
Las interfaces de escritura para clases de dominio pueden tener sentido si lo está usando para pruebas de unidades. Usamos objetos simulados en pruebas unitarias. Entonces, si tiene una interfaz para un objeto de dominio y su objeto de dominio en sí no está listo, su cliente puede probar su uso de la interfaz con la ayuda de objetos simulados.
Intefaces también prueba múltiples implementaciones de sus interfaces para su modelo de dominio. Entonces, no creo que siempre sea excesivo.
Las interfaces son una forma excelente de aislar componentes para propósitos de pruebas unitarias y administración general de dependencias. Al decir eso, a menudo prefiero las clases abstractas, por lo que al menos parte del comportamiento común se descarga allí en lugar de forzar parte de la duplicación que traen las interfaces. Los IDEs modernos hacen que sea fácil y rápido generar interfaces, por lo que no funcionan tanto :-)
No diseñe demasiado su sistema. Si descubre que tiene varios tipos de pedidos y cree que es apropiado declarar una interfaz para pedidos, refactorícelos cuando sea necesario. Para los modelos de dominio, la probabilidad es alta de que la interfaz específica cambie mucho durante la vida útil del desarrollo, por lo que rara vez es útil escribir una interfaz con anticipación.
No, solo uso interfaces en objetos de dominio para mantenerlos acoplados. Para mí, el principal objetivo de desarrollar mi propio código con interfaces es que puedo crear simulaciones fácilmente al hacer pruebas unitarias. No veo el sentido de burlarse de los objetos de dominio ya que no tienen las mismas dependencias que una capa de servicio o una clase de capa DAO.
Esto ciertamente no significa desviarse del uso de interfaces en objetos de dominio. Usar cuando sea apropiado. Por ejemplo, últimamente he estado trabajando en una aplicación web donde diferentes tipos de objetos de dominio corresponden a páginas de enlace permanente en las que los usuarios pueden dejar comentarios. Entonces, cada uno de estos objetos de dominio ahora implementa la interfaz "Commentable". Todo el código basado en comentarios se programa luego en la interfaz Commentable en lugar de los Objetos del Dominio.
Principalmente escribimos aplicaciones web con Wicket, Spring e Hibernate y utilizamos interfaces para Spring Beans, por ejemplo, servicios y DAO. Para estas clases, las interfaces tienen mucho sentido. Pero también usamos interfaces para cada clase de dominio y creo que esto es simplemente exagerado.
Te recomendaría mantenerte ágil y ágil: no hagas nada hasta que necesites hacerlo, y luego deja que tu IDE te refactorice cuando lo necesites.
Es bastante trivial en IDEA / eclipse convertir una clase concreta en una interfaz cuando decides que la necesitas.
A continuación, utilice la inyección de dependencia con Spring o Guice si tiene muchas implementaciones de la interfaz para inyectar en los lugares de su código que está utilizando ''nuevo''
Usualmente solo uso interfaces donde tiene sentido en proyectos más pequeños. Sin embargo, mi último trabajo tiene un gran proyecto en el que casi todos los objetos de dominio tienen una interfaz. Probablemente sea exagerado y definitivamente molesto, pero la forma en que hacemos las pruebas y usamos Spring para la inyección de dependencia lo requiere.
* Lo hago porque lo necesito para crear proxies de mis objetos de dominio.
En realidad, esta pregunta es un ejemplo del malentendido común sobre "programación contra interfaces".
Verán, este es un principio muy bueno, ¡pero no significa lo que mucha gente piensa que significa!
"Programar para una interfaz, no una implementación" (del libro de GoF) significa exactamente eso, no es que debas deshacerte de tu camino para crear interfaces separadas para todo. Si tiene un objeto ArrayList , declare la variable / campo / parámetro / tipo de retorno como de tipo List . El código del cliente solo tratará con el tipo de interfaz.
En el libro "Java efectivo" de Joshua Bloch, el principio se expresa más claramente, en el "Artículo 52: Refiérase a los objetos por sus interfaces". Incluso dice, en negrita:
Es completamente apropiado referirse a un objeto por una clase en lugar de una interfaz si no existe una interfaz adecuada.
Para las pruebas unitarias, la situación depende completamente de las capacidades de la herramienta de burla utilizada. Con mi propia herramienta, JMockit , puedo escribir pruebas unitarias con la misma facilidad para código que usa interfaces e Inyección de Dependencia que para código que usa clases finales creadas desde el código bajo prueba.
Entonces, para mí, la respuesta es: siempre use interfaces que ya existen, pero evite crear nuevas si no hay una buena razón para hacerlo (y la capacidad de prueba , por sí sola, no debería ser una).