设计模式学习笔记 - 设计原则 - 3.里氏替换原则，它和多态的区别是什么？

前言

今天来学习 SOLID 中的 L：里氏替换原则。它的英文翻译是 Liskov Substitution Principle，缩写为 LSP。

英文原话是： Functions that use points of references of base classes must be able to use objects of derived classes without knowing it。

用中文描述，是这样的：子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。

如何理解"里氏替换原则"

开头对里氏替换原则的解释比较抽象，通过一个例子来解释下。父类 Transporter 使用 org.apach.http 来传输网络数据。子类 SecurityTransporter 继承父类 Transporter，增加了额外的功能，支持传输 appId 和 appToken 安全认证信息。

java 复制代码

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) {
        Request request = new Request();
        // 省略设置 request中数据的代码...
        Response response = transporter.sendRequest(request);
        // 省略其他逻辑
    }
}

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

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

你可能会有疑问，刚刚的代码就是利用了多态，多态和里氏替换原则是不是一回事呢？

其实它们完全是两回事。

我们还是通过刚刚的例子来说明下。对 SecurityTransporter 类中 sendRequest() 函数稍微改造下。对 appId 、appToken 进行校验，若没有设置，则抛出异常。改造后的代码如下所示：

java 复制代码

// 改造前
public class SecurityTransporter extends Transporter {
	// 其他代码忽略...
    @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 SecurityTransporter extends Transporter {
	// 其他代码忽略...
    @Override
    public Response sendRequest(Request request) {
        if (StringUtils.isBlank(appId) || StringUtils.isBlank(appToken)) {
            throw new NoAuthorizationRuntimeException(...);
        }
        request.addPayload("app-id", appId);
        request.addPayload("app-token", appToken);
        return super.sendRequest(request);
    }
}

改造之后，如果传递进 demoFunction() 函数的是父类 Transporter 对象，那不会有溢出抛出，但是如果传递的是 SecurityTransporter 对象有可能会抛出异常，子类替换父类传递进 demoFunction() 函数之后，整个程序的逻辑行为有了改变。

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

总结一下，虽然从定义描述和代码实现上来看，多态和里氏替换原则有点类似，但它们关注的角度不同。

多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法。是一种代码实现的思路。
里氏替换原则是一种设计原则，用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。

哪些代码明显违背了 LSP？

子类在设计的时候，要遵守父类的行为约定（或者叫协议）。行为约定包括：

函数声明要实现的功能
对输入、输出、异常的约定
甚至包括注释中所罗列的任何特殊说明。

为了更好的说明，我们举几个反例来解释下。

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

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

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

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

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

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

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

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

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