《设计模式》-原则三：依赖倒置原则（DIP）

　　这几天晚上回来都去玩了！没有坚持学习。真的好惭愧！ 非常自责 后面一定要坚持 一气呵成  争取每天学一点，把这个学完。

　　今天主要是看了一下  设计模式中的 原则三： 依赖倒置原则(DIP)

　　官方是这样定义的：所谓依赖倒置原则指的是是要依据抽象编程，不要依赖与具体。要求客户端依据抽象进行耦合。

　　意思也就是说抽象不应当依赖于具体，具体应该依赖抽象。要针对接口编程，不要针对具体编程。

　　额，看到了 官方的定义，在来谈谈自己的认识吧。说得挺简单的哈，抽象、抽象、再抽象。做起来可就不是那么容易了。

　　我的理解是这样的，所谓依赖倒置原则 就是把现实的业务逻辑进行抽象化，现实一点具体一点的意思就是说，拿到一个东西先别慌着去实现，而是分析一下可以分为几个步骤。找出主线环节，并针对每个环节 定义接口 或者定义抽象类，然后再继承接口或者抽象类进行实现。那么如果有业务扩充也只是多派生一个实现类而已，不会影响到整个系统的结构，这一点也就是之前所说的“开闭原则” 针对系统结构保持稳定，针对新的业务进行扩展。 那么就可以保证上层调用的稳定性了。

　　举个例子：假如现在要实现一个打印查询结果的功能。如果按照以前的思维就是  直接拿着查询条件去查询数据，然后拿着数据去执行打印导出。

　　那么如果要 用面向对象的思维去做的话  我的想法是 可以分为这几个部分一、组合查询条件 二、根据查询条件进行读取数据 三、根据数据进行导出。

　　这样分的主要考虑是  查询条件可能以后会增加、读取的数据纬度会发生变化（比如添加读取字段）、导出的模板格式或者导出的文件格式会发生变化。

　　那么会有一个抽象类   里面定义 三个抽象方法（获取查询条件、依据查询条件读取数据、依据数据进行导出） 然后可以将这三个方法基于接口进行实现， 在调用的时候只用 继承抽象类根据业务要求调用对应的实现接口去实现对应的打印导出。

　　额 想的也就这么多了。 也可能因为急于求成导致调入设计陷阱。 有老鸟看到还望指点一二！