设计模式-依赖反转分析
2017-11-06 22:26
162 查看
上一篇文章中我复习了开放封闭原则,今天我来回顾下依赖倒转原则。
依赖倒转原则:
1.高层不依赖低层,高层和低层应依赖抽象
2.抽象不依赖细节。细节依赖抽象
这一原则是基于现实中完成一件事情手段的多样性,过程的稳定性而提出来的,手段对应细节,过程对应抽象。
在java中抽象可以有接口和抽象类来表示,细节有继承和实现来完成。程序的整体流程应通过接口之间行为的交互来完流动,动作的具体实现则有子类和实现类来掌控。
例如:主板有cpu,内存。显卡,风扇等构成,如果正对具体型号的配件进行编程,将会导致配件升级整个主板就被废弃掉,只针对主板上的某一个组件卡槽进行升级很可能和会导致与其他不见兼容不好而导致性能下降。为了避免这种情况的产生,我们将主板的构成抽象成接口,并辅以接口的对接协议来规范化相关组件的升级和研制,当主板无法支撑相关组件的性能时或组件有质的飞跃是修改接口和协议来进行变革。
由此可见面向接口编程的便利性,接口编程主要有三种实现方式:
1.接口传递
2.构造传递
3.setter传递
在实现依赖倒转原则时,我们要思考一下三方面:
1.低层模块尽量要有接口或者抽象类,或者都有。
2.变量的声明尽量是接口或抽象类。
3.要遵守里氏替换法则:子类一定能够替换父类。
此法则可以参照Sping中的实现方式来进一步学习和思考
依赖倒转原则:
1.高层不依赖低层,高层和低层应依赖抽象
2.抽象不依赖细节。细节依赖抽象
这一原则是基于现实中完成一件事情手段的多样性,过程的稳定性而提出来的,手段对应细节,过程对应抽象。
在java中抽象可以有接口和抽象类来表示,细节有继承和实现来完成。程序的整体流程应通过接口之间行为的交互来完流动,动作的具体实现则有子类和实现类来掌控。
例如:主板有cpu,内存。显卡,风扇等构成,如果正对具体型号的配件进行编程,将会导致配件升级整个主板就被废弃掉,只针对主板上的某一个组件卡槽进行升级很可能和会导致与其他不见兼容不好而导致性能下降。为了避免这种情况的产生,我们将主板的构成抽象成接口,并辅以接口的对接协议来规范化相关组件的升级和研制,当主板无法支撑相关组件的性能时或组件有质的飞跃是修改接口和协议来进行变革。
由此可见面向接口编程的便利性,接口编程主要有三种实现方式:
1.接口传递
2.构造传递
3.setter传递
在实现依赖倒转原则时,我们要思考一下三方面:
1.低层模块尽量要有接口或者抽象类,或者都有。
2.变量的声明尽量是接口或抽象类。
3.要遵守里氏替换法则:子类一定能够替换父类。
此法则可以参照Sping中的实现方式来进一步学习和思考
相关文章推荐
- C#设计模式之控制反转即依赖注入-微软提供的Unity
- Ioc 器管理的应用程序设计,前奏:容器属于哪里? 控制容器的反转和依赖注入模式
- 【设计模式】控制反转(IoC)与依赖注入(DI)
- Java设计模式之依赖反转(倒置)原则(Dependency inversion principle,DIP)
- C#设计模式之控制反转即依赖注入-Spring.NET
- 【设计模式】依赖反转原则
- 架构设计之源:设计模式的场景分析(1)Publish-Subscribe
- Spring 框架的设计理念与设计模式分析
- 23种设计模式分析(2):创建型模式
- Java设计模式之从[游戏中的兵种状态转换]分析状态(State)模式
- 分析状态(State)模式的Java设计模式
- JS设计模式之策略模式概念与用法分析
- Spring 框架的设计理念与设计模式分析
- JUnit设计模式分析
- 浅谈MVC架构模式分析与设计
- 关于控制反转(IOC)容器 ,依赖注入(DI)模式必读文章收集
- spring框架的设计理念与设计模式分析
- JAVA IO 设计模式彻底分析
- [转] 依赖注入&控制反转 oC 容器和Dependency Injection 模式(中文版)
- 控制反转和依赖注入的设计模式