Terme technique pour désigner l'opposé de l'injection de dépendance?

Il s'agit plus d'une nomenclature (rédaction technique) que d'une question purement technique. J'essaie d'écrire une proposition de refactoring (et de me l'attribuer) centrée sur l'expansion de l'injection de dépendance dans notre application. Bien que nous utilisions Spring pour le câblage automatique des beans, il existe encore des cas qui instancient les beans en utilisant MyClass obj = new MyClass(...), qui pourraient être totalement injectés. Je voudrais que ma proposition utilise une nomenclature élégante et fasse référence au modèle de conception opposé à DI avec un terme approprié.

Le «couplage serré» est-il un terme adéquat qui représente un antonyme de DI?

Non. Un couplage serré est bien plus que ce dont traite l'injection de dépendance.

L'injection de dépendance externalise une décision de mise en œuvre. Cela va un long chemin à découpler, mais le couplage est plus que cela.

Un bon antonyme pour l'injection de dépendances est le codage en dur d'une dépendance . Lorsque vous construisez (utilisez new ou utilisez directement une usine) à l'intérieur d'un objet de comportement, vous avez fusionné deux préoccupations différentes. Un localisateur de service permet de découpler mais vous laisse couplé au localisateur de service lui-même.

Le couplage est plus que la simple séparation de la construction et du comportement. Si j'ai 101 méthodes qui doivent être appelées dans un ordre particulier de la classe A à la classe B, je suis étroitement couplé. Peu importe à quel point la construction et le comportement sont merveilleusement séparés.

Le couplage est une mesure de l'interdépendance des deux objets. Tout ce qui contribue à rendre difficile la modification de l'un sans impacter l'autre contribue au couplage. L'injection de dépendance aide à cela, mais ce n'est pas tout cela.

À strictement parler, l' injection de dépendance ne s'oppose vraiment que PAS à l' injection de dépendance - et donc à toute stratégie de gestion des dépendances qui n'est pas l' injection de dépendance.

Le couplage [indésirable], bien qu'il ne s'agisse pas exactement d'un problème orthogonal, peut se produire ou être atténué de toute façon. Ces deux éléments sont couplés à DependencyClass:

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

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

DependencyLookupConstructorest couplé à un particulier DependencyClassdans ce cas. Mais, ils sont tous deux couplés à DependencyClass. Le vrai mal, s'il y en a un ici, n'est pas nécessairement le couplage, c'est qu'il DependencyLookupConstructordoit changer si DependencyClasssoudainement besoin de ses propres dépendances injectées ¹ .

Cependant, ce constructeur / classe est encore plus faiblement couplé:

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

Si vous travaillez en C #, la volonté ci - dessus permettra à votre ServiceLocatorretourner quoi que ce soit quand GetMyDoer()est invoqué, tant qu'il a peut do()ce l' DependencyLocatingConstructora do(). Vous bénéficiez de la validation de la signature au moment de la compilation sans même être couplé à une interface complète ² .

Alors, choisissez votre poison.

Mais fondamentalement, s'il y a un «opposé» concret à l'injection de dépendance, ce serait autre chose dans le domaine des «stratégies de gestion de la dépendance». Entre autres, si vous avez utilisé l'un des éléments suivants dans la conversation, je le reconnais comme n'étant PAS une injection de dépendance:

• Modèle de localisateur de service
• Localisateur / emplacement de dépendance
• Construction directe objet / dépendance
• Dépendance cachée
• "Pas d'injection de dépendance"

^{1. Ironiquement, certains des problèmes que DI résout à des niveaux plus élevés sont en quelque sorte le résultat de [l'utilisation excessive] de DI dans les niveaux inférieurs. J'ai eu le plaisir de travailler sur des bases de code avec une complexité inutile partout en raison de l'adaptation à la poignée d'endroits où cette complexité a réellement aidé ... Je suis certes biaisé par une mauvaise exposition.}

^{2. L'utilisation de l'emplacement du service vous permet également de spécifier facilement différentes dépendances du même type par leur rôle fonctionnel à partir du code appelant , tout en restant largement indépendant de la façon dont la dépendance est créée. Supposons que vous ayez besoin de résoudre Userou IUserà des fins différentes: par exemple, Locator.GetAdministrator()contre Locator.GetAuthor()- ou autre chose. Mon code peut demander ce dont il a besoin fonctionnellement sans même savoir quelles interfaces il prend en charge.}

Je ne sais pas s'il existe une terminologie industrielle spécifique et largement acceptée, mais les alternatives qui viennent à l'esprit incluent la création d'instances internes , la création de dépendances internes , les dépendances locales ou les dépendances de portée locale .

J'irais avec l' encapsulation des dépendances . Cela exprime que la dépendance est enfermée plutôt que de visiter et de repartir.