4 依赖
依赖可以传递,A对象依赖B对象,B又依赖C,C又依赖D……
只要做到抽象依赖,即使是多层的依赖传递也无所畏惧!
对象的依赖关系有如下传递方式:
构造器传递
在类中通过构造器声明依赖对象,构造函数注入
4.2 Setter传递
在抽象中设置Setter方法声明依赖关系,Setter依赖注入
4.3 接口声明依赖对象
在接口的方法中声明依赖对象
5 最佳实践
依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合
。
DIP指导下,具体类能少用就少用。
具体类我们还是要用的,毕竟代码要运行起来不能只依赖于接口。那具体类应该在哪用?
这些设计原则,核心关注点都是一个个业务模型。此外,还有一些代码做的工作是负责组装这些模型,这些负责组装的代码就需要用到一个个具体类。
做这些组装工作的就是DI容器。因为这些组装几乎是标准化且繁琐。如果你常用的语言中,没有提供DI容器,最好还是把负责组装的代码和业务模型放到不同代码。
DI容器另外一个说法叫IoC容器,Inversion of Control,你会看到IoC和DIP中的I都是inversion,二者意图是一致的。
依赖之所以可注入,是因为我们的设计遵循 DIP。而只知道DI容器不了解DIP,时常会出现让你觉得很为难的模型组装,根因在于设计没做好。
DIP还称为好莱坞规则:“Don’t call us, we’ll call you”,“别调用我,我会调你的”。这是框架才会有的说法,有了一个稳定抽象,各种具体实现都应由框架去调用。
为什么说一开始TransactionRequest是把依赖方向搞反了?因为最初的TransactionRequest是一个具体类,而TransactionHandler是业务类。
我们后来改进的版本里引入一个模型,把TransactionRequest变成了接口,ActualTransactionRequest 实现这个接口,TransactionHandler只依赖于接口,而原来的具体类从这个接口继承而来,相对来说,比原来的版本好一些。
对于任何一个项目而言,了解不同模块的依赖关系是一件很重要的事。你可以去找一些工具去生成项目的依赖关系图,然后,你就可以用DIP作为一个评判标准,去衡量一下你的项目在依赖关系上表现得到底怎么样了。很有可能,你就找到了项目改造的一些着力点。
理解了 DIP,再来看一些关于依赖的讨论,我们也可以看到不同的角度。
比如,循环依赖,循环依赖就是设计没做好的结果,把依赖关系弄错,才可能循环依赖,先把设计做对,把该有的接口提出来,就不会循环了。
我们怎么在项目中使用这个规则呢?只要遵循以下的几个规则就可以:
每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备
这是依赖倒置的基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置
变量的表面类型尽量是接口或者是抽象类
很多书上说变量的类型一定要是接口或者是抽象类,这个有点绝对化了
比如一个工具类,xxxUtils一般是不需要接口或是抽象类的
如果你要使用类的clone方法,就必须使用实现类,这个是JDK提供的一个规范。
任何类都不应该从具体类派生
如果一个项目处于开发状态,确实不应该有从具体类派生出子类的情况,但这也不是绝对的,因为人都是会犯错误的,有时设计缺陷是在所难免的,因此只要不超过两层的继承都是可以忍受的
尽量不要覆写基类方法
如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写
类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响
结合里氏替换原则使用
父类出现的地方子类就能出现, 接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化。
到底什么是“倒置”
依赖正置就是类间的依赖是实实在在的实现类间的依赖,也就是面向实现编程,这也是正常人的思维方式,我要开奔驰车就依赖奔驰车,我要使用笔记本电脑就直接依赖笔记本电脑。
而编写程序需要的是对现实世界的事物进行抽象,抽象的结果就是有了抽象类和接口,然后我们根据系统设计的需要产生了抽象间的依赖,代替了人们传统思维中的事物间的依赖,“倒置”就是从这里产生的
依赖倒置原则是实现开闭原则的重要途径,依赖倒置原则没有实现,就别想实现对扩展开放,对修改关闭。
只要记住面向接口编程就基本上抓住了依赖倒置原则的核心。
依赖倒置原则说的是:
1.高层模块不应依赖于低层模块,二者都应依赖于抽象
2.抽象不应依赖于细节,细节应依赖于抽象
总结起来就是依赖抽象(模型),具体实现抽象接口,然后把模型代码和组装代码分开,这样的设计就是分离关注点,将不变的与不变有效的区分开
防腐层可以解耦对外部系统的依赖。包括接口和参数。防腐层还可以贯彻接口隔离的思想,以及做一些功能增强(加缓存,异步并发取值)。
参考
设计模式之婵