What is the Java design principle of Dependency Inversion?

Introduction to dependency inversion

We often hear the terms dependency inversion, dependency inversion, inversion of control, dependency injection, and IOC during the framework development process. These terms we often hear are among the development and design principles. The Dependency Inversion Principle is related. Let’s take a look at these terms:

• Inversion of Control (IOC). This is basically what Spring interviews will do. I asked a question. The full name of IOC is Inversion of Controller. IOC is not necessarily a feature of Spring. Spring is a basic framework that uses IOC. A simple understanding is that the business code was redundantly used in the past through simple methods. It is troublesome when it needs to be changed. , permissions are completely controlled by developers. Anyway, it means that through some design patterns, developers do not develop based on relationships. As long as the functions that should be implemented are implemented, permissions are controlled by the program;

• Dependency Injection (DI), the full name is Dependency Injection. A simple understanding is that the objects that need to be operated are constructed through constructors, get/set, and interfaces, and new objects are injected through external objects passed in. This is dependency injection, and Spring is better for using it. A framework for ) Don't rely on low-level modules (low-level). High-level modules and low-level modules should depend on each other through abstractions. In addition, abstractions should not depend on specific implementation details, and specific implementation details should depend on abstractions

  ;

• ##Module concept

What do we often refer to as high module and low module? How do we distinguish, or mark the relationship when drawing;

Simply put, in the call chain, the caller belongs to the high level, and the callee belongs to the low level

. Why is such a design used? The root cause is loose coupling. Otherwise, high-level modules are strongly bound to low-level modules, and the high-level modules will not be affected by the code of the underlying modules; but is it completely necessary to follow this rule in actual scenarios? Woolen cloth? Let’s take a look at a common example:

MVC architecture: Commonly used methods are Controller-->Service-->Dao. Controller is a high module for Service, and Service is also a high module for Dao. , but we develop directly through injection in actual business scenarios. Of course, some may not inject directly and obtain objects through interfaces, which will increase the work cost.

Then we will have a question, will using this principle bring about an increase in work costs? According to my understanding, modules should also be divided into a granularity, and also need to be divided into relationships between modules, key relationships between codes, basic framework design relationships, and business code relationships. We have to consider scalability. If the business basically does not How to expand, there is no need to use this principle. Hollywood Principle

Hollywood Principle is short for Don’t call us, we’ll call you. According to popular science, in Hollywood, after submitting your resume to the entertainment company, you can only go home and wait. Since the performing arts company has complete control over the entire entertainment project, actors can only passively accept the company's tasks and complete their performances when necessary. This coincides with our dependency inversion principle. All dependency inversion principles are also called Hollywood principles.

The specific embodiment of the Hollywood principle is the template method pattern. All components are passive, and the container is responsible for all component initialization and invocation. This is also a point that should be considered as a basic framework. It mainly has the following benefits:

Support for interface-based programming

Reduce singletons and abstractions Factory dependencies
Reduce the coupling between business and framework
Business components can be reused and pluggable
Depending on the framework of Spring

• We need to clarify the concept that IOC is a feature of Spring, which makes the features of the Spring framework. It is not that the Spring framework created IOC.

What is the role of Spring's IOC? The so-called IOC is that the

Spring IOC container is responsible for the life cycle of the object and the relationship between objects

Spring IOC injected objects also provide dependent objects in the following ways: Constructor injection , stter method injection, interface injection.

Constructor injectionConstructor injection, as the name implies, means that the injected object lets the outside know which dependent objects it needs by declaring the parameter list of dependent objects in its construction method. Constructor injection is relatively simple, and it can be used completely after the construction is completed through construction.

<code>TestBean(Test test){<br>      this.test = test;<br>}</code>

setter method injection

For JavaBean objects, we generally access and set the properties of the object through the getter and setter methods. Therefore, the current object only needs to provide the corresponding setter method for the object it depends on, and the corresponding dependent object can be set to the injected object through this method. Compared with constructor injection, setter injection is more loose and flexible. It can be injected at any time

<code>public class TestBean {<br><br>    private Test test;<br><br>    public void setTestBean(Test test) {<br>        this.test = test;<br>    }<br>}</code>

Interface mode injection

Interface mode injection is more domineering, because it requires The dependent objects implement unnecessary interfaces, so we have to use this scenario reasonably. Generally, it rarely exists in the basic framework, but it is used more in the business field.

Annotation injection

Now Spring's mainstream injection method is mainly implemented through annotations, which are all based on the meta-annotation @Component, which also produces many derived annotations with @Component.

<code>@Autowrited<br>private TestBean testBean;<br><br>@Component<br>public TestBean(){<br><br>}<br></code>

The above is the detailed content of What is the Java design principle of Dependency Inversion?. For more information, please follow other related articles on the PHP Chinese website!