以前咱们对设计模式的六大原则作了简单概括,这篇博客是对依赖倒置原则进行的举例说明。
DIP是6大原则中最难以实现的原则,它是实现开闭原则的重要途径,DIP没有实现,就别想实现对扩展开放,对修改关闭。在项目中只要记住“面向接口编程”就基本上抓住了DIP的核心
对各类概念进行一个描述:java
咱们先要写出低耦合高内聚的代码,在java中须要遵循以下原则:
1. 模块间的依赖经过抽象类或接口发生,实现类之间的依赖关系也是经过抽象类或接口产生(实现类之间不该发生直接的依赖关系),下降系统的耦合性
2. 接口或抽象不依赖于实现类,但实现类依赖接口或抽象类,实现类对系统须要的功能具体实现,提升类的内聚程度web
1.数据访问抽象层:
“高层模块不该该依赖于低层模块,两者都应该依赖于抽象。”这一原则在分层架构模式中,获得了淋漓尽致地运用。
例如,业务逻辑层(高层模块)的对象就不该该直接依赖于数据访问层(低层模块)的具体实现对象(具体说的是:咱们在编写业务代码的时候,不该该直接在某个业务代码处直接用jdbc操做数据库,而是业务层方法的参数应该是数据访问层的抽象),而应该经过数据访问层的抽象接口进行访问,以下图所示。若是高层模块直接依赖于低层模块,一旦低层模块发生变化,就会影响到高层模块。经过引入抽象,对于高层模块而言,低层模块的实现是可替换的。这实际上也是”开放封闭原则”的体现。
这一原则同时还体现了软件设计对”间接”的追求。下图中的数据访问抽象层就是在设计中引入的一层间接性:
数据库
2.汽车驾驶的一个例子
咱们第一次设计驾驶员驾驶奔驰汽车的时候,由于场景单一,颇有可能就会陷入到面向实现编程(这里只是为了展示问题),固然最小需求时,能够这样作:
编程
代码以下:
场景运行结果以下:
设计模式
如今张三赚了一些钱,买了一辆宝马汽车:架构
宝马有了,却不能让张三开起来,这也太不合理了,咱们的设计出了问题:司机类和奔驰类之间是紧耦合的关系,其致使的结果就是系统的可维护性大下降,可读性下降。//若须要改成开宝马,必须得更改司机类的public void drive(Benz benz)(低层模块,太不该该)现根据DIP原则,从新编写以下
svg
实现的代码:
汽车:
司机:
场景:
运行结果:
函数
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();
}
}
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();
}
}
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();
}
}