DesignPattern Series __03 Dependency Inversion Principle

Dependency Inversion principle (Dependence Inversion Priiciple, DIP)

Introduction

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Detatils should depend upon abstractions.
翻译过来有是三个意思：

1. The layer module should not rely on the underlying module, should depend both abstract.

2. The abstract should not depend on the details.

3. The details should depend on the abstract.

In Java, the performance is:

1. The dependencies between modules occurs through the abstract, should not occur directly between the off-dependent implementation classes, the dependencies of the interface should be used or generated abstract class;

2. Interface or abstract class should not depend on the implementation class;

3. dependent interface or class should implement an abstract class.

Dependency Inversion principle design philosophy is: Compared to the internship class of variability, abstract much more stable. Design framework should be based on abstract, like this, can improve the stability of the project.
In the frame, the effect is used to develop an abstract specification, specific details are to be achieved class.

Applications

There is a class object driver Joe Smith (zs), with a drive way to drive a car.

public class Dependence1 {
    public static void main(String[] args) {
        Driver zs = new Driver();
        Benz benz = new Benz();
        zs.drive(benz);
    }
}

class Driver {
    public void drive(Benz benz) {
        benz.run();
    }
}

class Benz {
    public void run() {
        System.out.println("奔驰汽车发动...");
    }
}

//经过艰苦奋斗，张三同志买了一辆宝马汽车
class BMW {
    public void run() {
        System.out.println("宝马汽车发动...");
    }
}

So far, it looks very nice, normal function is achieved; however, because the function is based on a specific category Benz achieved, which brought trouble for the later expansion: for example, Comrade Joe Smith hard work, they bought, a BMW (BMW), but according to the drive method driver class, Comrade Joe Smith can not drive to buy a new BMW. This is a very serious logic: as long as have a driver's license, Mercedes-Benz and BMW should be able to drive.

improvement measures:

Obviously, drive method driver class should not depend on a particular brand of car, and the car is due to the general context. Therefore, the two new interfaces:
Idriver and ICar, define the functions of the driver and the car, the car is driving a car. Specific code as follows:

public class Dependence2 {
    public static void main(String[] args) {
        IDriver zs = new Driver();
        ICar benz = new Benz();
        zs.drive(benz);
        ICar bmw = new BMW();
        zs.drive(bmw);
    }
}

interface ICar {
    //是汽车都应该具备的功能
    public void run();
}

class Benz implements ICar {
    @Override
    public void run() {
        System.out.println("奔驰汽车发动...");
    }
}

class BMW implements ICar {
    @Override
    public void run() {
        System.out.println("宝马汽车发动...");
    }
}

interface IDriver {
    //是司机就应该会开车，不管是什么车
    public void drive(ICar iCar);
}

class Driver implements IDriver {
    @Override
    public void drive(ICar iCar) {
        iCar.run();
    }
}

In the demo, as a class Dependence2 layer module, its dependence on the underlying module based on an abstract; surface type when the seating surface of the driver type IDriver, Benz and BMW ICAR is, to do so, in the extended business logic (such as new when a car Mini), just modify the business scene class (top module), if there is no impact on the underlying module Driver Benz and so on.

Dependence of three forms

Dependent fashion in three ways: interface dependence, setter methods and constructors rely dependent. Detailed below:

1. Interface dependent

As the name suggests, is injection-dependent manner by the interface, the code detailed above improvements.

2.setter method relies

Setter methods defined in the abstract, the method relies on the so-called setter.
demo is as follows:

interface IDriver {
    //setter方式注入
    public void setICar(ICar iCar);

}

class Driver implements IDriver {
    private ICar iCar;

    @Override
    public void setICar(ICar iCar) {
        this.iCar = iCar;
    }

}

3. The structure relies

This is relatively easy to understand, is the specific type of ICar, Driver passed by the constructor:

class Driver implements IDriver {
    private ICar iCar;
    
    public Driver(ICar iCar) {
        this.iCar =iCar;    
    }
}

Notes and details

In the project, the underlying class module should have an abstract class or interface, or both;
declare variables should be abstract type, will help improve the stability of the project;
any kind should not derive from specific classes;
try not to the method of rewriting accumulation, in conjunction with the use of "Richter substitution principle."