嘻哈说：设计模式之里氏替换原则

按照惯例，首先我们来看一下里氏替换原则的定义。

所有引用基类（父类）的地方必须能透明地使用其子类的对象。通俗的说， 子类可以扩展父类 功能，但 不能改变父类原有 功能。

核心思想是 继承 。 通过继承，引用基类的地方就可以使用其子类的对象了。例如：

Parent parent = new Child();
复制代码

重点来了，那么如何透明地使用呢？

我们来思考个问题，子类可以改变父类的原有功能吗？

public class Parent {
    public int add(int a, int b){
        return a+b;
    }
}

public class Child extends Parent{
    @Override
    public int add(int a, int b) {
        return a-b;
    }
}
复制代码

这样好不好？

肯定是不好的，本来是加法却修改成了减法，这显然是不符合认知的。

它违背了里氏替换原则，子类改变了父类原有功能后，当我们在引用父类的地方使用其子类的时候，没办法透明使用add方法了。

父类中凡是已经实现好的方法，实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些规范，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。

所以，透明使用的关键就是，子类不能改变父类原有功能。

2、含义

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

刚才我们已经说过，子类不能改变父类的原有功能，所以子类不能覆盖父类的非抽象方法。

子类可以实现父类的抽象方法，must be，抽象方法本来就是让子类实现的。

package com.fanqiekt.principle.liskov.rapper;

/**
 * Rapper抽象类
 *
 * @Author: 番茄课堂-懒人
 */
public abstract class BaseRapper {

    /**
     * freeStyle
     */
    protected abstract void freeStyle();

    /**
     * 播放伴奏
     */
    protected void playBeat(){
        System.out.println("从乐库中随机播放一首伴奏：动次打次...");
    }

    /**
     * 表演
     * 播放伴奏，并进行freeStyle
     */
    public void perform(){
        playBeat();
        freeStyle();
    }
}
复制代码

BaseRapper是一个抽象类，它代表着Rapper的基类。

Rapper一般的表演方式是随机播放一首伴奏然后进行free style。

freeStyle则各有各的不同，所以将它写成了一个抽象方法，让子类自由发挥。

playBeat流程大多是一样的，从乐库中随意播放伴奏，所以将它写成了一个非抽象方法。

perform的流程大多也是一样的，放伴奏，然后freestyle，也将它写成了非抽象方法。

package com.fanqiekt.principle.liskov.rapper;

/**
 * Rapper
 *
 * @author 番茄课堂-懒人
 */
public class Rapper extends BaseRapper {

    /**
     * 播放伴奏
     *
     * 子类覆盖父类非抽象方法
     */
    @Override
    protected void playBeat() {
        System.out.println("关闭麦克风");
    }

    /**
     * 表演
     *
     * 子类覆盖父类非抽象方法
     */
    @Override
    public void perform() {
        System.out.println("跳鬼步");

    }

    /**
     * 子类可以覆盖父类抽象方法
     */
    @Override
    protected void freeStyle() {
        System.out.println("药药切克闹，煎饼果子来一套！");
    }
}
复制代码

Rapper是BaseRapper的子类，覆盖了父类的抽象方法freeStyle。

覆盖了父类的非抽象方法playBeat，并将逻辑更改为打开麦克风，明显违背了里氏替换原则。 这显然是非常错误的写法， 原因是父类行为与子类行为不一致，不可以透明的使用父类了。 播放伴奏你却给我打开麦克风，你确定不是在逗我？

我尝试着将playBeat进行下修改。

/**
 * 子类覆盖父类非抽象方法
 * 子类方法中调用super方法
 */
@Override
protected void playBeat() {
    super.playBeat();
    System.out.println("关闭麦克风");
}
复制代码

在子类方法中调用super方法，这样修改是否可以？

不可以，原因是打开麦克风跟播放伴奏没有任何逻辑上的关系。

