Shulou(Shulou.com)05/31 Report--

This article mainly introduces the Java design principles of dependence inversion is what the relevant knowledge, the content is detailed and easy to understand, simple and fast operation, has a certain reference value, I believe that you read this Java design principles dependency inversion is what the article will gain, let's take a look at it.

Brief introduction of dependency inversion

We often hear about dependency inversion, dependency inversion, control inversion, dependency injection, and IOC during framework development. These nouns we often hear are related to the principle of dependency inversion in development and design principles. Let's take a look at these nouns:

Inversion of control (IOC), which is basically a question that will be asked in Spring interviews. The full name of IOC is not necessarily a feature of Spring. Spring is a basic framework for using IOC. The simple understanding is that the business code is redundant together by a simple method, which is troublesome when it needs to be changed, and the permission is completely controlled by the developer. Anyway, it means that through some design patterns, the developer does not develop on the basis of the relationship. As long as the functions that should be implemented are implemented, the permissions will be controlled by the program.

Dependency injection (DI), whose full name is Dependency Injection, simply means that objects that need operations are injected into new objects through objects constructed by constructors, get/set, and interfaces. This is dependency injection, and Spring is a framework that makes good use of it.

The dependency inversion principle (DIP), whose full name is Dependency Inversion Principle, can also be called the dependency inversion principle, which means that high-level modules (high-level modules) do not rely on lower-level modules (low-level). High-level modules and low-level modules should depend on each other through abstractions. In addition, abstractions does not rely on concrete implementation details (details), while concrete implementation details (details) rely on abstractions (abstractions)

Module concept

What do we often mean by high module and low module? How do we distinguish, or mark the relationship when drawing?

To put it simply, on the call chain, the caller belongs to the high level and the callee belongs to the lower level. Why do you use such a design, the root is loose coupling, otherwise the high module strongly binds the low module, and it will not affect the high-level module because of the code of the underlying module; but is it absolutely necessary to follow this rule in the actual scenario? Let's look at a common example:

MVC architecture: the common usage: Controller-- > Service-- > Dao,Controller is a high module for Service, and Service is also a high module for Dao. However, in actual business scenarios, we develop directly in the form of injection, of course, some may not be directly injected, and objects are obtained through APIs, which will increase the work cost.

Then we will have a question: will the use of this principle lead to an increase in the cost of work? According to my understanding, the module also needs to be divided into a granularity, and it also needs to be divided into the relationship between modules, the key between the code, the basic framework design relationship, and the business code relationship. We have to consider expansibility. If the business basically does not expand, there is no need to use this principle.

Hollywood principle

The Hollywood principle is referred to as Don't call us, we'll call you. Popular science is in Hollywood. After submitting your resume to an acting company, you have to go home and wait. Under the complete control of the entire entertainment project by the performing arts company, actors can only passively accept the company's errands and complete their own performances in the necessary links. This coincides with our principle of dependency inversion, which is also called the Hollywood principle.

The concrete embodiment of the Hollywood principle is the template method pattern, all components are passive, and all component initialization and invocation are the responsibility of the container. This is also a point that should be considered by the basic framework, with the following main benefits:

Support for interface-based programming

Reduce dependence on singleton and abstract factories

Reduce the coupling of business and framework

Business components are reusable and pluggable

Spring depending on the framework

We need to clarify the concept that IOC is a feature of Spring that makes the Spring framework unique, and it is not the Spring framework that creates IOC.

What is the purpose of Spring's IOC? The so-called IOC means that the Spring IOC container is responsible for the life cycle of objects and the relationship between objects.

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

Constructor injection

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

TestBean (Test test) {

This.test = test

} setter method injection

For JavaBean objects, we usually 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 by this method. Compared with constructor injection, setter injection is more relaxed and flexible, and it can be injected at any time.

Public class TestBean {

Private Test test

Public void setTestBean (Test test) {

This.test = test

}

} interface mode injection

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

Annotation injection

At present, the mainstream injection methods of Spring are mainly implemented through annotations, which are all based on meta-annotations @ Component, which produces a lot of derivative annotations with @ Component.

@ Autowrited

Private TestBean testBean

@ Component

Public TestBean () {

}

This is the end of the article on "what is the dependency inversion of Java design principles?" Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "what is the dependence inversion of Java design principles". If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.