投资集团网站建设,小规模公司需要交哪些税,北京梵客装饰,做app模板下载网站目录 定义原始定义进一步的理解 作用实现方法代码示例 面向对象设计原则之开-闭原则 面向对象设计原则之里式替换原则 面向对象设计原则之依赖倒置原则 面向对象设计原则之单一职责原则
定义
依赖倒置原则#xff08;Dependence Inversion Principle#xff09;#xff0c… 目录 定义原始定义进一步的理解 作用实现方法代码示例 面向对象设计原则之开-闭原则 面向对象设计原则之里式替换原则 面向对象设计原则之依赖倒置原则 面向对象设计原则之单一职责原则
定义
依赖倒置原则Dependence Inversion Principle缩写为DIP。
原始定义
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 翻译一下高层模块不应该依赖低层模块两者都应该依赖其抽象抽象不应该依赖细节细节应该依赖抽象。
进一步的理解
到底什么“倒置”要理解什么是倒置我们先理解一下“正置”即正常的依赖是什么样子的。比如我们经典的三层架构controller层调用BL层BL层调用DAO层。由于每一层都是依赖于下层的实现这样当某一层的结构发生变化时它的上层就不得不也要发生改变比如我们DAO里面逻辑发生了变化可能会导致BL和Controller层都随之发生变化这种架构是非常荒谬的
好这个时候如果我们换一种设计思路高层模块不直接依赖低层的实现而是依赖于低层模块的抽象具体表现为我们增加一个IBL层里面定义业务逻辑的接口controller层依赖于IBL层BL层实现IBL里面的接口所有具体的业务逻辑则实现在BL里面这个时候如果我们BL里面的逻辑发生变化只要接口的行为不变上层Controller里面就不用发生任何变化。
以上我们引入面向接口编程的概念增加了接口IBL层那倒置到底该如何理解难道依赖抽象面向接口就是倒置了
我觉得可以从软件项目越来越大开发团队人员越来越多的发展现状来理解高层A依赖于低层B即A要调用B提供的方法那么在B开发完成之前A层是没发开发或者开发完没法编译通过和单元测试的。修改为高层A依赖于抽象层C抽象层C是属于A层的即由A层来规定抽象层C的接口规范低层B也依赖于抽象层C来具体实现C中的接口因此通过引入C层来达到了“倒置”。通过该倒置引入C层来规范A和B 可以同时 来开发不必相互等待依赖。这里的倒置既有模块依赖上的倒置更有在解决问题时思考和规划上的倒置即要先进行良好的顶层规划设计约定好接口规范而具体的逻辑编写都是基于规范的具体而已。
作用
可以减少类间的耦合性、提高系统稳定性。提高代码可读性和可维护性可降低修改程序所造成的风险。可以减少并行开发引起的风险。
实现方法
主要就是合理的抽象接口类并定义接口方法。以下代码示例中以 司机驾车为例结合代码重构过程来具体说明。
代码示例
司机驾驶奔驰车的类图起初 我们设计的都是具体实现类司机类依赖于奔驰车类Client类中有司机有车可以具体创建对象来使用了。 package com.will.tools.model.dip;public class Benz {public void run(){System.out.println(奔驰汽车跑起来...);}
}奔驰车可提供一个方法run代表车辆运行。
package com.will.tools.model.dip;public class Driver {public void drive(Benz benz){benz.run();}
}开车调用奔驰车的run方法。
package com.will.tools.model.dip;public class Client {public static void main(String[] args) {Driver guojing new Driver();Benz benz new Benz();//郭靖开奔驰guojing.drive(benz);}
}Client创建 司机郭靖和奔驰车并让郭靖开奔驰车。
现在来了新需求郭靖司机不仅要开奔驰车还要开宝马车又该怎么实现呢
先把宝马车创建出来如下
package com.will.tools.model.dip;
public class BMW {public void run(){System.out.println(宝马汽车跑起来...);}
}宝马车产生了但郭靖却没有办法开起来为什么 郭靖Driver没有开动宝马车的方法一个拿有C1驾照的司机竟然只能开奔驰车而不能开宝马车这太不合理了在现实世界都不允许这样干何况程序还是对现实世界的抽象呢。
这说明我们的设计出了问题司机类和奔驰车类紧耦合了导致系统可维护性和可读性降低。这里只是增加了一个车类却要修改司机类被依赖者变更了却需要让依赖者来承担修改成本这没有稳定性可言。
另外对于并行开发的风险也很大没有奔驰车类司机类根本编译不过去。 因此我们重构一下引入DIP如下 建立两个接口IDriver和ICar分别定义了司机和汽车的各个职能司机就是驾驶汽车必须实现drive()方法。汽车就是能run。
package com.will.tools.model.dip;public interface ICar {void run();
}package com.will.tools.model.dip;public interface IDriver {void drive(ICar car);
}package com.will.tools.model.dip;public class Driver implements IDriver {Overridepublic void drive(ICar car) {car.run();}
}接口只是一个抽象化的概念是对一类事物的最抽象描述具体的实现代码由相应的实现类来完成。
IDriver通过传入ICar接口实现了抽象之间的依赖关系Driver实现类也传入了ICar接口至于到底是哪个型号的Car需要声明在高层模块。
宝马汽车和奔驰汽车都实现ICar接口并各自实现run方法。
package com.will.tools.model.dip;public class Benz implements ICar {Overridepublic void run() {System.out.println(奔驰汽车跑起来...);}
}package com.will.tools.model.dip;public class BMW implements ICar {Overridepublic void run() {System.out.println(宝马汽车跑起来...);}
}业务场景应贯彻“抽象不应依赖细节”即抽象ICar接口不依赖BMW和Benz两个实现类细节因此在高层次的模块中应用的都是抽象,传入的参数都是ICar,如下
package com.will.tools.model.dip;public class Client {public static void main(String[] args) {
// Driver guojing new Driver();
// Benz benz new Benz();
// //郭靖开奔驰
// guojing.drive(benz);IDriver guojing new Driver();ICar benz new Benz();guojing.drive(benz);ICar bmw new BMW();guojing.drive(bmw);}
}Client属于高层业务逻辑它对低层模块的依赖都建立在抽象上。guojing的表面类型是IDriverbenz的表面类型是ICar。这时guojing再要开宝马车的话就只需要在高层业务类Client中直接调用即可而不用修改Driver类。
