依赖倒置原则的理解

1.问题由来：类A直接依赖类B，假如要将类A改成依赖类C，则必须经过修改类A的代码来达成。这种场景下，类A通常是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操做；假如修改类A，会给程序带来没必要要的风险。

2.解决方案：将类A修改成依赖接口I，类B和类C各自实现接口I，类A经过接口I间接与类B或者类C发生联系，则会大大下降修改类A的概率。（其实换成接口，可能下面的不少代码都不须要变了，若是仍是A，B的对象实例，那么下面的代码可能会发生修改。）

3.依赖倒置原则针对的是接口编程。

4.对于容易发生的变化的地方，提供接口，接口具备高度抽象性，让其进行接收，这样就能够极大的减小修改高层模块中的代码。

上面的仅仅是纯概念自己的理解：

如下是货真价实的理解。

继承的做用是复用前人写的代码

多态的做用是前人写好的框架，该框架能够调用后来人写好的代码。这正是设计模式的精髓。想一想也是。（这就是可扩展，这是否是很厉害）。

举例说明：

假设计算机有3大重要部件：cpu，硬盘，内存条

为了可以让计算机可以和三大部件进行解耦合，意思就是计算机能够安装任何型号的cpu，硬盘，内存条。设计原则就是让计算机依赖三大部件（高层依赖于抽象层），让实现层依赖于抽象层，各类类型的cpu去继承抽象层，这样达到了高层和实现层的解耦合，也让实现层和实现层之间解耦合。