Spring dependency injection

One of the core functions of the Spring framework is to manage the dependencies between beans by relying on injection.

Dependency injection

Each application-based java has several objects that work together to present the application that the end user sees working. W hen writing a complex Java application, application classes should be as independent as possible of other Java classes to increase the likelihood of reuse of these classes, and test independence from other classes when unit testing is done. 依赖注入（或有时称为布线） helps bind these classes together while keeping them independent.

Suppose you have an application that contains text editor components, and you want to provide spell checking. The standard code looks like this:

public class TextEditor {
   private SpellChecker spellChecker;  
   public TextEditor() {
      spellChecker = new SpellChecker();
   }
}

What we're doing here is creating a dependency between TextEditor and SpellChecker. And in a scenario where the control reverses the IoC, we do this:

public class TextEditor {
   private SpellChecker spellChecker;
   public TextEditor(SpellChecker spellChecker) {
      this.spellChecker = spellChecker;
   }
}

Here, TextEditor shouldn't worry about the implementation of SpellChecker. SpellChecker will be implemented independently and will be provided to TextEditor when textEditor is instantiated, and the entire process is controlled by the Spring framework.

Here, we've removed full control from TextEditor and saved it elsewhere (i.e., XML profiles), and dependencies (that is, the SpellChecker class) are injected into the TextEditor class through the class constructor. Therefore, the control flow has been "reversed" by dependency injection (DI) because you have effectively delegated the dependency to some external systems.

The second way to rely on injection is through the Setter method of the TextEditor class, and we will create a SpellChecker instance that will be used to call the setter method to initialize the properties of textEditor.

Therefore, DI has two main variants and the following two sub-chapters will cover them in combination with examples:

You can mix the two methods, constructor-based and setter-based DI, but it is a good practice to use constructors with mandatory dependencies and sette r with optional dependencies.

Code is a CLEANER of the DI principle, and the decoupling effect is more pronounced when objects are provided with their dependencies. An object does not look for its dependencies, nor does it know the location or class of the dependencies, all of which are controlled by the Spring framework.