设计模式原则3依赖倒置原则

个人博客&＃xff1a;打开链接

依赖倒置原则定义

依赖倒置原则(Dependence Inversion Principle ,DIP)定义如下&＃xff1a;

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 abstracts.

翻译过来为&＃xff1a;

• 高层模块不应该依赖低层模块&＃xff0c;两者都应该依赖抽象
• 抽象不应该依赖细节
• 细节应该依赖抽象

也可以说高层模块&＃xff0c;低层模块&＃xff0c;细节都应该依赖抽象

每一个逻辑的实现都是由颗粒原子逻辑组成的&＃xff0c;颗粒原子逻辑就是低层模块&＃xff0c;而颗粒原子逻辑组成的模块就是高层模块。在java语言中&＃xff0c;抽象就是接口或抽象类&＃xff0c;两都都是不能直接被实例化的&＃xff0c;细节就是实现类&＃xff0c;实现接口或继承抽象类而产生的类就是细节&＃xff0c;两者都可以直接被实例化。

依赖倒置原则在java语言中&＃xff0c;表现是&＃xff1a;

• 模块间的依赖通过抽象发生&＃xff0c;实现类之间不发生直接的依赖关系&＃xff0c;其依赖关系是通过接口或抽象类产生的。
• 接口或抽象类不依赖实现类
• 实现类依赖接口或抽象类

更加精简的定义就是“面向接口编程”—OOD(Object-Oriented Design&＃xff0c;面向对象设计)的精髓之一。

依赖倒置原则的好处

• 采用依赖倒置原则可以减少类间的耦合性&＃xff0c;提高系统的稳定
• 降低并行开发引起的风险&＃xff0c;提高代码的可读性和可维护性

为什么我们要符合依赖倒置原则

举个例子司机驾驶奔驰车&＃xff0c;如图所示类图&＃xff1a;

司机源代码&＃xff1a;

public class Driver {//司机的主要职责就是驾驶汽车public void drive(Benz benz) {benz.run();}
}

司机通过调用奔驰车的run方法开动奔驰车&＃xff0c;奔驰车源代码&＃xff1a;

public class Benz {//汽车肯定会行驶public void run(){System.out.println("奔驰汽车开始运行...");}
}

有车&＃xff0c;有司机&＃xff0c;在Client场景类产生相应的对象。其源代码为&＃xff1a;

