Dependency inversion principle of software architecture design principle

Time:2022-5-26

Dependency Inversion Principle (DIP) means that when designing code structure, high-level modules should not rely on low-level modules, and both should rely on their abstraction. Abstract should not rely on details, details should rely on abstraction. Through dependency inversion, we can reduce the coupling between classes, improve the stability of the system, improve the readability and maintainability of the code, and reduce the risk caused by modifying the program. Next, let’s take a case, or take course as an example. First, create a class Tom:

public class Tom {
    public void studyJavaCourse(){
        System. out. Println ("Tom is taking a course in Java");
    }

    public void studyPythonCourse(){
        System. out. Println ("Tom is studying Python");
    }
}

To call:

public static void main(String[] args) {
    Tom tom = new Tom();
    tom.studyJavaCourse();
    tom.studyPythonCourse();
}

Tom loves learning and is currently studying Java courses and python courses. As we all know, learning is addictive. With the “surge” of learning interest, Tom still wants to study AI (Artificial Intelligence) courses. At this time, the code should be modified from the lower layer to the higher layer. Add the studyaicourse () method in the Tom class, and call it additionally at the high level. In this way, after the system is released, it is actually very unstable, and it will bring unexpected risks while modifying the code. Next, we optimize the code and create an abstract icourse interface for the course:

public interface ICourse {
    void study();
}

Then write the javacourse class:

public class JavaCourse implements ICourse {
    @Override
    public void study() {
        System. out. Println ("Tom is taking a java course");
    }
}

Then implement the python course class:

public class PythonCourse implements ICourse {
    @Override
    public void study() {
        System. out. Println ("Tom is taking a python course");
    }
}

Modify Tom class:

public class Tom {
    public void study(ICourse course){
        course.study();
    }
}

Look at the calling code:

public static void main(String[] args) {
    Tom tom = new Tom();
    tom.study(new JavaCourse());
    tom.study(new PythonCourse());
}

At this time, no matter how the interest of Tom soars, for the new course, you only need to create a new class and tell Tom by passing parameters, without modifying the underlying code. In fact, this is a very familiar way, called dependency injection. There are also constructor mode and setter mode for injection. Let’s look at the constructor injection method:

public class Tom {

    private ICourse course;

    public Tom(ICourse course){
        this.course = course;
    }

    public void study(){
        course.study();
    }
}

Look at the calling code:

public static void main(String[] args) {
    Tom tom = new Tom(new JavaCourse());
    tom.study();
}

According to the constructor injection mode, an instance is created every time when it is called. If Tom is a global singleton, we can only choose to inject by setter and continue to modify the code of Tom class:

public class Tom {
    private ICourse course;
    public void setCourse(ICourse course) {
        this.course = course;
    }
    public void study(){
        course.study();
    }
}

Look at the calling code:

public static void main(String[] args) {
    Tom tom = new Tom();
    tom.setCourse(new JavaCourse());
    tom.study();

    tom.setCourse(new PythonCourse());
    tom.study();
}

Now let’s look at the final class diagram, as shown in the figure below.
Dependency inversion principle of software architecture design principle

We should remember that the architecture based on abstraction is much more stable than that based on detail. Therefore, after getting the requirements, we should face interface programming and design the code structure at the top level first and then in detail.

This article is the original of “Tom bomb architecture”. Please indicate the source for reprint. Technology lies in sharing, I share my happiness!
If this article is helpful to you, you are welcome to pay attention and praise; If you have any suggestions, you can also leave comments or private letters. Your support is the driving force for me to adhere to my creation. Follow the wechat official account “Tom bomb architecture” to get more technical dry goods!

[recommendation] Tom bomb architecture: collecting this article is equivalent to collecting a Book of “design patterns”

Other design principles

Tom bomb architecture: Open Closed Principle (OCP)

Tom bomb architecture: simple responsibility pinciple (SRP)

Tom bomb architecture: interface aggregation principle (ISP)

Tom bomb architecture: Law of Demeter LOD

Tom bomb architecture: Liskov Substitution Principle (LSP)

Tom bomb architecture: composite / Aggregate Reuse Principle (car)