寂然解读设计模式 - 里氏替换原则

I walk very slowly, but I never walk backwards

设计模式原则 - 里氏替换原则

寂然

大家好，我是寂然~，本节课呢，我来给大家介绍设计模式原则之里氏替换原则，话不多说，我们直接进入正题，老规矩，首先带大家了解一下里氏替换原则的官方定义，并作一个解释，但是在此之前，我们先来聊聊ava面向对象最重要的特性之一 - 继承性

前情提要 - 聊聊继承性

继承性相信大家已经十分熟悉了，继承是面向对象的很重要的特性之一，其实我们今天课程要讲的里氏替换原则，就是要告诉我们，在编程中，如何正确的使用继承，这里有伙伴要问了，正确的使用怎么解？OK，那我们先来聊聊，分析下继承的优势和劣势

继承优势

● 提高代码的复用性（每个子类都拥有父类的方法和属性）

● 提高代码的可扩展性（很多开源框架的扩展接口都是通过继承父类来完成的）

继承劣势

● 继承是侵入性的（只要继承，就必须拥有父类的所有属性和方法）

● 继承机制很大的增加了耦合性（如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都可能产生故障）

上面提到了，里氏替换原则，就是要告诉我们，在编程中，如何正确的使用继承，带着这样的疑问，我们先来看下里氏替换原则的官方定义

官方定义

里氏替换原则（Liskov Substitution Principle，LSP）是1988年，麻省理工学院一位姓里的女士提出的，官方定义如下：

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型

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

所有引用基类的地方必须能透明地使用其子类的对象

基本介绍

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能

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

上面我们提到，继承给程序设计带来便利的同时，也带来了弊端，里氏替换原则即是给继承性制定了规范

案例演示 - 计算器

为了让大家体会一下我们上面说的，我们通过一个案例来详细说明一下

假设现在有一个计算器类，可以进行加法减法计算，我们定义其子类，进行需求的增补，简易代码如下：

//定义计算器类
class Calculator{

    //定义加法计算
    public int add(int a,int b){
        int result = a + b;
        return result;
    }

    //定义减法计算
    public int sub(int a,int b){
        int result = a - b;
        return result;
    }

}
//定义其子类
class HjCalculayor extends Calculator{

    //增补需求（两数相加之和 +5） 无意中重写了父类的方法
    public int add(int a,int b){
        int result = a + b + 5;
        return result;
    }

    //需求：二者相加之和，与100相减
    public int mul(int a,int b){

        int count = add(a, b);
        int result = 100 - count;
        return result;

    }
}

OK，我们对上述代码进行简单的测试，可以看到，子类需要实现需求，无意间重写了父类的方法

 public static void main(String[] args) {

      int mulResult = new HjCalculayor().mul(2, 3);
      System.out.println("二者相加之和再与100相减的结果为" + mulResult);
      //运行结果：二者相加之和再与100相减的结果为90  出现问题

 }

案例分析

我们发现原来运行正常的mul()方法发生了错误，原因就是子类 HjCalculayor 无意中重写了父类的方法，造成原有功能出现错误，在实际编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差，特别是运行多态比较频繁的时候，针对上述问题，我们来聊聊解决方案

解决方案

上面出现的情况，其实就是里氏替换原则担心的，我们可以扩展，但是不能改变父类原有的功能，里氏替换原则虽然这样说，但并非让我们因噎废食，放弃使用继承，我们可以通过其它方式来解决继承所带来的弊端，如：组合、聚合、依赖等方式，当然，这些后面在类关系中都会给大家展开深入讲解

比如这里，其中一种解决方案是让原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，如果类HjCalculayor 需要使用类 Calculator的方法，将二者变为组合关系来完成需求

//创建一个更加基础的基类
//把更加基础，需要复用的成员/方法写到基类中
class Base{
   //TODO...
}

//定义计算器类
class Calculator extends Base{

    //定义加法计算
    public int add(int a,int b){
        int result = a + b;
        return result;
    }

    //定义减法计算
    public int sub(int a,int b){
        int result = a - b;
        return result;
    }

}

class HjCalculayor extends Base{

    //如果 HjCalculayor需要使用 Calculator 类的方法，使用组合关系
    private Calculator calculator = new Calculator();

    //增补需求（两数相加之和 +5）
    public int add(int a,int b){
        int result = a + b + 5;
        return result;
    }

    //需求：二者相加之和，与100相减
    public int mul(int a,int b){

        int count = calculator.add(a, b);
        int result = 100 - count;
        return result;

    }
}

这样可以看到，在完成业务逻辑时，明确调用 calculator.add() 方法，这样既符合里氏替换原则，子类避免改变父类原有的功能，同时定义一个更加通俗的基类，改变原有的继承关系，也可以保证整个继承体系的复用性

深度解析

里氏替换原则其实还有以下两个含义，我们一起来聊聊

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

在我们做系统设计时，经常会设计接口或抽象类，然后由子类来实现抽象方法，这里使用的其实也是里氏替换原则，子类可以实现父类的抽象方法很好理解，事实上，子类也必须完全实现父类的抽象方法，哪怕写一个空方法，否则会编译报错，里氏替换原则的关键点在于不能覆盖父类的非抽象方法，这是他着重强调的

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

在继承父类属性和方法的同时，每个子类也都可以有自己的个性，在父类的基础上扩展自己的功能，前面其实已经提到，当功能扩展时，子类不要重写父类的方法，而是另写一个方法

注意事项

第一就是我们上面提到的，里氏替换原则虽然指出了继承带来的一些弊端，但是并非让我们放弃使用继承，而是给我们制定了编程中正确使用继承的规范，这是需要和大家再次强调的

第二，里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象

下节预告

OK，那既然上面提到了，里氏代换原则是实现开闭原则的重要方式之一，那我们掌握了里氏替换原则，下一节，我们正式进入开闭原则的学习，我会为大家用多个案例分析，来解读设计模式原则之开闭原则，以及它的注意事项和细节，最后，希望大家在学习的过程中，能够感觉到设计模式的有趣之处，高效而愉快的学习，那我们下期见~