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

Questa è più una nomenclatura (scrittura tecnica) piuttosto che una domanda puramente tecnica. Sto cercando di scrivere una proposta di refactoring (e farmi assegnare a me stesso) incentrata sull'espansione dell'iniezione di dipendenza nella nostra applicazione. Mentre usiamo Spring per i bean autowiring, ci sono ancora istanze che utilizzano istanze dei bean MyClass obj = new MyClass(...), che potrebbero essere totalmente iniettate. Vorrei fare in modo che la mia proposta utilizzasse una nomenclatura elegante e fare riferimento al modello di progettazione opposto a DI con un termine appropriato.

"Accoppiamento stretto" è un termine adeguato che si pone come un inno a DI?

No. L'accoppiamento stretto è molto più di quello di cui si occupa l'iniezione di dipendenza.

L'iniezione di dipendenza esternalizza una decisione di attuazione. Questo fa molto per disaccoppiare, ma l'accoppiamento è molto più di questo.

Un buon inno per l'iniezione di dipendenza è la codifica dura di una dipendenza . Quando costruisci (usa nuovo o usa direttamente qualche factory) all'interno di un oggetto comportamentale hai confuso due preoccupazioni diverse. Un localizzatore di servizi aiuta a disaccoppiare ma ti lascia accoppiato al localizzatore di servizi stesso.

L'accoppiamento è molto più che separare 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 separate la costruzione e il comportamento.

L'accoppiamento è una misura dell'interdipendenza dei due oggetti. Tutto ciò che contribuisce a rendere difficile apportare modifiche in uno senza influire sull'altro sta contribuendo all'accoppiamento. L'iniezione di dipendenza aiuta in questo, ma non è tutto.

A rigor di termini, l' iniezione di dipendenza si oppone davvero NON a iniezione di dipendenza - e quindi a qualsiasi strategia di gestione delle dipendenze che non sia iniezione di dipendenza.

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

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

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

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

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

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

Se lavori in C #, quanto sopra ti consentirà ServiceLocatordi restituire qualsiasi cosa quando GetMyDoer()viene invocata, a patto che abbia do()ciò che DependencyLocatingConstructorha do(). Ottieni il vantaggio della convalida della firma in fase di compilazione senza nemmeno essere accoppiato a un'interfaccia completa ² .

Quindi, scegli il tuo veleno.

Ma fondamentalmente, se esiste un "opposto" concreto dell'iniezione di dipendenza, sarebbe qualcos'altro nel regno delle "strategie di gestione delle dipendenze". Tra l'altro, se hai usato uno dei seguenti argomenti nella conversazione, lo riconoscerei come NON Iniezione di dipendenza:

• Pattern di localizzazione di servizio
• Localizzatore / posizione delle dipendenze
• Costruzione diretta di oggetti / dipendenze
• Dipendenza nascosta
• "Iniezione non dipendente"

^{1. Ironia della sorte, alcuni dei problemi che DI risolve ai livelli più alti sono una sorta di risultato di [over-] utilizzo di DI nei livelli inferiori. Ho avuto il piacere di lavorare su basi di codice con complessità inutile dappertutto a causa dell'accoglienza di una manciata di posti in cui quella complessità ha effettivamente aiutato ... Sono certamente influenzato da una cattiva esposizione.}

^{2. L'utilizzo dell'ubicazione del servizio consente inoltre di specificare facilmente dipendenze diverse dello stesso tipo in base al loro ruolo funzionale rispetto al codice di invocazione , pur essendo in gran parte agnostico su come viene costruita la dipendenza. Supponiamo di dover risolvere Usero IUserper scopi diversi: ad esempio, Locator.GetAdministrator()contro Locator.GetAuthor()- o qualsiasi altra cosa. Il mio codice può chiedere di cosa ha bisogno funzionalmente senza nemmeno sapere quali interfacce supporta.}

Non so che esiste una terminologia specifica e ampiamente accettata del settore, ma le alternative che vengono in mente includono la creazione di istanze interne , la creazione di dipendenze interne , le dipendenze locali o le dipendenze localmente .

Vorrei andare con l' incapsulamento delle dipendenze . Questo esprime la dipendenza è bloccata piuttosto che visitare e lasciare di nuovo.