Termine tecnico per indicare l'opposto dell'iniezione di dipendenza?

No. L'accoppiamento stretto è molto più di ciò che riguarda l'iniezione di dipendenza.

L'iniezione di dipendenza esternalizza una decisione di implementazione. Questo è un lungo cammino per disaccoppiare ma l'accoppiamento è più di questo.

Un buon antonym per l'iniezione delle dipendenze è hard coding una dipendenza . Quando costruisci (usa nuovo o usi direttamente qualche fabbrica) all'interno di un oggetto comportamentale hai messo insieme due preoccupazioni diverse. Un localizzatore di servizi aiuta a disaccoppiare ma ti lascia accoppiato al localizzatore di servizi stesso.

L'accoppiamento è più di una semplice separazione tra costruzione e comportamento. Se ho 101 metodi che devono essere chiamati in un ordine particolare dalla classe A alla classe B, sono strettamente accoppiati. Non importa quanto siano meravigliosamente separati la costruzione e il comportamento.

L'accoppiamento è una misura dell'interdipendenza dei due oggetti. Qualsiasi cosa contribuisca a rendere difficile apportare modifiche in uno senza influenzare l'altro, contribuisce ad accoppiare. L'iniezione di dipendenza aiuta con questo, ma non è tutto questo.

In senso stretto, Iniezione delle dipendenze si oppone veramente NON Iniezione delle dipendenze - e quindi qualsiasi strategia di gestione delle dipendenze che non sia Iniezione di dipendenza.

L'accoppiamento [indesiderato], sebbene non sia esattamente un problema ortogonale, può verificarsi o essere mitigato in entrambi i modi. Questi sono entrambi accoppiati a DependencyClass :

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

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

DependencyLookupConstructor è accoppiato a un particolare DependencyClass in questo caso. Ma sono entrambi accoppiati a DependencyClass . Il vero male, se ce n'è uno qui, non è necessariamente l'accoppiamento, è che DependencyLookupConstructor deve cambiare se DependencyClass improvvisamente ha bisogno delle sue proprie dipendenze iniettate ¹ .

Tuttavia, questo costruttore / classe è anche più liberamente accoppiato:

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

Se lavori in C #, quanto sopra consentirà al tuo ServiceLocator di restituire qualsiasi cosa quando viene richiamato GetMyDoer() , purché possa do() che DependencyLocatingConstructor ha do() . Ottieni il vantaggio della convalida della firma in fase di compilazione senza nemmeno essere abbinato a un'interfaccia completa ² .

Quindi, scegli il tuo veleno.

Ma sostanzialmente, se esiste un "contrario" concreto di Dependency Injection, sarebbe un'altra cosa nel regno delle "Strategie di gestione delle dipendenze". Tra l'altro, se hai usato uno dei seguenti argomenti in conversazione, l'avrei riconosciuto come NON Iniezione di dipendenza:

• Modello localizzatore di servizio
• Indicatore di dipendenza / posizione
• Costruzione diretta di oggetti / dipendenze
• Dipendenza nascosta
• "Iniezione non dipendente"

^{1. Ironia della sorte, alcuni dei problemi che DI risolve a livelli più alti sono una sorta di risultato di [over-] usando DI nei livelli inferiori. Ho avuto il piacere di lavorare su basi di codice con complessità non necessaria all over come risultato di accogliere la manciata di luoghi in cui tale complessità ha effettivamente aiutato ... Sono ovviamente prevenuto dalla cattiva esposizione.}

^{2. L'uso della posizione del servizio consente inoltre di specificare facilmente diverse dipendenze dello stesso tipo dal loro ruolo funzionale dal codice di richiamo , rimanendo comunque largamente agnostici su come viene costruita la dipendenza. Supponi di dover risolvere User o IUser per diversi scopi: es., Locator.GetAdministrator() contro Locator.GetAuthor() - o qualsiasi altra cosa. Il mio codice può chiedere ciò di cui ha bisogno funzionalmente senza nemmeno sapere quali interfacce supporta.}

Vorrei andare con incapsulamento delle dipendenze . Questo esprime la dipendenza è bloccato in piuttosto che visitare e lasciare di nuovo.

Non so se esiste una terminologia industriale specifica e ampiamente accettata, ma le alternative che mi vengono in mente includono creazione di istanze interne , creazione di dipendenze interne , locali dipendenze o dipendenze nell'ambito locale .