设计原则利剑三-依赖倒置原则

前端之家收集整理的这篇文章主要介绍了设计原则利剑三-依赖倒置原则前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

英文名称:Dependence Inversion Principle(DIP)

中文名称:依赖倒置原则

原 则:

1、高层模块不应该依赖底层模块,两者都应该依赖其抽象

2、抽象不应该依赖细节

3、细节应该依赖抽象

作 用:该设计模式的本职就是通过抽象(接口或者抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合。

真 言:

1、每个类尽量都有接口或抽象类,或者接口和抽象类两者都有(可能觉得复杂,可是当项目复杂的时候非常有用)

2、变量的表面类型尽量使接口或者是抽象类(这样可以避免在增加子类的时候无需更改相关类)

3、任何类都不应该从具体类派生

4、尽量不要覆写基类的方法

5、结合里氏替换原则(要实现父类中所有的方法

说 明:文章系本人学习设计模式后的读后感,属于原创,转载请注明出处,谢谢!本人邮箱:wyxhd2008@yahoo.com.cn

深刻理解:凡是有关系的类,千万不要通过实体类来发生关系,而应该先将其抽象,让抽象类之间进行协议,感觉有点像我们古代的指腹为婚的方式,婚姻父母做主,有女儿的父母有个女儿,有儿子的父母有个儿子,然后父母去互相找对象,哈哈,有点残忍。

理论实践:

先看看下图所展示的两个类之间的关系,司机与奔驰车之间是强耦合关系,如果车子一旦变更为宝马,那么司机中又得增加一个方法才能够解决此问题,很明显,这种不遵守依赖倒置原则的设计对于大型项目完全是不可取的。如同找媳妇一样,如果将媳妇定义为具体某个人,一旦哪个人不再爱你,那你将怎么办?生活中有很多这样的悲剧,所以两个具体类之间不要有任何的依赖关系,而应该升级为男人与女人之间的依赖关系。

使用倒置原则,对两个类进行抽象化设计,定义抽象类之间的关系,从而使得司机可以随意开任意一辆车。娘的,ROSE真的不好用,还是用回EA

忽然想想,男人和女人的例子也是一样,设计好依赖关系,上UML图如下:可以说唐伯虎是真正掌握了泡妞大法的,要是唐伯虎跟每个女人都要发生上关系,那么他不是很累?如果没有依赖倒置原则,那么就没有唐伯虎点秋香的故事了,嘿嘿。

既然抽象类之间来负责依赖关系,那么依赖的实现又有那几种方式呢?

1、用构造函数

2、用set方法构造

3、在接口中申明依赖于该对象,实现类必须要传值过去

依赖倒置原则在日常的设计中也经常使用到,但是并不彻底,分析我现在设计的系统中,基本上没有设计过接口和抽象类,例如在ApplicationFolder类与ContentViewControl的交互中,我没有将ContentViewControl这个类定义为抽象类,而定义的都是实体类,在实体类中都都定义好了可重写的方法Overridable标识,那么当我系统中的设计方式会出现如下蹩脚的设计模式,上UML图如下:

其实我系统设计的这个模式也完全能够满足需要,只是每次生成一个ListView一定要记得去实现其中的方法,要是忘记了忘记了,这种设计应该是属于违反了高层模块依赖于底层模块,而又想到我这个View有三种模式,一种是HomePageView,一种是ListView,一种是GraphView,现在实现的方式全部都是实现ContentViewControl类来实现,在子类中不实现其方法,算是一种偷懒的方法,但是对用户体验绝对是不好的,不小心也容易出错,那么综合已经学到的三个设计模式:职责单一原则,里氏置换原则,依赖倒置原则我重新设计我系统这几个类之间的关系,上UML图如下:

经过上面的实施,在MainForm中来分别处理这三种情况,如果是HomePage,那么久将相应的F2,F5,导出等功能全部屏蔽掉,是图形则仅仅显示导出图片功能,是列表则需要提供相关功能,而在子类的实施中则更加的简单,如HomePage子类则不用浪费任何代码来写其他类型所需要的方法,而我现在设计的系统中则很难做到这一点,要做到也可以,但是每增加一个显示的列表,那么就必须要在MainForm判断一次,这就违背了类与类之间依赖的关系,这么设计后,系统的结构清晰多了,并且我可以在HomePageControl中增加很多属于自己的方法而不影响到其他类。哈哈,原来将系统的关系理清楚了是这么的心里舒畅!现在仔细想想自己设计的系统个,有点纠结啊,好多东西没有遵循规则!

原文链接:https://www.f2er.com/javaschema/287566.html

猜你在找的设计模式相关文章