「设计模式」六大原则之五：依赖倒置原则小结

「设计模式」六大原则系列链接:
「设计模式」六大原则之一：单一职责小结
「设计模式」六大原则之二：开闭职责小结
「设计模式」六大原则之三：里氏替换原则小结
「设计模式」六大原则之四：接口隔离原则小结
「设计模式」六大原则之五：依赖倒置原则小结
「设计模式」六大原则之六：最小知识原则小结

六大原则体现很多编程的底层逻辑：高内聚、低耦合、面向对象编程、面向接口编程、面向抽象编程，最终实现可读、可复用、可维护性。

设计模式的六大原则有：

• Single Responsibility Principle：单一职责原则
• Open Closed Principle：开闭原则
• Liskov Substitution Principle：里氏替换原则
• Law of Demeter：迪米特法则（最少知道原则）
• Interface Segregation Principle：接口隔离原则
• Dependence Inversion Principle：依赖倒置原则
  把这六个原则的首字母联合起来（ L 算做一个）就是 SOLID （solid，稳定的），其代表的含义就是这六个原则结合使用的好处：建立稳定、灵活、健壮的设计。

本文介绍 SOLID 中的第五个原则：依赖倒置原则。

1.依赖倒置原则（DIP）定义

依赖倒置原则的英文翻译是 Dependency Inversion Principle，缩写为 DIP。

中文翻译有时候也叫依赖反转原则。

为了追本溯源，我先给出这条原则最原汁原味的英文描述：

High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstractions.

我们将它翻译成中文，大概意思就是：

• 高层模块（high-level modules）不要依赖低层模块（low-level）。
• 高层模块和低层模块应该通过抽象（abstractions）来互相依赖。
• 除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。

所谓高层模块和低层模块的划分，简单来说就是，在调用链上，调用者属于高层，被调用者属于低层。

在 Java 语言中，抽象指的是接口或抽象类，两都都是不能直接实例被化的，细节就是实现类，实现接口或继承抽象类而产生的类就是细节。其特点就是可以被直接实例化，也就是可以加上 new 关键字。

高层模块就是调用端，低层模块就是具体实现类。

依赖倒置原则在 Java中的体现就是：

模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系通过接口或抽象产生的。

简单点理解，我们要面向接口编程，或者是面向抽象编程。

4.DIP举例说明

在项目中如何灵活的更换第三方图片加载库，或者同时共存，用户根据手机选择性使用三方库。

第一个版本，只使用一种 Picasso 加载库

private void loadImage(String url, ImageView imageView) {
    Picasso.get().load(url).resize(50, 50).centerCrop().into(imageView)
}

第二个版本图片加载库，需要变化， Picasso 换成 Glide， 只需要修改这一个工具类即可

public class PicassoUtils {
    //从网络加载
    public static void loadByUrl(String url, IamgeView imageView){
        Picasso.get().load(url).resize(50, 50).centerCrop().into(imageView)
    }

    //从文件加载
    public static void loadByPath(String path,ImageView imageView) {

    }
}

第三个版本，需求变化，要求两种加载库都需要，根据不同手机适配。（类似的：根据不同的手机选择不同的推送服务，方便提高消息的到达率）

此时就需要应用好面向接口编程思想了。

interface ImageLoader {
    //从网络加载
    void loadByUrl(String url, ImageView imageView);
    //从文件加载
    void loadByPath(String path, ImageView imageView);
}

//使用 Picasso
public class PicassoLoader implements ImageLoader {
    ...
}

//使用 Glide
public class GlideLoader implements ImageLoader {
    ...
}

//业务层使用，imageLoader是什么就看需求，随便创建
//也可以定义一个全局管理类，里面视需求自定义全局 PicassoLoader 或 GlideLoader
// 调用方法
ImageLoader imageLoader = new PicassoLoader() 
  //ImageLoader imageLoader = new GlideLoader()
imageLoader.loadByUrl(url, imageView);

可以看到面向接口的好处: 能够减少耦合，代码容易维护，容易拓展，因为接口是抽象的，所以不用纠结于具体的逻辑，想怎么实现都可以；又因为接口是顶层的，所以下层就多，就更容易扩展，就更灵活。

2. 如何理解控制反转（IOC）

控制反转的英文翻译是 Inversion Of Control，缩写为 IOC。

控制反转是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。这里所说的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。

3. 如何理解依赖注入（DI）

依赖注入跟控制反转恰恰相反，它是一种具体的编码技巧。

依赖注入的英文翻译是 Dependency Injection，缩写为 DI。

那到底什么是依赖注入呢？

我们用一句话来概括就是：不通过 new() 的方式在类内部创建依赖类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类使用。

在这个例子中，Notification 类负责消息推送，依赖 MessageSender 类实现推送商品促销、验证码等消息给用户。我们分别用依赖注入和非依赖注入两种方式来实现一下。具体的实现代码如下所示：

// 非依赖注入实现方式
public class Notification {
  private MessageSender messageSender;
  
  public Notification() {
    this.messageSender = new MessageSender(); //此处有点像hardcode
  }
  
  public void sendMessage(String cellphone, String message) {
    //...省略校验逻辑等...
    this.messageSender.send(cellphone, message);
  }
}

public class MessageSender {
  public void send(String cellphone, String message) {
    //....
  }
}
// 使用Notification
Notification notification = new Notification();

// 依赖注入的实现方式
public class Notification {
  private MessageSender messageSender;
  
  // 通过构造函数将messageSender传递进来
  public Notification(MessageSender messageSender) {
    this.messageSender = messageSender;
  }
  
  public void sendMessage(String cellphone, String message) {
    //...省略校验逻辑等...
    this.messageSender.send(cellphone, message);
  }
}
//使用Notification
MessageSender messageSender = new MessageSender();
Notification notification = new Notification(messageSender);

通过依赖注入的方式来将依赖的类对象传递进来，这样就提高了代码的扩展性，我们可以灵活地替换依赖的类。这一点在我们之前讲“开闭原则”的时候也提到过。

当然，上面代码还有继续优化的空间，我们还可以把 MessageSender 定义成接口，基于接口而非实现编程。改造后的代码如下所示：

public class Notification {
  private MessageSender messageSender;
  
  public Notification(MessageSender messageSender) {
    this.messageSender = messageSender;
  }
  
  public void sendMessage(String cellphone, String message) {
    this.messageSender.send(cellphone, message);
  }
}

public interface MessageSender {
  void send(String cellphone, String message);
}

// 短信发送类
public class SmsSender implements MessageSender {
  @Override
  public void send(String cellphone, String message) {
    //....
  }
}

// 站内信发送类
public class InboxSender implements MessageSender {
  @Override
  public void send(String cellphone, String message) {
    //....
  }
}

//使用Notification
MessageSender messageSender = new SmsSender();
Notification notification = new Notification(messageSender);

上面例子是依赖注入的典型用法。

4. 小结

“基于接口而非实现编程”与“依赖注入”的联系是二者都是从外部传入依赖对象而不是在内部去new一个出来。

区别是“基于接口而非实现编程”强调的是“接口”，强调依赖的对象是接口，而不是具体的实现类；

而“依赖注入”不强调这个，类或接口都可以，只要是从外部传入不是在内部new出来都可以称为依赖注入。

参考：

《设计模式之美》

《重学 Java 设计模式》

《Android 源码设计模式解析与实战》

设计模式之基-六大设计原则