依赖倒转原则DIP

依赖倒转原则DIP（Dependency Inversion Principle）

主要是通过在具体对象之上再建立一层抽象对象，使具体对象的构造能更加灵活，降低耦合。比如观察者模式，使耦合的双方都依赖于抽象，而不是两个具体对象相互直接依赖。

“开放-封闭”原则是我们OOD的目标，达到这一目标的主要机制就是“依赖倒转”原则(DIP)这个原则的内容是：要依赖于抽象,不要依赖于具体。或者说是：要针对接口编程，不要对实现编程(Program to an interface, not an implementation)。
     对于抽象层次来说，它是一个系统的本质的概括是系统的商务逻辑和宏观的，战略性的决定，是必然性的体现；具体的层次则是与实现有关的算法和逻辑，一些战术性的决定，带有相当大的偶然性。传统的过程性系统设计办法倾向于使高层次的模块依赖于低层次的模块；抽象层次依赖于具体层次。这实际上就是微观决定宏观，战术决定战略，偶然决定必然。依赖倒转原则就是要把这种错误的依赖关系倒转过来。
     许多的建构设计模型，例如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是假定所有的具体类都会变化，这也不是全对，有些具体类就相当稳定。使用这个类的客户端就完全可以依赖这个具体类而不用再弄一个抽象类。 (引用到此结束)
     对于接口以及接口的作用，让我们用一个类比来理解，这样会更加的直观，我们平时用的插座就可以看做一种接口，我们只通过它就可以用电了，假若供电方式发生了变化，比如由现在的火力发电变为太阳能发电，整个供电线路要进行全面的改修，那麽我们的用电方式并不会受到影响还是通过插座来用电，供电方式发生的变化和线路的改变对我们来说是透明的，这样作的好处通过对比一下下面的情形就可以知道了，假若我们没有通过插座来用电，而是直接与供电站直接通过电线连接，除去安全性的问题不说，若供电方式发生了变化，线路要进行改修，那麽可能就会有人敲你家的门说：“你好，我们是来改装电线的”，而且可能是在凌晨2:00，为什么？城市的每一户人家都要进行这样的改装啊，电路改装人员的工作量实在是太大了，只能7*24的工作了。所以还是打开门吧，否则只能过着没有电的日子了。所以我们通过插座(接口)带来的好处是不是很明显了呢？它降低用电方和供电方的耦合，为变化的实施带来了便利。
     接口是实现插件化(pluggability)的关键，对象间的连接不必硬绑定(hardwire)到一个具体类的对象上，而是绑定在一个较高层次的抽象之上(接口或者抽象类)因此增加了类的灵活性，可以自由的进行“插拔”。通过接口或抽象类可以降低类之间的耦合，一个对象可以很容易地被(实现了相同接口的)的另一个对象所替换，而不会影响这个对象本身，所以一切的变化完全在此对象不知情的情况下进行。