设计模式六大原则<二>依赖倒置原则

设计模式概述见：
http://blog.csdn.net/chijiandi/article/details/78839305

依赖倒置原则的基本概念

高层模块不应该依赖底层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
换句话说：依赖倒置要求我们面向接口编程。
遵守依赖倒置原则，要求我们遵守这样两点：
1. 低层模块应有其抽象类或接口
2. 遵循里氏替换原则

为什么要遵守依赖倒置原则

面向接口编程有这样几点好处：

1. 降低程序的耦合性。其能够最大限度的解耦，所谓解耦既是解耦合的意思，它和耦合相对。耦合就是联系，耦合越强，联系越紧密。在程序中紧密的联系并不是一件好的事情，因为两种事物之间联系越紧密，你更换其中之一的难度就越大，扩展功能和debug的难度也就越大。
2. 易于程序的扩展；
3. 有利于程序的维护；

其实说白了所以设计模式思想不过都是降低耦合提高程序的维护性。

举这样一个依赖导致原则的反例：

我们需要一个加法的功能，所以我们写了一个算法的类，含有一个加法的方法:

class Calc {
    int add(int a, int b) {
        return a + b;
    }
}

客户端进行调用：

public class Main {
    public static void main(String[] args) {
        new Calc().add(1, 2);
    }
}

但是有一天当增加需要，要我们实现一个减法，
什么？算法类不会减法，那是不是要修改算法类，对其增加一个减法的
当算法越来越多，是不是就产生了很强的耦合性，不易维护？
也就是说，实现新的功能是需要在修改原有代码的基础上的？？？

依赖倒置原则怎么遵守

依赖于接口的编程在于接口存在的地方可以替换为子类，这其中又牵扯到了里氏替换原则。
里氏替换原则又是开放-封闭原则的一种实现，
此时，若一开始就遵守了依赖倒置原则的编码，我们会是这样的：
让低层模块依赖于抽象：

interface Calc {
    int getResult(int a, int b);
}

低层模块实现接口：

class Add implements Calc {
    @Override
    public int getResult(int a, int b) {
        return a+b;
    }
}

客户端便可以这样调用

public class Main {
    public static void main(String[] args) {
       Calc calc = new Add();
       calc.getResult(1,2);
    }
}

若是需要一个减法的功能，新增减法类即可，不会对原先的加法类进行任何的修改。
再向前一步，策略模式、简单工厂模式等等都只是对这些思想的一点应用。

后记

每次更多地学习一点设计模式就会发现，每一种设计模式往往都关联着多个其他设计模式的思想或方法，这可能就是学习了设计模式会改变我们的代码风格的原因吧。

若有理解错误，感谢指出