2019 新年第一篇。
设计模式六大原则之三:依赖倒置原则。
简介
姓名 :依赖倒置原则
英文名 :Dependence Inversion Principle
价值观 :大男子主义的典型代表,什么都得通过老大或者老爸同意。
伴侣 :一定是个温柔体贴的女子。
个人介绍 :
- 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. 细节应该依赖抽象(实现类依赖接口或抽象类)
给大家讲个故事,我胡乱想的,如有雷同,肯定是英雄所见略同。那必须交个朋友。
一个小村里,有两家饭馆,虽然挂着不同的牌子,挨在一起,但是老板确是表兄弟。这两兄弟抠得很,为了节省成本,密谋了一个想法:在两家饭馆谁家忙的时候,可以让不忙的那家的员工过去支援一下。这样子,本来每家饭馆都需要 2 个洗碗工,总共需要 4 个,他们就只招了 3 个,省了 1 个洗碗工的成本,当然不止洗碗工,还有服务员等等。两兄弟约定了规则:
- A 饭馆需要支援的时候,B 饭馆老板,让 B 饭馆老板选哪个员工去支援,不能直接让 A 饭馆的员工直接找 B 饭馆的员工去帮忙,但可以让 A 饭馆员工找 B饭馆老板告知需要支援。
- 虽然老板权利大,但是也不能说 A 饭馆老板直接叫 B 饭馆的员工去帮忙。
- 员工没有真实的老板,今天为 A 饭馆工作就是 A 饭馆的员工,没有跟定哪个老板。
大概通过这个小故事,描述了依赖倒置原则的基本内容。
代码体现
下面通过代码来模拟这个故事。
错误的示范
这个错误的示范将就看哈,可能有些问题没描述清楚。
老板和员工抽象
1 | abstract class Boss { |
老板具体类
1 | class BossA extends Boss { |
员工具体类
1 | class StaffA extends Staff { |
测试代码
1 | /** 初始化老板和员工 */ |
好像看起来实现了要求了,但是其实这段代码没有按照上面的 3 点规则编写,破坏了第 3 点规则,老板们的员工没有用员工的抽象类,破坏了细节依赖抽象这一点。设想一下,假如现在 A 老板把 A 员工辞退了,重新招了个 C 员工,那么怎么实现呢?是不是需要再新增一个 StaffC 类,然后再修改 BossA 类代码,把 StaffA 换成 StaffC。这样超级麻烦,在平时写项目中要时刻考虑这一点:在具体实现类使用其他类,是不是可以用其抽象类?
代码:
正确的示范
看了上面那个憋屈的代码,再来看下面简洁的代码,才会发现依赖倒置原则是多么强大。
老板和员工抽象类
1 | abstract class Boss2 { |
老板类
1 | class BossImpl extends Boss2 { |
员工类
1 | class StaffImpl extends Staff2{ |
测试类
1 | /** 正确示范 */ |
这代码相比上面错误的示范,简洁了很多,实现的功能却更灵活,这就是依赖倒置原则强大的地方,它可以将类的耦合性降低,提供灵活的处理。
代码:
最佳实践
- 变量的表面类型尽量是接口或者是抽象类
- 任何类都不应该从具体类派生
- 尽量不要覆写基类的方法
- 结合里氏替换原则使用
(来自《设计模式之禅》)
总结
总的来说,要实现依赖倒置原则,要有『面向接口编程』这个思维,掌握好这个思维后,就可以很好的运用依赖倒置原则。
参考资料:《大话设计模式》、《Java设计模式》、《设计模式之禅》、《研磨设计模式》、《Head First 设计模式》
希望文章对您有所帮助,设计模式系列会持续更新,感兴趣的同学可以关注公众号,第一时间获取文章推送阅读,也可以一起交流,交个朋友。