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

英文名称：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中增加很多属于自己的方法而不影响到其他类。哈哈，原来将系统的关系理清楚了是这么的心里舒畅！现在仔细想想自己设计的系统个，有点纠结啊，好多东西没有遵循规则！

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!