AlphaWang.com

Alpha's Programming Notes | 一个程序员的日常

[六大设计原则] 3. Dependence Inversion Principle

定义

DIP,Dependence Inversion Principle:

  • High level modules should not depend upon low level modules. Both should depend upon abstractions.
  • Abstractions should not depend upon details. Details should depend upon abstractions.

即“面向接口编程”:

  • 高层模块不应该依赖低层模块,两者都应该依赖其抽象;

    模块间的依赖通过抽象发生。实现类之间不发生直接的依赖关系(eg. 类B被用作类A的方法中的参数),其依赖关系是通过接口或抽象类产生的;

  • 抽象不应该依赖细节;

    接口或抽象类不依赖于实现类

  • 细节应该依赖抽象;

    实现类依赖接口或抽象类

      **何为“倒置”?**  
      依赖正置:类间的依赖是实实在在的实现类间的依赖,即面向实现编程,这是正常人的思维方式;     
      而依赖倒置是对现实世界进行抽象,产生了抽象间的依赖,代替了人们传统思维中的事物间的依赖。
    

问题由来

类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。
这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。

示例(类间的耦合性):

例如有一个Driver,可以驾驶Benz:

1
2
3
4
5
6
7
8
9
10
11
public class Driver {
    public void drive(Benz benz) {
        benz.run();
    }
}

public class Benz {
    public void run() {
        System.out.println("Benz开动...");
    }
}

问题来了:现在有变更,Driver不仅要驾驶Benz,还需要驾驶BMW,怎么办?
Driver和Benz是紧耦合的,导致可维护性大大降低、稳定性大大降低(增加一个车就需要修改Driver,Driver是不稳定的)。

示例(并行开发风险性):

如上例,Benz类没开发完成前,Driver是不能编译的!不能并行开发!

解决办法

将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。

上例中,新增一个抽象ICar接口,ICar不依赖于BMW和Benz两个实现类(抽象不依赖于细节)。
1)Driver和ICar实现类松耦合
2)接口定下来,Driver和BMW就可独立开发了,并可独立地进行单元测试

依赖的三种写法

1、构造函数传递依赖对象(构造函数注入)

1
2
3
4
5
6
7
8
9
10
11
12
13
public interface IDriver {
    public void drive();
}

public class Driver implements IDriver {
    private ICar car;
    public Driver(**ICar** _car) {
        this.car = _car;
    }
    public void drive() {
        this.car.run();
    }
}

2、setter方法传递依赖对象(setter依赖注入)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public interface IDriver{
    public void setCar(ICar car);
    public void drive();
}

public class Driver implements IDriver {
    private ICar car;
    public void setCar(**ICar** car) {
        this.car = car;
    }
    public void drive() {
        this.car.run();
    }
}

3、接口声明依赖对象(接口注入)

好处

依赖倒置可以减少类间的耦合性、降低并行开发引起的风险。

建议

DIP的核心是面向接口编程;
DIP的本质是通过抽象(接口、抽象类)使各个类或模块的实现彼此独立,不互相影响。

在项目中遵循以下原则:

  • 每个类尽量都有接口或抽象类
  • 变量的表面类型尽量使接口或抽象类
  • 任何类都不应该从具体类派生*——否则就会依赖具体类。
  • 尽量不要重写父类中已实现的方法——否则父类就不是一个真正适合被继承的抽象。
  • 结合里氏替代原则使用

design patterns

« [六大设计原则] 2. Liskov Substitution Principle [六大设计原则] 4. Interface Segrefation Principle »