透明使用子类的时候，虽然伴奏也会正常的播放，但却在调用者不知情的情况下关闭了麦克风，而关闭麦克风又明显与播放伴奏无关。 这就对于调用者无法做到真正的透明了。

同样覆盖了父类的非抽象方法perform，并将逻辑更改为跳舞，这要是违背了里氏替换原则的。 只跳舞不说唱的表演还叫Rapper吗？

我尝试着将perform进行下修改。

/**
 * 表演
 * freestyle + 跳舞
 * 子类覆盖父类非抽象方法
 */
@Override
public void perform() {
    super.perform();
    System.out.println("跳鬼步");
}
复制代码

perform方法我这样修改可以吗？

这个倒是可以的，为什么同样是子类调用super方法，为什么playBeat不可以，perform就可以呢？

perform是表演，跳舞是表演的一种补充，属于表演范畴，调用者可以透明地调用perform方法。

安静的freestyle还是手舞足蹈的freestyle，对于调用者来讲，都属于freestyle表演。

2、子类中可以增加自己特有的方法。

继承一个很重要的特点：子类继承父类后可以新增方法。

/**
 * 跳舞
 * 子类中增加特有的方法
 */
public void dance(){
    System.out.println("跳鬼步！");
}
复制代码

在Rapper中可以增加dance方法。

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

注意，是子类 重载 父类，而不是子类重写父类。

重载的话，相当于一个全新的方法，与父类的同名方法并不冲突。两个是同时存在的，根据传入参数而自动选择方法。

可以重载抽象方法，也可以重载非抽象方法。

方法的形参为什么要比父类更宽松呢？

首先，形参肯定不能一致，一致的话，就是重写了，就又回到第一条含义了。

第二，如果我们更加严格，那会出现什么情况呢？

我们可以来看下面的例子。

package com.fanqiekt.principle.liskov.rapper;

import java.util.List;

/**
 * 父类
 *
 * @author 番茄课堂-懒人
 */
public abstract class Parent {

    public void setList(List<String> list){
        System.out.println("执行父类setList方法");
    }
}
复制代码

这个是父类，setList方法有个List类型的形参。>

package com.fanqiekt.principle.liskov.rapper;

import java.util.ArrayList;

/**
 * 子类
 *
 * @author 番茄课堂-懒人
 */
public class Children extends Parent {

    public void setList(ArrayList<String> list) {
        System.out.println("执行子类setList方法");
    }
}
复制代码

这个是子类，传入参数类型为ArrayList，比父类更加的严格。

Parent parent = new Children();
parent.setList(new ArrayList<>());
复制代码

我们运行这行代码，看下结果。

执行子类setList方法
复制代码

这个结果有没有问题？

是有问题的，setList(new ArrayList<>())按照里氏替换原则是应该执行父类的setList(List list)方法的。

这块不是很好理解，对于调用者来讲，我是调用的Parent的setList(List list)方法，结果却执行Children的setList(ArrayList list)方法了。

这就好像是子类重写了父类的setList方法，而不是重载了子类的setList方法。

也就是说，方法的形参严格后，在某种情况就变成重写了。

那我们再来看看宽松版本的。

/**
 * 子类
 *
 * @author 番茄课堂-懒人
 */
public class Children extends Parent {

    public void setList(Collection<String> list) {
        System.out.println("执行子类setList方法");
    }
}
复制代码

子类，传入参数类型为Collection，比父类更加的宽松。

Parent parent = new Children();
parent.setList(new ArrayList<>());
复制代码

同样的，我们运行这行代码，看下结果。

执行父类setList方法
复制代码

Children children = new Children();
children.setList(new HashSet<>());
复制代码

同样的，我们运行这行代码，看下结果。

执行子类setList方法
复制代码

传入参数类型更加宽松，实现了子类重载父类。

4、当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

注意，这里说的是 重写抽象方法 ，非抽象方法是不能重写的。

为什么说子类实现父类的抽象方法时，返回值要更严格呢？

package com.fanqiekt.principle.liskov.rapper;

import java.util.List;