public class Client {public static void main(String[] args){Driver zhangSan &＃61; new Driver();Benz benz &＃61; new Benz();//张三开奔驰车zhangSan.drive(benz);}
}

以上代码完成了基本的需求&＃xff0c;对于软件项目设计“变更才显真功夫”&＃xff0c;那么问题来了&＃xff0c;来了一辆宝马车&＃xff0c;可是张三却没法驾驶&＃xff0c;这和现实完全不符。司机可以开任何品牌的车嘛。
宝马车源代码&＃xff1a;

public class BMW{//BMW also can be drivenpublic void run(){System.out.println("宝马车开始运行...");}
}

为了让张三可以开任何牌子的车&＃xff0c;我们引入依赖倒置原则。引入依赖倒置原则后的类图&＃xff1a;

司机接口&＃xff1a;

public interface IDriver {//是司机就应该会驾驶汽车public void drive(ICar car);
}

司机类的实现&＃xff1a;

public class Driver implements IDriver {//司机的主要职责就是驾驶汽车public void drive(ICar car){car.run();}
}

在IDriver中&＃xff0c;通过传入ICar接口实现了抽象之间的依赖关系&＃xff0c;Driver实现类也传入了ICar接口&＃xff0c;至于到底是哪种型号的Car&＃xff0c;需要在高层模块中声明。ICar及其两个实现类为&＃xff1a;

public interface ICar {//是汽车就应该能跑public void run();
}
public class Benz implements ICar {public void run(){System.out.println("奔驰车开始运行...");}
}
public class BMW implements ICar{public void run(){System.out.println("宝马车开始运行...");}
}


如此这般&＃xff0c;我们实现了抽象不依赖于细节&＃xff0c;而依赖于抽象&＃xff0c;即ICar接口不依赖于BMW或者Benz&＃xff0c;而仅仅依赖于ICar&＃xff0c;这也是该项目中的高层次模块&＃xff0c;业务场景中是这样的&＃xff1a;

public class Client {public static void main(String[] args) {IDriver zhangSan &＃61; new Driver();ICar benz &＃61; new Benz();//张三开奔驰车zhangSan.drive(benz);}
}

这里司机和汽车使用的都是抽象接口&＃xff0c;这里的zhangsan以及benz都是按照接口进行操作的&＃xff0c;所以屏蔽了细节对接口的影响&＃xff0c;进一步&＃xff0c;如果有新的需求&＃xff0c;zhangsan想要开BMW车&＃xff0c;只需要将ICar benz &＃61; new Benz()更换为ICar bmw &＃61; new BMW()即可&＃xff0c;这些都是在业务场景中进行的修改&＃xff0c;我们根本不用改动低层次模块Driver&＃xff0c;Benz或者是BMW&＃xff0c;更不会影响高层模块IDriver或者ICar&＃xff0c;这样把风险降到了最小。

我们再来考虑并行开发的影响&＃xff0c;之所以会影响并行开发是因为模块依赖&＃xff0c;我们知道&＃xff0c;模块之间如果有依赖关系&＃xff0c;只需要制定出两者之间的接口或者抽象类就可以了&＃xff0c;我们继续原来的例子&＃xff0c;甲负责IDriver的开发&＃xff0c;乙负责ICar开发&＃xff0c;只需要提前商定好接口&＃xff0c;两者即可独立的进行开发&＃xff0c;如果甲开发进度较快&＃xff0c;而乙进度滞后&＃xff0c;也不会对甲造成什么影响&＃xff0c;如果此时甲想要进行单元测试&＃xff0c;只需要Mock出一个ICar的实现类对象&＃xff0c;即可对IDriver以及实现类Driver进行测试了&＃xff1a;

public class DriverTest extends TestCase{Mockery context &＃61; new JUnit4Mockery();&＃64;Testpublic void testDriver() {//根据接口虚拟一个对象final ICar car &＃61; context.mock(ICar.class);IDriver driver &＃61; new Driver();//内部类context.checking(new Expectations(){{oneOf (car).run();}});driver.drive(car);}
}

可见&＃xff0c;即使两者的开发进度不一样&＃xff0c;也可以分别进行测试&＃xff0c;这也是测试驱动开发的精髓所在。

抽象&＃xff0c;对实现而言&＃xff0c;是一个约束&＃xff0c;所有实现类必须对抽象进行实现&＃xff0c;对其他依赖模块而言&＃xff0c;是一种契约&＃xff0c;抽象定义的接口&＃xff0c;既约束了自己&＃xff0c;也约束了自己与外部的关系&＃xff0c;保证实现细节不会脱离契约的范畴&＃xff0c;为其他依赖模块提供支持&＃xff0c;双方按照约定的接口共同发展&＃xff0c;只要接口在&＃xff0c;细节就不会偏离太远&＃xff0c;始终为其他依赖模块提供坚实的依赖细节。

依赖的传递

针对于对象依赖的声明&＃xff0c;有三种方式&＃xff1a;

通过构造函数传递依赖关系

这种方式通过构造函数声明依赖对象&＃xff0c;这种方式叫做构造函数注入&＃xff0c;示例如下&＃xff1a;

public interface IDriver {//是司机就应该会驾驶汽车public void drive();
}public class Driver implements IDriver{private ICar car;//构造函数注入public Driver(ICar _car){this.car &＃61; _car;}//司机的主要职责就是驾驶汽车public void drive(){this.car.run();}
}

通过Setter方法传递依赖关系

这种方式&＃xff0c;通过Setter方法&＃xff0c;为外部提供设置依赖对象的方式&＃xff0c;这种方法叫做Setter依赖注入&＃xff0c;示例如下&＃xff1a;

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 &＃61; car;}//司机的主要职责就是驾驶汽车public void drive(){this.car.run();}
}

通过接口方法传递依赖关系

我们最开始使用的&＃xff0c;就是这种方法&＃xff0c;也叫做接口注入。

最佳实践

依赖倒置原则&＃xff0c;在项目中使用可以使各个类或模块的实现彼此独立&＃xff0c;不互相影响&＃xff0c;实现模块间的松耦合&＃xff0c;那我们在项目中怎么应用这个原则呢&＃xff1f;有一下几个规则&＃xff1a;

• 尽量有接口或者抽象类

这也是依赖倒置原则的基础&＃xff0c;要依赖抽象就必须先有抽象才对。

• 变量的表面类型&＃xff0c;尽量是接口或者抽象类型

并不要求一定是接口或者抽象类型&＃xff0c;某些工具类&＃xff0c;或者是类的clone方法的使用&＃xff0c;就要求是实现类的类型。

• 实现类尽量不再派生

这只是一个软性规则&＃xff0c;在某些场景下&＃xff0c;例如设计有缺陷&＃xff0c;或者进行项目维护的时候&＃xff0c;也是可以从实现类中派生的&＃xff0c;根据具体的场景来做措施。

• 尽量不重写基类的方法

如果基类是抽象类并且已经实现了方法&＃xff0c;那么就尽量不要重写该方法&＃xff0c;因为该方法有可能会被其他的抽象所依赖&＃xff0c;重写该方法&＃xff0c;会破坏抽象接口的稳定性。

• 结合里氏替换原则

里氏替换原则同样可以应用到这里&＃xff0c;父类出现的地方子类就可以出现&＃xff0c;到我们这里可以理解为基类&＃xff0c;接口或者抽象类可以出现的地方&＃xff0c;就可以使用实现类对象&＃xff0c;由接口来定义公用的属性和方法&＃xff0c;抽象类实现公共的构造部分&＃xff0c;由实现类实现准确的业务逻辑&＃xff0c;并对父类进行细化。

小结

要想彻底理解依赖倒置&＃xff0c;我们先来说说依赖正置&＃xff0c;依赖正置指的是实现类依赖实现类&＃xff0c;这也是我们生活中的思考方式&＃xff0c;例如&＃xff0c;开车依赖宝马&＃xff0c;喝酒依赖二锅头&＃xff0c;等等&＃xff0c;这些是实现类之间的依赖&＃xff0c;而我们编程&＃xff0c;需要对现实世界的事物进行抽象&＃xff0c;接口和抽象类就是抽象的结果&＃xff0c;然后根据我们的系统设计&＃xff0c;这些抽象类和接口之间产生了依赖关系&＃xff0c;就产生了依赖倒置。

在小型项目中&＃xff0c;依赖倒置原则的优点很难体现&＃xff0c;但是在大型项目中&＃xff0c;依赖倒置原则的优点就会体现出来&＃xff0c;特别是用于规避一些非技术原因引起的问题&＃xff0c;项目越大&＃xff0c;需求变化的概率越大&＃xff0c;使用依赖倒置原则对实现类进行约束&＃xff0c;可以很好的避免因为需求变化导致工作量剧增&＃xff0c;另外&＃xff0c;如果在大型项目中人员变动&＃xff0c;则使用依赖倒置原则可以避免受到影响&＃xff0c;而且维护人员也可以简单轻松的进行维护。

依赖倒置原则是实现开闭原则的基础&＃xff0c;只要抓住“面向接口编程”这一核心思想&＃xff0c;基本上不会脱离依赖倒置原则太远。另外在项目中&＃xff0c;使用依赖倒置原则也要审时度势&＃xff0c;每一个设计原则的优点也是有限度的&＃xff0c;不要抓住原则不放&＃xff0c;而不考虑项目的实际情况&＃xff0c;原则是死的&＃xff0c;但是设计者是活的&＃xff0c;项目的实际状况是动态变化的&＃xff0c;项目的最终目标是上线和盈利&＃xff0c;技术只是实现目的的工具&＃xff0c;切忌耍花枪式的过度设计。