设计模式原则篇(3):依赖倒转原则---Dependence Inversion Principle

                依赖倒转原则，听名字感觉就十分的奇怪。“依赖”是什么？为什么要到转呢？理解这些

        首先要从"依赖倒转原则"的定义入手。

                依赖倒转原则：

                         高层模块不应该依赖于底层模块，而是应该依赖于抽象；抽象不应该依赖于具体的

                 细节；细节应该依赖于抽象。

                         高层模块和底层模块容易明白。每一个功能模块的实现都是由原则逻辑组成的，不可

                 分割的原则逻辑就是底层模块，其再组装就是高层模块。那么，抽象和细节有事怎么一回

                 事呢？这里的抽象就是java中的抽象类、接口，至于细节则就是具体实现类了。因此上述

                 的三层含义可以概括如下：

                          1、模块之间的依赖是通过抽象发生的，实现类并不体现其关系，其依赖关系是通过抽

                                 像类、接口体现的。

                          2、对于接口、抽象类的编码不应该依赖于实现类。

                          3、实现类具体的行为是依赖于接口、抽象类的。

                  通俗的讲就是针对接口编程，而不是针对实现编程。

                  现在反过来去理解“依赖倒转原则”：传统的过程性系统的设计方法倾向于是高层次的依赖于

           低层次的模块；抽象层次依赖于具体层次。倒转原则就是把这个依赖关系倒转过来就是“依赖”

           倒转的由来。

                     具体情况如下：错误的依赖关系

                 

                   倒转过来之后的关系：

               

                   不过怎样做到依赖倒转原则呢？

                 以抽象的方式耦合是实现依赖倒转原则的关键，这里的耦合关系一共有三种：

                            ●  零耦合：如果两个类之间没有耦合关系，则成为零耦合关系

                            ●  具体耦合：耦合关系发生在两个具体的类之间，经由一个类对

                                                    另一个类的直接引用造成的。

                            ●  抽象耦合：耦合发生在一个具体类和一个抽象类之间，较之前者更灵活

                 因为要实现抽象耦合，就必然涉及到继承，因此里氏替换原则就是其前提。

                 关于里氏替换原则上一篇文章有介绍。