DesignPattern系列__03依赖倒置原则

依赖倒置原则(dependence inversion priiciple,dip)

介绍

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.高层模块不应该依赖底层模块，两者都应该依赖其抽象。

2.抽象不应该依赖细节。

3.细节应该依赖抽象。

在java中，表现就是：

1.模块间的依赖通过抽象发生，实现类之间不应该发生直接的依赖关机，其依赖关系应该是用过接口或者抽象类产生的；

2.接口或者抽象类不应该依赖实现类；

3.实现类应该依赖接口或者抽象类。

依赖倒置原则的设计理念是：相较于实习类具有多变性，抽象要稳定的多。框架的设计应该基于抽象，这样子，能提高项目的稳定性。
在框架中，抽象的作用是用来制定规范，具体的细节应该交给实现类。

应用实例

有一个司机类对象张三(zs)，具有drive方法来驾驶汽车。

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("宝马汽车发动...");
    }
}

目前为止，看上去很美好，正常的功能也实现了；但是，因为这个功能是基于具体的实现类benz实现的，这就为后来的扩展带来了麻烦：比如张三同志艰苦奋斗，又买了一辆宝马(bmw)，但是根据driver类的drive方法，张三同志不能驾驶新买的宝马汽车。这就是很严重的逻辑了：只要是有了驾照，奔驰和宝马应该都能驾驶。

改进措施：

很明显，司机类中的drive方法不应该依赖于一种具体品牌的汽车，而因该是汽车的泛指。所以，新建两个接口:
idriver和icar，分别定义了司机和汽车的职能，汽车就是驾驶汽车。具体的代码如下：

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();
    }
}

在demo中，类dependence2 作为高层模块，它对底层模块的依赖建立在抽象上；司机张三的表面类型时idriver，benz和bmw的表面类型是icar，这样做，在扩展业务逻辑(比如新增一辆汽车mini)时，只需修改业务场景类(高层模块)，对底层模块如driver和benz等没有影响。

依赖的三种形式

依赖的形式有三种：接口依赖、setter方法依赖和构造器依赖。具体介绍如下：

1.接口依赖

顾名思义，就是通过实现接口的方式注入依赖，代码详见上面的改进措施。

2.setter方法依赖

在抽象中定义setter方法，就是所谓的setter方法依赖。
demo如下：

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.构造器依赖

这个也比较好理解，就是将icar的具体类型，通过构造器传给driver：

class driver implements idriver {
    private icar icar;
    
    public driver(icar icar) {
        this.icar =icar;    
    }
}

注意事项和细节

在项目中，底层模块的类都应该有抽象类或者接口，或者两者都有；
变量的声明应该是抽象类型，有利于提高项目的稳定性；
任何类都不应该从具体类派生；
尽量不要重写积累的方法，要结合“里氏替换原则”使用。