DI fanático del control anti-patrón: Tener problemas para entender

Question

estoy leyendo la inyección de dependencias en .NET por Mark Seemann y yo no puedo por la vida de mí conseguir mi cabeza envuelta alrededor de esto:

Aunque el nueva palabra clave es un olor a código cuando se trata de VOLATILE DEPENDENCIAS, no tiene que preocuparse por usarlo para STABLE DEPENDENCIES. La nueva palabra clave no es repentinamente "ilegal" en general, , pero debe abstenerse de usarla para obtener instancias de VOLATILE DEPENDENCIAS.

Tal vez sea porque todavía no puedo entender cómo el contexto ambiental es una inyección en lugar de solo una variable global, pero no estoy obteniendo lo que el autor está diciendo.

Realmente me gustaría entender DI de arriba a abajo, pero ahora estoy atascado y esto es solo 1/3 del camino por el libro ... El anti-patrón Control-Freak parece ser cada uno programador que alguna vez vivió ...

¿Alguien tiene alguna idea?

Answer 1

Volatility (para mí) es una medida de la probabilidad de que una clase deba cambiarse.

Lo ideal es que las clases de diseño estén abiertas a la extensión pero estén cerradas a la modificación (Principio de apertura cerrada). Esto no siempre es posible. Esas clases que usted cierra para cambiar son menos volátiles que las otras.

NDepend (una herramienta de métrica de análisis estático .Net) tiene una métrica llamada Instability que en mi mente también. Lo definen como:

Inestabilidad (I): La relación de acoplamiento eferente (Ce) al acoplamiento total. I = Ce/(Ce + Ca). Esta métrica es un indicador de la resistencia de la asamblea al cambio. El rango para esta métrica es de 0 a 1, con I = 0 que indica un ensamblaje completamente estable e I = 1 que indica un ensamblaje completamente inestable.

No desea que las clases estables dependan de las menos estables.

En cuanto a la decisión de inyectar o no, eso suena más como un problema de rol de clase. De Domain Driven Design, (DDD) Las clases generalmente son Entidades (tienen identidad), Servicios (orquestan cosas) o Valores (son inmutables y comparables, como ROJO o 100 ml).

Inyectaría Servicios, llamaría a los nuevos en Valores. Las entidades generalmente provienen de un repositorio (que usted inyecta), pero internamente el repositorio llamará nuevo en ellas. ¿Eso ayuda?

Answer 2

Por lo general, el contenedor DI resuelve todas las dependencias de la implementación concreta y maneja la duración para usted. Pero DI Control-Freak hace lo contrario: crea un objeto concreto usando la palabra clave new, los inyecta y maneja el tiempo de vida solo. Entonces, nadie más tiene la posibilidad de configurar y manejar dependencias fuera de su código. Y así, reutilizar o probar proporcionando otras implementaciones o falsificaciones.

Aquí es la cita del libro de marca-@ Seemann, que responde a su pregunta:

lo he denominado Control Freak para describir una clase que no de control relinquish de sus dependencias.

Esto sucede cada vez que creamos una nueva instancia de un tipo mediante el uso de la nueva número- palabra. Cuando hacemos eso, declaramos explícitamente que vamos a controlar la duración de la instancia de y que nadie más tendrá la oportunidad de interceptar ese objeto en particular.

Answer 3

No escuché estos términos antes, pero al transponer lo que sé sobre la inyección de dependencia, los definiría de la siguiente manera.

Una dependencia estable es aquella cuya implementación concreta no variará, en clase o configuración, a lo largo del tiempo o en situaciones diferentes.

Una dependencia volátil es aquella cuya implementación concreta puede variar, en clase o configuración, a lo largo del tiempo o en diferentes situaciones.

Si puede perdonar un ejemplo en Java, una dependencia estable sería StringBuilder. Si está escribiendo un método para construir una cadena, no necesita tener un StringBuilder inyectado, puede simplemente crearlo. Ídem para ArrayList, HashMap, etc. Más allá de las clases de biblioteca estándar, si estuviera escribiendo una aplicación bancaria, probablemente no inyectaría un RunningTotaliser, porque ese es un objeto que simplemente suma números para usted.

Los ejemplos de dependencias volátiles en la biblioteca estándar son más difíciles de encontrar. Un ejemplo clásico sería un DataSource, que es un objeto que encapsula los detalles de conexión de una base de datos, y que seguramente no deberían ser suministrados por el código que está realizando las conexiones.