/**
 * 父类
 *
 * @author 番茄课堂-懒人
 */
public abstract class Parent {

    public abstract List<String> getList();
}
复制代码

父类，有一个getList的抽象方法，返回值为List。

package com.fanqiekt.principle.liskov.rapper;

import java.util.List;

/**
 * 子类
 *
 * @author 番茄课堂-懒人
 */
public class Children extends Parent {

    @Override
    public Collection<String> getList() {
        return new ArrayList<>();
    }
}
复制代码

子类，getList返回为Collection类型，类型更宽松。

会有红线提示：... attempting to use incompatible return type 。

因为，父类返回值是List，子类返回值是List的父类Collection，透明使用父类的时候则需要将Collection转换成List。 类向上转换是安全的，向下转换则不一定是安全了。

package com.fanqiekt.principle.liskov.rapper;

import java.util.List;

/**
 * 子类
 *
 * @author 番茄课堂-懒人
 */
public class Children extends Parent {

    @Override
    public ArrayList<String> getList() {
        return new ArrayList<>();
    }
}
复制代码

子类，getList返回为ArrayList类型，类型更严格。

将ArrayList转换成List，向上转换是安全的。

2、场景

八大菜系的厨师

番茄餐厅，经过兢兢业业的经营，从一家小型的餐馆成长为一家大型餐厅。

厨师：老板，咱们现在家大业大客流量也大，虽然我精力充沛，但我也架不住这么多人的摧残。

老板：摧残？你确定？

厨师：哪能，您听错了，是照顾，架不住这么多人的照顾。

老板：小火鸡，可以呀，求生欲很强嘛。那你有什么想法？

厨师：我觉得咱们可以引入八大菜系厨师，一来，什么菜系的菜就交给什么菜系的厨师，味道质量会更加的上乘，才能配的上我们这么高规格的餐厅。

老板：嗯，说的有点道理，继续说。

厨师：二来，人手多了，还可以增加上菜的速度，三来......

老板：有道理，马上招聘厨师，小火鸡，恭喜你，升官了，你就是未来的厨师长。因为你求生欲真的很强。

厨师长：谢谢老板。（内心：我求生欲很强？哪里强了？放学你别走，我让你尝尝我的厉害，给你做一桌子好菜）

求生欲果真很强。

3、实现

不废话，撸代码。

package com.fanqiekt.principle.liskov;

/**
 * 抽象厨师类
 *
 * @author 番茄课堂-懒人
 */
public abstract class Chef {
    /**
     * 做饭
     * @param dishName 餐名
     */
    public void cook(String dishName){
        System.out.println("开始烹饪："+dishName);

        cooking(dishName);

        System.out.println(dishName + "出锅");
    }

    /**
     * 开始做饭
     */
    protected abstract void cooking(String dishName);
}
复制代码

抽象厨师类，公有cook方法，负责厨师做饭的一些相同逻辑，例如开始烹饪的准备工作，以及出锅。

具体做饭的细节则提供一个抽象方法cooking（正在做饭），具体菜系厨师需要重写该方法。

package com.fanqiekt.principle.liskov;

/**
 * 山东厨师
 *
 * @author 番茄课堂-懒人
 */
public class ShanDongChef extends Chef{
    @Override
    protected void cooking(String dishName) {
        switch (dishName){
            case "西红柿炒鸡蛋":
                cookingTomato();
                break;
            default:
                throw new IllegalArgumentException("未知餐品");
        }
    }

    /**
     * 炒西红柿鸡蛋
     */
    private void cookingTomato() {
        System.out.println("先炒鸡蛋");
        System.out.println("再炒西红柿");
        System.out.println("...");
    }
}
复制代码

鲁菜厨师ShanDongChef继承了厨师抽象类Chef，实现了抽象方法cooking。

package com.fanqiekt.principle.liskov;

/**
 * 四川厨师
 *
 * @author 番茄课堂-懒人
 */
