Technical term to denote opposite of dependency injection?

Question

This is more of a nomenclature (technical writing) rather than a purely technical question. I am trying to write a refactoring proposal (and get it assigned to myself) centered around expanding dependency injection in our application. While we do use Spring for autowiring beans, there are still instances that instantiate beans using MyClass obj = new MyClass(...), which could totally be injected. I would like to make my proposal use elegant nomenclature and refer to the design pattern opposite of DI with a proper term.

Is "tight coupling" an adequate term that stands as an antonym to DI?

Answer 1

Is "tight coupling" an adequate term that stands as an antonym to DI?

No. Tight coupling is much more than what dependency injection deals with.

Dependency injection externalizes a decision of implementation. This goes a long way to decouple but coupling is more than just this.

Technical term to denote opposite of dependency injection?

A good antonym for dependency injection is hard coding a dependency. When you construct (use new or directly use some factory) inside a behavior object you've smushed together two different concerns. A service locator helps decouple but leaves you coupled to the service locator itself.

Coupling is more than just separating construction and behavior. If I have 101 methods that have to be called in some particular order from class A to class B I'm tightly coupled. Doesn't matter how wonderfully separated construction and behavior are.

Coupling is a measure the interdependence of the two objects. Anything that contributes to making it difficult to make changes in one without impacting the other is contributing to coupling. Dependency injection helps with this but it is not all of this.

Answer 2

Strictly speaking, Dependency Injection only really opposes NOT Dependency Injection -- and therefore any dependency management strategy that isn't Dependency Injection.

[Unwanted] coupling, though not exactly an orthogonal issue, can either occur or be mitigated either way. These are both coupled to DependencyClass:

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

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

DependencyLookupConstructor is coupled to a particular DependencyClass in this case. But, they're both coupled to DependencyClass. The real evil, if there is one here, isn't the coupling necessarily, it's that DependencyLookupConstructor needs to change if DependencyClass suddenly needs its own dependencies injected¹.

However, this constructor/class is even more loosely coupled:

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

If you're working in C#, the above will permit your ServiceLocator to return anything when GetMyDoer() is invoked, as long as it has can do() what DependencyLocatingConstructor has it do(). You get the benefit of compile-time signature validation without even being coupled to a complete interface².

So, pick your poison.

But basically, if there's a concrete "opposite" of Dependency Injection, it would be something else in the realm of "Dependency Management Strategies." Amongst others, if you used any of the following in conversation, I'd recognize it as being NOT Dependency Injection:

• Service Locator Pattern
• Dependency Locator / Location
• Direct object/dependency construction
• Hidden dependency
• "Not Dependency Injection"

---

^{1. Ironically, some of the problems that DI solves at higher levels are sort of a result of [over-]using DI in the lower levels. I've had the pleasure of working on codebases with unnecessary complexity all over as a result of accommodating the handful of places where that complexity actually helped ... I'm admittedly biased by bad exposure.}

^{2. Using service location also permits you to easily specify different dependencies of the same type by their functional role from the invoking code, while still being largely agnostic about how the dependency is built. Suppose you need to resolve User or IUser for different purposes: E.g., Locator.GetAdministrator() versus Locator.GetAuthor() -- or whatever. My code can ask for what it needs functionally without even knowing what interfaces it supports.}

Answer 3

I don't know that there's specific, widely accepted industry terminology, but alternatives that come to mind include internal instance creation, internal dependency creation, local dependencies, or locally scoped dependencies.

Answer 4

Direct Dependency

Wow asked 6 years ago! I came to do this page searching for the same answer, and ultimately decided to use the term Direct Dependency instead of Hard Coding.

This decision was made because it describes what the injection avoids, by creating an indirect dependency. And after coming up with that definition, I decided to also start using the term indirect dependency to describe the general case of injection.

Reasoning

If i was to provide an object containing functions to a system, this would function as form of injection. The host or controller would have a direct dependency to the target, and the method would be invoked without a dependency from the target to either.

Target

export default {
  setName(name){ }  
}

So the common denominator between either exposing a method, or having some method accept an injected parameter by various means, is that the dependency is indirect, and removed from the target. The target has either a direct dependency or an indirect dependency on something. Injection is a form of indirect dependency.

Now let's look at the ideal coupling of dependencies, using the mediator pattern. Using this pattern, we have both direct and indirect dependencies:

Target

useMediator().callback = (name) => { myName = name }

Host

useMediator().callback('foobar')

In this example, our target has a direct dependency to the mediator, but publishes its callback to be used an indirect dependency. The host of our target will also have a direct dependency to the mediator, but an indirect dependency to the client method. In code-speak, the client and host include the mediator, but not each other.

The bottom line is that there are many ways to implement indirect dependencies, including but not limited to method parameter injection, but only 1 way to implement direct dependencies: by explicitly including them.

Answer 5

I would go with dependency encapsulation. This expresses the dependency is locked in rather than visiting and leaving again.