Seven principles of design patterns (3) - Dependency Inversion Principle

Foreword

We say on one interface segregation principle is to allow duty interface is minimized. So to maintain the code simple, call the method is also clear.

This section we examine dependency inversion principle. This principle I think it is particularly special importance. In many places we can see. For example Dubbo used to SPI like.

basic introduction

What is the Dependency Inversion Principle?

We can be divided into two:

1) 高层模块不应该依赖低层模块，二者都应该依赖其抽象
2) 抽象不应该依赖细节，细节应该依赖抽象

In fact, the sum down, reversed-dependent (inverted) The central idea is oriented programming interface

Variability with respect to the details of the abstract things much more stable.

We abstract interface basis to structure our project much more stable than the detail-based architecture.

In java, refers to an abstract interface or abstract class, details of that specific category

The purpose of using an interface or abstract class is to develop a good standard, and not related to any particular operation, to show the details of the task entrusted to them to complete the implementation class

Case

Dry above text must be read several times, and then look at the case.

Counterexample

First, let's explain a counter-example, if you have not used depend on the principle of inversion problem?

public class Audi {
    public void run(){
        System.out.println("开奥迪上班");
    }
}

class Person{
    public void goToWork(Audi car){
        car.run();
    }

    public static void main(String args[]){
        Person person = new Person();
        Audi audi = new Audi();
        person.goToWork(audi);
    }
}

Appeals Code output is:

开奥迪上班

We think about this design there is no problem?

Obviously, if this person for a car, we need to change the Person class is not the source code? ?

We realized goToWork in this class Person () work this way. And was introduced to Audi this object.

If we want to change a car, you can only modify goToWork () This method, passing in the car you want to open.

Such designed code is very flexible.

Let's see what the right way is.

Dependency Inversion Principle

public class Audi {
    public void run(){
        System.out.println("开奥迪上班");
    }
}

public class Jili {
    public void run(){
        System.out.println("开国产神车吉利上班");
    }
}

public interface Car {

    void run();
}

class Person{
    public void goToWork(Car car){
        car.run();
    }

    public static void main(String args[]){
        Person person = new Person();
        Audi audi = new Audi();
        Jili jili = new Jili();
        person.goToWork(audi);
        person.goToWork(jili);
    }
}

Appeals Code output

开奥迪上班
开国产神车吉利上班

I do not know if you can see from the advantages achieved Dependency Inversion Principle?

Yes, this case we want to open the car to open the car, do not need to go to modify the source code.

This time we come to understand before, then it is a lot clearer.

Variability with respect to the details of the abstract things much more stable.

We abstract interface basis to structure our project much more stable than the detail-based architecture.

to sum up

Dependency Inversion principle is that our abstract parent class to sub-class or abstract interface point to achieve ideological class.

Usually pay more attention to development, you will find many places to use this idea in principle.

But this design also has a drawback is that we did not realize the interface methods in a specific category, then this time this method is not called, and why? Jvm behind the series we'll analyze this one alone.

Therefore, the ideal state is to use interfaces or abstract classes to develop a good standard, strict reference to a specific category of the interface or abstract class.