依赖倒换原则（DIP）

依赖倒换原则（DIP）

要依赖于抽象，不要依赖于具体实现。DIP跟另一种说法含义相近：面向接口编程。

         不知道何时有“层”这个说法，尽管你不会一眼看出XX软件分为几个层，但是确实这样的分层是有理由的，分开即耦合度降低，各司其责。你可以想想你所在公司的管理制度，那是一个金字塔模型。上层是高层管理人员，它们下发的命令直接影响最底层的工人，而最底层工人具体的工作内容并不影响上面的高层管理人员。商务逻辑层不能依赖于实现层，公司的架构师要负责商务逻辑层的维护，底层coder负责实现层，公司不可能将这种逻辑依赖于实现层，不仅仅是coder和架构师的素质差别，更重要的是这根本就是一个错误的逻辑。

         依赖倒换原则是COM、CORBA、JavaBean以及EJB等架构设计模型背后的基本原则。

         依赖的种类：零耦合关系（两个类没有发生任何相互引用）、具体耦合关系（两个具体类直接引用对方的具体类型）、抽象耦合关系（两个类的引用利用其抽象类或者接口来实现，这是DIP的核心）。

         怎么实现依赖倒换原则？实现层要依赖于抽象层，那么所有的商务逻辑必须在抽象层制定好，而且要更改实现层的实现方式时，必须保证抽象层不做任何改变。通过定义抽象类和接口来实现商务逻辑的集中控制，通过面向接口编程来保证当实现层改变实现方式时，抽象层的商务逻辑不做改变。针对接口编程意思是说：应当使用抽象类和接口进行变量的类型声明、参量的类型声明、方法的返还类型声明以及数据类型的转换等。

         模板方法直观的为我们解释了通过定义抽象类和接口来实现商务逻辑的集中控制，一般通过继承抽象类来得到抽象类具体方法的使用权限，通常这些方法的定义需求是统一的商务逻辑定义。迭代子模式也做到了这点，它将公用的迭代功能定义为一个接口，实现了这个接口的集合类表示支持迭代，使用迭代子接口声明的类型，在实现过程中，当集合类发生改变时，它也能正常工作，这就是所谓的抽象耦合关系，只对迭代接口的引用。

         坚持DIP原则会生产出大量的类，它们大多都是抽象类和接口，怎么处理好这种引用关系是值得思考的。另外，依赖倒换原则假定所有的具体类都是会变化的，但是实际情况中不总是这样，这需要我们实际情况实际解决。