在传统的结构化编程中，最上层的模块通常都要依赖下面的子模块来实现，也称为高层依赖低层！

DIP原则就是要逆转这种依赖关系，让高层模块不要依赖低层模块.

教科书上的定义：
第1点：高层模块不依赖底层模块，两者都依赖抽象
第2点：抽象不应该依赖于细节，细节应该依赖于抽象

每个较高层次都为它所需要的服务声明一个抽象接口,较低的层次实现这些抽象接口,每个高层类都通过该抽象接口使用下一层的服务,接口属于高层,低层要实现高层的接口,因此现在是低层依赖于高层.
是依赖关系倒置和接口所有权的倒置.

启发式规则:
1.任何变量都不应该持有一个指向具体类的指针或者引用.
2.任何类都不应该从具体类派生(始于抽象,来自具体)
3.任何方法都不应该覆写它的任何基类中的已经实现了的方法.

这个原则对于那些虽然具体但是却稳定的类来说似乎并不是很合适， 如果一个类不太会改变， 而且也不太可能创建其他的派生类，那么依赖它似乎并没有太大的危害。比如java的String类。

（原文地址忘了，不好意思）
对上面的【1.任何... 2.任何... 3.任何...】 不是非常赞同。光看到词语就觉得有点极端化的感觉。
纯粹是菜鸟的个人感觉^^

意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

结构：

下面通过鸭子模拟器的设计来具体介绍。

公司需要设计一套鸭子模拟器系统，该系统的第一次需求为：鸭子能够戏水；鸭子能够呱呱叫。根据该需求系统设计如下：

这个设计主要用了父类鸭子和子类绿头鸭、红头鸭，这样设计的目的是为了达到代码的复用。

过了一段时间，公司希望该系统能够满足新的需求：有些鸭子会飞。因此该系统需要进行修改，修改后的系统可能如下：

该系统在父类中加了“fly（）”方法（在父类中加该方法是为了实现代码的复用）。这里就出现了两个问题：

（1）、所有的鸭子都会飞了。

（2）、所有鸭子的叫声都一样，都是“呱呱”叫。

注：这两个问题可以通过子类中方法覆盖来解除，但这样处理不是很好。鸭子的类别越多，这种处理的缺点就越明显。

其实这个系统的变化点是鸭子的叫声和鸭子的飞行能力，因此我们很容易想到把鸭子的叫声和鸭子的飞行能力做成接口，把这些变化的地方封装起来，这样上面的两个问题都可以解决，所以系统可能被修改为下面的样子：

MallardDuck和RedheadDuck既会飞又会叫，RubberDuck只会叫不会飞，DecoyDuck不会飞也不会叫。应该说这个系统没有问题了，从表面看这种设计完全符合需求，而且完全符合面向对象的理念，但是当鸭子的类别很多时，你会发现这种设计缺乏代码的复用，这两个独立出来的接口似乎没有任何意义，根本无法减轻工作量，还不如原来的设计呢。所以你可能会想到问题的关键是接口中的方法没有实现，那我们该怎么办呢？

我们的做法是把接口做成类，运用组合的方法来实现需求。考虑到“针对接口编程，而不是针对实现编程”的设计原则，我们的系统可能就会设计成如下的结构，这个结构就是应用了“策略”模式。

 
源代码下载：/Files/wxj1020/MiniSimuDuck.rar

1、慢一点，你理解的越多，需要记的就越少。

2、勤做练习，自己记笔记。

3、上床睡觉之前不要再看别的书了，或者至少不再看其他有难度的东西。

4、要喝水，而且要多喝点水。

5、大声说出来。

6、听听你的大脑怎么说。

7、要有点感觉！

8、设计一点东西！

书中列举的设计原则：

1、封装变化。找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。

2、针对接口编程，而不是针对实现编程。

举例说明：

假设有一个抽象类Animal，有两个具体的实现（Dog与Cat）继承Animal。

“针对实现编程”的做法：Dog d = new Dog();d.bark();

“针对接口编程”的做法：Animal animal = new Dog();animal.makeSound();

                                或者：Animal animal = getAnimal();animal.makeSound();

3、多用组合，少用继承。

原因：

       a、继承会使类无限膨大，可能会使类变得臃肿。

       b、子类可能会继承父类中那些无用甚至有害的方法。

       c、组合比继承更灵活，可以实现在执行中动态改变对象的功能。

4、为了交互对象之间的松耦合设计而努力。

5、类应该对修改关闭，对扩展开放。