Término técnico para denotar opuesto de inyección de dependencia?

Esto es más una nomenclatura (escritura técnica) que una pregunta puramente técnica. Estoy tratando de escribir una propuesta de refactorización (y asignarla a mí mismo) centrada en expandir la inyección de dependencia en nuestra aplicación. Si bien utilizamos Spring para autoabastecer beans, todavía hay instancias que crean instancias de beans MyClass obj = new MyClass(...)que podrían inyectarse por completo. Me gustaría hacer que mi propuesta use una nomenclatura elegante y referirme al patrón de diseño opuesto a DI con un término apropiado.

¿Es "acoplamiento apretado" un término adecuado que se erige como un antónimo de DI?

No. El acoplamiento apretado es mucho más de lo que trata la inyección de dependencia.

La inyección de dependencia externaliza una decisión de implementación. Esto va muy lejos para desacoplar, pero el acoplamiento es más que solo esto.

Un buen antónimo para la inyección de dependencias es codificar una dependencia . Cuando construyes (usa uno nuevo o usa directamente una fábrica) dentro de un objeto de comportamiento, has eliminado dos preocupaciones diferentes. Un localizador de servicios ayuda a desacoplar pero lo deja acoplado al localizador de servicios en sí.

El acoplamiento es más que solo separar la construcción y el comportamiento. Si tengo 101 métodos que deben llamarse en un orden particular de clase A a clase B, estoy estrechamente acoplado. No importa cuán maravillosamente separadas estén la construcción y el comportamiento.

El acoplamiento es una medida de la interdependencia de los dos objetos. Cualquier cosa que contribuya a dificultar hacer cambios en uno sin afectar al otro está contribuyendo al acoplamiento. La inyección de dependencia ayuda con esto, pero no es todo esto.

Estrictamente hablando, la Inyección de dependencias solo se opone realmente a NO la Inyección de dependencias y, por lo tanto, a cualquier estrategia de administración de dependencias que no sea Inyección de dependencias.

El acoplamiento [no deseado], aunque no es exactamente un problema ortogonal, puede ocurrir o mitigarse de cualquier manera. Ambos están acoplados a DependencyClass:

public DependencyInjectedConstructor(DependencyClass dep) {
  dep.do();
}

public DependencyLookupConstructor() {
  var dep = new DependencyClass();
  dep.do();
}

DependencyLookupConstructorestá acoplado a un particular DependencyClassen este caso. Sin embargo, son ambos acoplados a DependencyClass. El verdadero mal, si hay uno aquí, no es necesariamente el acoplamiento, es que DependencyLookupConstructordebe cambiar si de DependencyClassrepente necesita inyectar sus propias dependencias ¹ .

Sin embargo, este constructor / clase está aún más débilmente acoplado:

public DependencyLocatingConstructor() {
  var dep = ServiceLocator.GetMyDoer();
  dep.do();
}

Si está trabajando en C #, lo anterior permitan que el ServiceLocatorregresar nada cuando GetMyDoer()se invoca, con tal de que tiene puede do()lo que DependencyLocatingConstructorlo tiene do(). Obtiene el beneficio de la validación de firma en tiempo de compilación sin siquiera estar acoplado a una interfaz completa ² .

Entonces, elige tu veneno.

Pero, básicamente, si hay un "opuesto" concreto de la Inyección de dependencias, sería algo más en el ámbito de las "Estrategias de gestión de dependencias". Entre otros, si utilizó alguno de los siguientes en la conversación, lo reconocería como NO una inyección de dependencia:

• Patrón de localizador de servicio
• Localizador de dependencia / ubicación
• Construcción directa de objeto / dependencia
• Dependencia oculta
• "No inyección de dependencia"

^{1. Irónicamente, algunos de los problemas que DI resuelve en niveles más altos son el resultado de [sobre-] usar DI en los niveles más bajos. He tenido el placer de trabajar en bases de código con una complejidad innecesaria en todas partes como resultado de acomodar el puñado de lugares donde esa complejidad realmente ayudó ... Estoy ciertamente predispuesto por la mala exposición.}

^{2. El uso de la ubicación del servicio también le permite especificar fácilmente diferentes dependencias del mismo tipo por su función funcional del código de invocación , mientras sigue siendo en gran medida agnóstico sobre cómo se construye la dependencia. Suponga que necesita resolver Usero IUserpara diferentes propósitos: por ejemplo, Locator.GetAdministrator()versus Locator.GetAuthor(), o lo que sea. Mi código puede preguntar qué necesita funcionalmente sin siquiera saber qué interfaces admite.}

No sé si existe una terminología específica de la industria ampliamente aceptada, pero las alternativas que se me ocurren incluyen la creación de instancias internas , la creación de dependencias internas , las dependencias locales o las dependencias de ámbito local .

Yo iría con la encapsulación de dependencia . Esto expresa que la dependencia está bloqueada en lugar de visitar y salir nuevamente.