本文共 1269 字，大约阅读时间需要 4 分钟。

设计模式概述见：

依赖倒置原则的基本概念

高层模块不应该依赖底层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

换句话说：依赖倒置要求我们面向接口编程。 遵守依赖倒置原则，要求我们遵守这样两点： 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);    }}

若是需要一个减法的功能，新增减法类即可，不会对原先的加法类进行任何的修改。

再向前一步，策略模式、简单工厂模式等等都只是对这些思想的一点应用。

后记

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

若有理解错误，感谢指出

转载地址：http://kgiob.baihongyu.com/