Original article source, very well written

Dependency inversion

One of the six design principles

The principle of

1. Upper modules should not depend on lower modules, they should all depend on abstractions.

2. Abstraction should not depend on details. Details should depend on abstractions.

The lower level

The top layer: the business layer, the operations, is what to do the bottom layer: the logic layer, the data layer, the implementation details, is how to do

The example of people going out

People go out of a variety of means of transportation, Driver as an abstract class, people rely on Driver, as for riding or riding, are handled by the Driver’s implementation class, such as Bike, Car, etc., implementation class is the details

Regular writing
public class Person {

    private Bike mBike;

    public Person() {
        mBike = new Bike();
    }

    public void chumen() {
        System.out.println("Out the door."); mBike.drive(); }}Copy the code
Increase the interface
public class Person {

//  private Bike mBike;
//  private Car mCar;
//  private Train mTrain;
    private Driveable mDriveable;

    public Person() {
        mDriveable = new Train();
    }

    public void chumen() {
        System.out.println("Out the door."); //mBike.drive(); //mCar.drive(); //mTrain.drive(); mDriveable.drive(); }}Copy the code

Dependency inversion is essentially the embodiment of interface – oriented programming

Inversion of Control (IoC)

Inversion of Control Inversion of Control Inversion of Control

The Driver was instantiated by Person, and now the Driver is passed in the constructor so that the Person class doesn’t need to be moved no matter how the trip changes. Okay

Inversion of control
public class Person {

    private Driveable mDriveable;

    public Person(Driveable driveable) {
        this.mDriveable = driveable;
    }

    public void chumen() {
        System.out.println("Out the door."); mDriveable.drive(); } } public class Test1 { public static void main(String[] args) { Bike bike = new Bike(); Car car = new Car(); Train train = new Train(); // Person person = new Person(bike); // Person person = new Person(car); Person person = new Person(train); person.chumen(); }}Copy the code

Dependency Injection

Dependency injection, also often referred to simply as DI, was introduced in the previous section. It is a means to achieve IoC. What does that mean?

In order not to modify Person because of changes in the dependent implementation, that is, to leave the code of the Person class unchanged if the Driveable implementation class changes, minimize the coupling between the two. We need to use the IoC pattern described in the previous section to rewrite the code. This requires us to hand over control of dependency instantiation, so what about dependencies? If a dependency cannot be instantiated on Person, it will need to be given an injection outside the IoC container. This injection action is also called injection. This is commonly called an injector.

Dependency injection can be implemented in three ways:

  1. Constructor
  2. Setter injection
  3. Interface injection
setter
public class Person {
    public void setDriveable(Driveable mDriveable) { this.mDriveable = mDriveable; }}Copy the code
Interface injection
public interface DepedencySetter {
    void set(Driveable driveable);
}

class Person implements DepedencySetter{
    private Driveable mDriveable;

    @Override
    public void set(Driveable driveable) { this.mDriveable = mDriveable; }}Copy the code

This is very similar to Setter. A lot of you might be wondering is it unnecessary to add an interface?

The answer is definitely no, it comes down to a character question. For example, in the previous restaurant, there are cooks and waiters in addition to the delivery man. If only the delivery man realizes a delivery interface, the restaurant will only configure the delivery to the delivery man.

The existence of interfaces represents a configuration dependent capability.

In software frameworks, XML configuration files are read or annotations are read using reflection technology. Based on the configuration information, the framework has dynamically configured some dependencies for classes with specific interfaces. It can also be said that the Injector relied on the interface rather than the specific implementation class, which has further improved accuracy and flexibility.

conclusion

1. Dependency inversion is a software design principle in the field of object-oriented development. It advocates that the upper module does not depend on the lower module, and abstraction does not depend on details. 2. Dependency inversion is a design pattern based on the principle of dependency inversion, which introduces the concept of IoC container. 3. Dependency injection is one of the means to achieve dependency inversion. 4. Their essence is to make code more “cohesive, less coupled.”

1. Inversion of control is a design pattern that follows the principle of dependency inversion

2. Dependency injection is a means to achieve inversion of control