¿Está bien tener dependencias dentro de una clase que debe ser intercambiable?

8

Digamos que tengo un modelo de dominio y quiero leerlo y guardarlo desde cualquier capa de persistencia. En este momento podría ser un archivo json, pero en el futuro podría ser un XML o una base de datos (que también podría cambiar. en su tipo).

Para generar el modelo de dominio desde la capa de persistencia, tengo una implementación de una interfaz simple que, digamos, contiene un método getAll() y saveAll() . Si quiero cambiar a otro tipo de persistencia, simplemente puedo cambiar la implementación de la interfaz. Sin embargo, dentro de la implementación usaré soluciones completamente diferentes para leer y almacenar los datos, así que tendré que usar diferentes objetos de otras bibliotecas para tratar con los datos.

Digamos que uso un serializador Json en la primera implementación, luego instanciaré la instancia de ese serializador en mi implementación directamente. Esto llevará a mi implementación directamente en función de ese serializador, nunca podré darle otro. Pero esto no sería posible de todos modos, porque no hay una interfaz universal para los serializadores (o cualquier tipo de persistencia). Entonces, si quiero usar un serializador diferente, lo único que puedo hacer es escribir una implementación completamente nueva en lugar de pasar otra desde el exterior.

Entonces, ¿está bien que las dependencias de código duro en este caso? ¿O hay una opción mejor?

    
pregunta Philip Feldmann 20.12.2016 - 14:38

2 respuestas

4

Con referencia a mi respuesta a una pregunta reciente , la clave aquí es separar las interfaces de la capa de persistencia de Cualquier implementación de la capa de persistencia, utilizando el patrón de escalera.

La dependencia del serializador Json se convierte en un detalle de implementación del paquete de persistencia Json. El resto de la aplicación no necesita saber nada al respecto, ni sufrir la carga de esa dependencia, ya que solo accede al paquete de persistencia a través de las interfaces, que se encuentran en otro paquete.

Si luego agrega un paquete de persistencia de base de datos, simplemente implementa esas interfaces y sus dependencias de ORM, por ejemplo, también se ocultan como detalle de la implementación.

    
respondido por el David Arno 20.12.2016 - 15:03
2

No puedes eliminar todas las dependencias de tu código; eventualmente, tienes que depender de algo , de lo contrario, solo vas a terminar con un dios gigante que hace todo por sí mismo.

Como regla general, desea que cada clase dependa de objetos que serán más estables que ellos mismos; y desea que las relaciones inestables utilicen inyección de dependencia para permitir pruebas más fáciles y más flexibilidad.

¿Qué tan probable es que el serializador JSON cambie? ¿Es más o menos estable que el código que estás escribiendo?

Si es probable que reemplace el serializador más de una vez con una implementación diferente, entonces quizás pueda crear un proxy o un objeto envolvente alrededor del propio serializador. De esa manera, puedes controlar la interfaz que tienes con el serializador y solo depender de una biblioteca externa en un solo lugar.

Dicho esto, personalmente todavía no he encontrado una razón para reemplazar un serializador JSON (con un serializador diferente), por lo que no me preocuparía demasiado tener una dependencia directa con él. Un serializador siempre tendrá una interfaz más estable que cualquier otra cosa en mis propias aplicaciones, y los métodos que necesito son tan simples y pocos que no hay realmente una razón para que cambien.

Parece que no está preocupado específicamente por el cambio del serializador en sí mismo ; por lo que describió, le preocupa que los requisitos externos cambien a un sistema de persistencia totalmente diferente, en cuyo caso, De todos modos, la implementación de la capa de persistencia se reescribirá completamente, y el uso de la inyección de dependencia o un proxy no lo ayudará.

Mientras la interfaz entre la capa de persistencia y los modelos de su dominio permanezca igual, y usted se burla de la capa de persistencia cuando prueba en unidad los modelos de su dominio, no veo ningún problema dependiendo de la interfaz específica de una biblioteca JSON. Esa dependencia es barata de probar, y es poco probable que la biblioteca JSON cambie.

    
respondido por el guiniveretoo 20.12.2016 - 15:41

Lea otras preguntas en las etiquetas