经过一段时间对大话设计模式的学习，发现其中有几个特别基础的原则，对于这些原则我们必须有个清楚的认知，才能更好的向下进行我们的学习内容。其中依赖倒转原则在后面的一些设计模式中都有涉及，所以感觉很有必要进行学习。

前提：

电脑坏了，很简单的通过电话交流，拆下一个内存条，电脑就这样简单的被修好了，这样是不是也太简单了。。原因在哪？大家都拆过电脑，在PC端都采用的是易插拔的方式，不管哪一个坏了，仅仅更换或修改那一个就可以了。这个就是面向对象中高内聚，低耦合。cpu大家都在用，却只有那么几个公司在生产，内聚很强，独自为产品。CUP和显卡，内存条之间的联系很微弱。不存在其中一个损坏，所有东西都不能使用的现象。它们都是针对接口设计，而不是针对品牌设计。说白了就是无论是哪个公司生产的，只要接口一样，大家都可以使用。

何为依赖倒转原则？

A、一直在强调高层模块不应该依赖低层模块。两个都应该依赖抽象。

B、抽象不应该依赖细节。细节应该依赖抽象。

一直在强调抽象不应该依赖细节，细节应该依赖抽象。这是什么意思？面对对象的程序设计中三大基本特征：封装，继承，多态。个人感觉现在所说的依赖倒转原则就类似于封装。不是去面对过程实现编程功能，而是针对接口编程。细节应该依赖抽象：提前提供一个接口，需要实现具体的功能，就去封装一个功能，然后去实现这个接口。抽象依赖细节这个意思就是先做一个功能，然后在去做一个接口实现，现在做的弊端没有统一的定义，做一个功能，就需要有一个接口去实现。而第一种则是先制定一个规范，然后大家再去针对规范，做事情，去符合规范要求，在实现具体的功能。上述内容都在讲述何为依赖。那为什么要叫倒转？在PC存在这样的问题，CUP，内存条等都需要依赖主板，但是主板坏了，其他的部件都不能用了。这个也不符合我们需求啊，不能因为一个损坏，造成全体瘫痪啊。我们的目的是为更好的复用。其实主板和CUP等内容都是模块，只不过一个是低层模块，一个是高层模块。所以两者之前不应该是依赖关系，而是它们需要依赖抽象。

到现在就涉及到一个新的原则——里氏代换原则。

里氏代换原则

子类型必须能够替换掉它们的父类型。在软件里面，把父类都替换成它的子类，程序的行为没有变化。

就用书中的例子在编程的世界里，就不能用企鹅来代替鸟类。

只有当子类可以替换掉父类，软件不受到影响的时候才能真正被复用，而子类也能够在父类的基础上增加新的行为。例如动物类，都拥有吃，跑等行为，所以当我们需要狗，猫，类似行为是，继承于动物时，只需要实例，程序其他处不需要改变。

【总结】

之前没有好好看看这些基本的原则，以至于后面再学习别的模式的时候，感觉到有些费劲。一步一步走踏实还是很重要的。这个依赖倒转原则其实也没什么，好好研究一下，就行了。细节依赖抽象，实现最大程度的复用。