「设计模式」六大原则之三：里氏替换原则小结

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

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

设计模式的六大原则有：

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

本文介绍 SOLID 中的第三个原则：里氏替换原则。

1.里式替换原则定义

里式替换原则的英文定义：Liskov Substitution Principle，缩写为 LSP。这个原则最早是在 1986 年由 Barbara Liskov 提出，他是这么描述这条原则的：

If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program。

在 1996 年，Robert Martin 在他的 SOLID 原则中，重新描述了这个原则，英文原话是这样的：

Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it。

我们综合两者的描述，将这条原则用中文描述出来，是这样的：子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。

简单点说，子类可以扩展父类的功能，但不能改变父类原有的功能。当子类继承父类时，除新添加的方法且完成新增的功能外，尽量不要重写父类的方法。有四个含义：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

• 子类可以增加自己的特有方法。

• 当子类的方法重载父类的方法时，方法的前置条件（输入的参数）要比父类的方法更宽松。

• 当子类的方法实现父类的方法（重写、重载或实现抽象方法）时，方法的后置条件（即方法的输出或返回值）要比父类的方法更严格或与父类的方法相等。

凡是用到父类的地方，替换成子类不会改变原有逻辑。（反过来不行，有子类出现的地方，父类未必能适应，因为子类有功能增强）

我们知道面向对象编程的三个基本原则: 封装，继承和多态。里氏置换原则就是继承的体现，主要用来解决继承带来的问题。

里氏替换原则的核心是抽象，抽象又依赖于继承。

2. 举例说明

示例1：

父类 Transporter 使用 org.apache.http 库中的 HttpClient 类来传输网络数据。

子类 SecurityTransporter 继承父类 Transporter，增加了额外的功能，支持传输 appId 和 appToken 安全认证信息。

public class Transporter {
    
    
  private HttpClient httpClient;
  
  public Transporter(HttpClient httpClient) {
    
    
    this.httpClient = httpClient;
  }

  public Response sendRequest(Request request) {
    
    
    // ...use httpClient to send request
  }
}

public class SecurityTransporter extends Transporter {
    
    
  private String appId;
  private String appToken;

  public SecurityTransporter(HttpClient httpClient, String appId, String appToken) {
    
    
    super(httpClient);
    this.appId = appId;
    this.appToken = appToken;
  }

  @Override
  public Response sendRequest(Request request) {
    
    
    if (StringUtils.isNotBlank(appId) && StringUtils.isNotBlank(appToken)) {
    
    
      request.addPayload("app-id", appId);
      request.addPayload("app-token", appToken);
    }
    return super.sendRequest(request);
  }
}

public class Demo {
    
        
  public void demoFunction(Transporter transporter) {
    
        
    Reuqest request = new Request();
    //...省略设置request中数据值的代码...
    Response response = transporter.sendRequest(request);
    //...省略其他逻辑...
  }
}

// 里式替换原则
Demo demo = new Demo();
demo.demofunction(new SecurityTransporter(/*省略参数*/););

子类 SecurityTransporter 的设计完全符合里式替换原则，可以替换父类出现的任何位置，并且原来代码的逻辑行为不变且正确性也没有被破坏。

思考点：如果在子类中使用了多态的思想，重写了这个方法会出现什么问题

public class SecurityTransporter extends Transporter {
    
    
  //...省略其他代码..
  @Override
  public Response sendRequest(Request request) {
    
    
    // 如果父类没有处理，而子类在里处理了，虽然抛出的是运行时异常（Runtime Exception），我们可以不在代码中显式地捕获处理，但是这里违背了该设计原则
    if (StringUtils.isBlank(appId) || StringUtils.isBlank(appToken)) {
    
    
      throw new NoAuthorizationRuntimeException(...);
    }
    request.addPayload("app-id", appId);
    request.addPayload("app-token", appToken);
    return super.sendRequest(request);
  }
}

虽然改造之后的代码仍然可以通过 Java 的多态语法，动态地用子类 SecurityTransporter 来替换父类 Transporter，也并不会导致程序编译或者运行报错。但是，从设计思路上来讲，SecurityTransporter 的设计是不符合里式替换原则的。

示例2：

比如 Android中 window 和 view 的关系实现，也符合了该原则。

// 窗口类
public class Window {
    
    
  public void show(View child) {
    
    
    child.draw();
  }
}
// 父类实现
//建立视图抽象
public abstract class View {
    
    
  public abstract void draw();
  public void measure(int width, int height){
    
    
    // 测量视图大小
  }
}

// 子类实现 
// 按钮类的具体实现
public class Button extends View{
    
    
  public void draw(){
    
    
       // 绘制按钮
  }
}
// 文本类的具体实现
public class TextView extends View{
    
    
  public void draw(){
    
    
    // 绘制文本
  }
}

通过里氏替换，可以自定义实现各式各样的 View ,然后传递给 window, window 负责组织 view, 并且将 View 绘制到屏幕上。

3. 哪些代码明显违背了 LSP？

子类违背父类声明要实现的功能

父类中提供的 sortOrdersByAmount() 订单排序函数，是按照金额从小到大来给订单排序的，而子类重写这个 sortOrdersByAmount() 订单排序函数之后，是按照创建日期来给订单排序的。那子类的设计就违背里式替换原则。

子类违背父类对输入、输出、异常的约定

在父类中，某个函数约定：运行出错的时候返回 null；获取数据为空的时候返回空集合（empty collection）。而子类重载函数之后，实现变了，运行出错返回异常（exception），获取不到数据返回 null。那子类的设计就违背里式替换原则。

在父类中，某个函数约定，输入数据可以是任意整数，但子类实现的时候，只允许输入数据是正整数，负数就抛出，也就是说，子类对输入的数据的校验比父类更加严格，那子类的设计就违背了里式替换原则。

在父类中，某个函数约定，只会抛出 ArgumentNullException 异常，那子类的设计实现中只允许抛出 ArgumentNullException 异常，任何其他异常的抛出，都会导致子类违背里式替换原则。

子类违背父类注释中所罗列的任何特殊说明

父类中定义的 withdraw() 提现函数的注释是这么写的：“用户的提现金额不得超过账户余额……”，而子类重写 withdraw() 函数之后，针对 VIP 账号实现了透支提现的功能，也就是提现金额可以大于账户余额，那这个子类的设计也是不符合里式替换原则的。

开发 Tips

以上便是三种典型的违背里式替换原则的情况。除此之外，判断子类的设计实现是否违背里式替换原则，还有一个小窍门，那就是拿父类的单元测试去验证子类的代码。如果某些单元测试运行失败，就有可能说明，子类的设计实现没有完全地遵守父类的约定，子类有可能违背了里式替换原则。

4. 小结：

理解这个原则，我们还要弄明白里式替换原则跟多态的区别。虽然从定义描述和代码实现上来看，多态和里式替换有点类似，但它们关注的角度是不一样的。多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计原则，用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑及不破坏原有程序的正确性。

参考：

《设计模式之美》

《重学 Java 设计模式》

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