public class SiChuanChef extends Chef{
    @Override
    protected void cooking(String dishName) {
        switch (dishName){
            case "酸辣土豆丝":
                cookingPotato();
                break;
            default:
                throw new IllegalArgumentException("未知餐品");
        }
    }

    /**
     * 炒酸辣土豆丝
     */
    private void cookingPotato() {
        System.out.println("先放葱姜蒜");
        System.out.println("再放土豆丝");
        System.out.println("...");
    }
}
复制代码

川菜厨师SiChuanChef继承了厨师抽象类Chef，实现了抽象方法cooking。

package com.fanqiekt.principle.liskov;

/**
 * 服务员
 *
 * @author 番茄课堂-懒人
 */
public class Waiter {
    /**
     * 点餐
     * @param dishName 餐名
     */
    public void order(String dishName){
        System.out.println("客人点餐：" + dishName);

        Chef chef = new SiChuanChef();
        switch(dishName) {
            case "西红柿炒鸡蛋":
                chef = new ShanDongChef();
                break;
            case "酸辣土豆丝":      //取款
                chef = new SiChuanChef();
                break;
        }
        chef.cook(dishName);

        System.out.println(dishName + "上桌啦，请您品尝!");
    }
}
复制代码

服务员类Waiter有一个点餐order方法，根据不同的菜名去通知相应菜系的厨师去做菜。

这里就用到了里氏替换原则，引用父类Chef可以透明地使用子类ShanDongChef或者SiChuanChef。

package com.fanqiekt.principle.liskov;

/**
 * 客人
 *
 * @author 番茄课堂-懒人
 */
public class Client {
    public static void main(String args[]){
        Waiter waiter = new Waiter();
        waiter.order("西红柿炒鸡蛋");
        System.out.println("---------------");
        waiter.order("酸辣土豆丝");
    }
}
复制代码

我们运行一下。

客人点餐：西红柿炒鸡蛋
开始烹饪：西红柿炒鸡蛋
先炒鸡蛋
再炒西红柿
...
西红柿炒鸡蛋出锅
西红柿炒鸡蛋上桌啦，请您品尝!
---------------
客人点餐：酸辣土豆丝
开始烹饪：酸辣土豆丝
先放葱姜蒜
再放土豆丝
...
酸辣土豆丝出锅
酸辣土豆丝上桌啦，请您品尝!
复制代码

4、优点

撸过代码后，我们发现替换原则的几个优点。

里氏替换原则的核心思想就是继承，所以优点就是继承的优点。

代码重用通过继承父类，我们可以重用很多代码，例如厨师烹饪前的准备工作和出锅。

减少创建类的成本，每个子类都拥有父类的属性和方法。

易维护易扩展通过继承，子类可以更容易扩展功能。

也更容易维护了,公用方法都在父类中，特定的方法都在特定的子类中。

5、缺点

同上可知，它的缺点就是继承的缺点。

破坏封装继承是侵入性的，所以会让子类与父类之间紧密耦合。

子类不能改变父类可能造成子类代码冗余、灵活性降低，因为子类拥有父类的所有方法和属性。

6、嘻哈说

闲来无事听听曲，知识已填脑中去；学习复习新方式，头戴耳机不小觑。 番茄课堂，学习也要酷。 接下来，请您欣赏懒人为里氏替换原则创作的歌曲。

试听请点击这里

嘻哈说：里氏替换原则

隔壁的说唱歌手可以在乐库播放的beat freestyle歌曲
他们表演默契得体还充满乐趣
非抽象重写不是合理
抽象的重写不需客气
这是属于他们哲理
继承是里氏替换的核心想法
引用父类的地方透明使用子类会让代码更加强大
子类可以有自己特有方法
重载父类时形参更加的广大
不然可能覆盖父类方法
重写抽象方法时返回值类型要往下
因为类向上转换可以把心放下
八大菜系每个厨师都有自己拿手的
那些共有基本功也都掌握透彻
优点是易扩展易维护自动继承父类拥有的
复制代码