里氏替换原则(Liskov Substitution Principle LSP)

发布于 作者:

里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

为什么叫里氏替换原则？

里氏替换原则在SOLID这五个设计原则中是比较特殊的存在：

  • 如果违反了里氏替换原则，不只是降低软件设计的优雅性，很可能会导致Bug
  • 只有里氏替换原则是以人名命令的

里氏替换原则译自Liskov substitution principle。Liskov是一位计算机科学家，也就是Barbara Liskov，麻省理工学院教授，也是美国第一个计算机科学女博士，师从图灵奖得主John McCarthy教授，人工智能概念的提出者。

里氏替换原则最初由Barbara Liskov在1987年的一次学术会议中提出，而真正正式发表是在1994年，Barbara Liskov 和 Jeannette Wing发表的一篇学术论文《A behavioral notion of subtyping》.

什么是里氏替换原则？

里氏替换原则在1994年Barbara Liskov 和 Jeannette Wing发表论文中的描述是：

If S is a declared subtype of T, objects of type S should behave as objects of type T are expected to behave, if they are treated as objects of type T

从字面上翻译：如果S是T的子类型，对于S类型的任意对象，如果将他们看作是T类型的对象，则对象的行为也理应与期望的行为一致。

而另一种关于里氏替换原则的描述为Robert Martin在《敏捷软件开发：原则、模式与实践》一书中对原论文的解读：子类型（subtype）必须能够替换掉他们的基类型（base type）。这个是更简明的一种表述。

如何理解里氏替换原则？

不管是Barbara Liskov论文中的表述，还是Robert Martin的解读，都是比较抽象的表达。要理解里氏替换原则，其实就是要理解两个问题：

  • 什么是替换？
  • 什么是与期望行为一致的替换（Robert Martin所说的“必须能够替换”）？

什么是替换

替换的前提是面向对象语言所支持的多态特性，同一个行为具有多个不同表现形式或形态的能力。以JDK的集合框架为例，List接口的定义为有序集合，List接口有多个派生类，比如大家耳熟能详的ArrayList, LinkedList。那当某个方法参数或变量是List接口类型时，既可以是ArrayList的实现, 也可以是LinkedList的实现，这就是替换。

举个简单的例子：

public String getFirst(List<String> values) {
        return values.get(0);
}

对于getFirst方法，接受一个List接口类型的参数，那既可以传递一个ArrayList类型的参数：

List<String> values = new ArrayList<>();
values.add("a");
values.add("b");
String firstValue = getFirst(values);

又可以接收一个LinkedList参数：

List<String> values = new LinkedList<>();
values.add("a");
values.add("b");
String firstValue = getFirst(values);

什么是与期望行为一致的替换？

在不了解派生类的情况下，仅通过接口或基类的方法，即可清楚的知道方法的行为，而不管哪种派生类的实现，都与接口或基类方法的期望行为一致。或者说接口或基类的方法是一种契约，使用方按照这个契约来使用，派生类也按照这个契约来实现。这就是与期望行为一致的替换。继续以上节中的例子说明：

public String getFirst(List<String> values) {
        return values.get(0);
}

对于getFirst方法，接收List类型的参数，而List类型的get方法返回特定位置的元素，对于本例即为第一个元素。这些是不依赖派生类的知识的。所以对于上节中的示例，不管是ArrayList类型的实现，还是LinkedList的实现，getFirst方法最终的返回值是一样的。这就是与期望行为一致的替换。

违反里氏替换原则的场景

从直观上可能觉得派生类对象可以在替换其基类对象是理所当然的，但会有出现一些场景有意无意地违反了里氏替换原则。

子类中抛出了基类未定义的异常

还以JDK的集合框架为例，如果自定义一个List的派生类，如下：

class CustomList<T> extends ArrayList<T> {
    @Override
    public T get(int index) {
        throw new UnsupportedOperationException();
    }
}

仅重写get方法，throw一个UnsupportedOperationException，因为List接口关于get方法的描述，仅会抛出IndexOutOfBoundsException, throw UnsupportedOperationException的行为并不是基类所期望的，即违反了里氏替换原则，

/**
     * Returns the element at the specified position in this list.
     *
     * @param index index of the element to return
     * @return the element at the specified position in this list
     * @throws IndexOutOfBoundsException if the index is out of range
     *         ({@code index < 0 || index >= size()})
     */
    E get(int index);

子类改变了基类方法的语义或引入了副作用

同样，如果自定义另一个List的派生类，如下：

class CustomList<T> extends ArrayList<T> {
    @Override
    public T get(int index) {
        if (index >= size()){
            return null;
        }
        return get(index);
    }
}

仅重写get方法，当输入index大于当前list的size时，返回null，而不抛出IndexOutOfBoundsException, 因为List接口关于get方法的描述，当index超出范围时抛出IndexOutOfBoundsException，所以改变了基类方法的语义，即违反了里氏替换原则。

违反里氏替换原则的危害

当我们违反了这一原则会带来有一些危害：

  • 反直觉。期望所有子类行为是一致的，但如果不一致可能需要文档记录，或者在代码跑失败后涨此知识；
  • 不可读。如果子类行为不一致，可能需要不同的逻辑分支来适配不同的行为，徒增代码复杂度；
  • 不可用。可能出错的地方终将会出错。

如何避免违反里氏替换原则

谈到如何避免，当然要基于里氏替换原则的定义，与期望行为一致的替换。

  • 从行为出发来设计。在做抽象或设计时，不只是要从模型概念出发，还要从行为出发，比如一个经典的例子，正方形和长方形，从现实的概念中正方形是一个长方形，但是在计算其面积的行为上是不一致的。
  • 基于契约设计。这个契约即是基类方法签名、功能描述、参数类型、返回值等。在派生类的实现时，时刻保持派生类与基类的契约不被破坏。