对于抽象层次来说,它是一个系统的本质的概括,是系统的商务逻辑和宏观的,战略性的决定,是必然性的体现;具体的层次则是与实现有关的算法和逻辑,一些战术性的决定,带有相当大的偶然性.传统的过程性系统设计办法倾向于使高层次的模块依赖于低层次的模块;抽象层次依赖于具体层次.这实际上就是微观决定宏观,战术决定战略,偶然决定必然.依赖倒转原则就是要把这种错误的依赖关系倒转过来.
许多的建构设计模型,例如COM,CORBA,JavaBean,EJB等,它们背后的基本原则就是DIP.
对于软件设计的两个目标,复用和可维护性来说,传统的设计侧重于具体层次模块的复用和可维护,比如算法,数据结构,函数库等等.但是,对系统的抽象是比较稳定的,它的复用是很重要的,同时,抽象层次的可维护性也应当是一个重点.就是说DIP也导致复用和可维护性的"倒转".
我们现在来看看依赖有几种,依赖也就是耦合,分为下面三种
- 零耦合(Nil Coupling)关系,两个类没有依赖关系,那就是零耦合.
- 具体耦合(Concrete Coupling)关系,两个具体的类之间有依赖关系,那么就是具体耦合关系,如果一个具体类直接引用另外一个具体类,就会发生这种关系.
- 抽象耦合(Abstract Coupling)关系.这种关系发生在一个具体类和一个抽象类之间,这样就使必须发生关系的类之间保持最大的灵活性.
DIP要求客户端依赖于抽象耦合,抽象不应当依赖于细节,细节应当依赖于抽象(Abstractions should not depend upon details. Details should depend upon abstractions),这个原则的另外一个表述就是"四人团"强调的那个:要针对接口编程,不要对实现编程.(Program to an interface,not an implementation),程序在需要引用一个对象时,应当尽可能的使用抽象类型作为变量的静态类型,这就是针对接口编程的含义. DIP是达到"开-闭"原则的途径.
要做到DIP,用抽象方式耦合是关键.由于一个抽象耦合总要涉及具体类从抽象类继承.并且需要保证在任何引用到某类的地方都可以改换成其子类,因此,LSP是DIP的基础.DIP是OOD的核心原则,设计模式的研究和应用都是用它作为指导原则的.DIP虽然强大,但是也很难实现.另外,DIP是假定所有的具体类都会变化,这也不是全对,有些具体类就相当稳定.使用这个类的客户端就完全可以依赖这个具体类而不用再弄一个抽象类.
原文链接：https://www.f2er.com/javaschema/286931.html