【专题系列】设计模式——二：里氏替换原则

谁借莪１个温暖的怀抱￠ 2023-03-06 08:07 12阅读 0赞

点击上方“Java大数据修炼之道”，右上角选择“**设为星标**”

### 你想要的优质技术好文第一时间送达！ ###

公众号后台回复“**资源**”，获取独家秘制精品资料

![format_png][]

来源 | https://www.cnblogs.com/three-fighter/p/12347360.html

# 什么是里氏替换原则？Why里氏替换原则？ #

先看看里氏替换原则（Liskov Substitution Principle）的定义：

<table> 
 <tbody> 
  <tr> 
   <td>Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.</td> 
  </tr> 
 </tbody> 
</table>

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

通俗的说，**子类可以扩展父类功能，但不能改变父类原有功能。**

**![format_png 1][]**

**这是一位女士Barbara Liskov 在1988 年提出——这是最原始的定义：**

<table> 
 <tbody> 
  <tr> 
   <td>“ What is wanted here is something like the following substitution property: 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. ”</td> 
  </tr> 
 </tbody> 
</table>

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

在面向对象的语言里，继承无疑是一个优秀的特性，它有提高代码复用性、扩展性等优点，但是白璧微瑕，它同样也会带来一些不足： ● 继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法； ● 降低了代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约 束； ● 增强了耦合性。当父类的常量、变量和方法被修改时，需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大段的代码需要重构。

为了扬长避短，就有必要引入里氏替换原则。

# 里氏抽丝剥茧 #

里氏替换原则包含了四层含义：

\* 子类必须完全实现父类的方法

在做系统设计时，经常会定义一个接口或抽象类，然后编码实现，调用类则直接传 入接口或抽象类，其实这里已经使用了里氏替换原则。

举个例子来说明这个原则，以CS游戏为例，来描述一下里面用到的枪，类图如图2-1所示：

2-1：CS游戏中的枪支类图

![format_png 2][]  
枪的主要职责是射击，如何射击在各个具体的子类中定义，手枪是单发射程比较近，步枪威力大射程远，机枪用于扫射。在士兵类中定义了一个方法killEnemy，使用枪来杀敌人， 具体使用什么枪来杀敌人，调用的时候才知道。

枪支抽象类：

public abstract class AbstractGun {
      //枪用来干什么的？杀敌！
      public abstract void shoot();
    }

手枪、步枪、机枪的实现类：

public class Handgun extends AbstractGun {
       //手枪的特点是携带方便，射程短
       @Override 
       public void shoot() {
         System.out.println("手枪射击...");
         }
     }
     
    
    public class Rifle extends AbstractGun{
      //步枪的特点是射程远，威力大
      public void shoot(){
        System.out.println("步枪射击...");
        }
    }
    
    
    public class MachineGun extends AbstractGun{
        public void shoot(){
          System.out.println("机枪扫射...");
         }
    }

士兵的实现类：

public class Soldier {
       //定义士兵的枪支
       private AbstractGun gun; //给士兵一支枪
       public void setGun(AbstractGun _gun){
           this.gun = _gun;
       }
      
       public void killEnemy(){
         System.out.println("士兵开始杀敌人...");
         gun.shoot();
       }
    
     }

定义士兵使用枪来杀敌，但是这把枪是抽象的，具体是手枪还是步枪需 要在上战场前（也就是场景中）前通过setGun方法确定。场景类Client如下：

场景类：

public class Client {
       public static void main(String[] args) {
          //产生三毛这个士兵
          Soldier sanMao = new Soldier(); //给三毛一支枪
          sanMao.setGun(new Rifle());
          sanMao.killEnemy();
        }
    }

在这个程序中，给三毛这个士兵一把步枪，然后就开始杀敌了。如果三毛要使用机枪，当然也可以，直接把sanMao.setGun(new Rifle())修改为sanMao.setGun(new MachineGun()) 即可，在编写程序时Solider士兵类根本就不用知道是哪个型号的枪（子类）被传入。

再来想一想，如果有一个玩具手枪，该如何定义呢？我们先在类图2-1上增加 一个类ToyGun，然后继承于AbstractGun类，修改后的类图如图2-2所示:

2-2:枪支类图![format_png 3][]

玩具枪是不能用来射击的，杀不死人的，这个不应该写在shoot方法中。

public class ToyGun extends AbstractGun {
      //玩具枪是不能射击的，但是编译器又要求实现这个方法，怎么办？虚构一个呗！
       @Override 
      public void shoot() {
      //玩具枪不能射击，这个方法就不实现了
       }
    }

由于引入了新的子类，场景类中也使用了该类，Client类稍作修改:

public class Client {
        public static void main(String[] args) {
           //产生三毛这个士兵 Soldier sanMao = new Soldier();
           sanMao.setGun(new ToyGun()); sanMao.killEnemy();
         }
    }

结果：

士兵开始杀敌人...

玩具枪开始杀人了！在这种情况下，我们发现业务调用类已 经出现了问题，正常的业务逻辑已经不能运行，那怎么办？有两种办法。

● 在Soldier类中增加instanceof的判断，如果是玩具枪，就不用来杀敌人。这个方法可以 解决问题，但是，在程序中，每增加一个类，所有与这个父类有关系的类都必须修改，显然，这个方案被否定了。

● ToyGun脱离继承，建立一个独立的父类，为了实现代码复用，可以与AbastractGun建 立关联委托关系，如图2-3所示:

2-3:玩具枪与真实枪分离的类图

![format_png 4][]例如，可以在AbstractToy中声明将声音、形状都委托给AbstractGun处理，然后两个基类下的子类自由延展，互不影响。

> 如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发 生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

\* 子类可以有自己的个性

子类可以有自己的行为和外观了，也就是方法和属性—— 里氏替换原则可以正着用，但是不能反过来用。在子类出现的地方，父类未必就可以胜任。还是以刚才的关于枪支的例子为例，步枪有几个比较“响亮”的型号，比如AK47、AUG 狙击步枪等，把这两个型号的枪引入后的Rifle子类图如图2-4所示：

2-4:增加AK47和AUG后的Rifle子类图![format_png 5][]

AUG继承了Rifle类，狙击手（Snipper）则直接使用AUG狙击步枪。

AUG狙击枪类代码：

public class AUG extends Rifle {
     //狙击枪都携带一个精准的望远镜
      public void zoomOut(){
       System.out.println("通过望远镜察看敌人...");
     }
     public void shoot(){
       System.out.println("AUG射击...");
     }
     
    }

狙击手类:

public class Snipper {
      public void killEnemy(AUG aug){
        //首先看看敌人的情况，别杀死敌人，自己也被人干掉
        aug.zoomOut();
        //开始射击
        aug.shoot();
     }
    }

狙击手使用狙击枪来杀死敌人，业务场景Client类如下：

public class Client {
       public static void main(String[] args) {
         //产生三毛这个狙击手
         Snipper sanMao = new Snipper();
         sanMao.setRifle(new AUG());
         sanMao.killEnemy();
       }
    }

运行结果：

通过望远镜察看敌人...
    AUG射击...

在这里，系统直接调用了子类，狙击手是很依赖枪支的，别说换一个型号的枪了，就是换一个同型号的枪也会影响射击，所以这里就直接把子类传递了进来。这个时候，我们能不 能直接使用父类传递进来呢？修改一下Client类：

public class Client {
      public static void main(String[] args) {
        //产生三毛这个狙击手
        Snipper sanMao = new Snipper();
        sanMao.setRifle((AUG)(new Rifle()));
        sanMao.killEnemy();
       }
    }

显然是不行的，会在运行期抛出java.lang.ClassCastException异常，这也是大家经常说的 向下转型（downcast）是不安全的，从里氏替换原则来看，就是有子类出现的地方父类未必就可以出现。

\* 覆盖或实现父类的方法时输入参数可以被放大

方法中的输入参数称为前置条件，这是什么意思呢？大家做过Web Service开发就应该知道有一个“契约优先”的原则，也就是先定义出WSDL接口，制定好双方的开发协议，然后再各自实现。里氏替换原则也要求制定一个契约，就是父类或接口，这种设计方法也叫做 Design by Contract（契约设计），与里氏替换原则有着异曲同工之妙。契约制定了，也就同 时制定了前置条件和后置条件，前置条件就是你要让我执行，就必须满足我的条件；后置条 件就是我执行完了需要反馈，标准是什么。这个比较难理解，来看一个例子。

先定义一个Father类：

public class Father {
      //把HashMap转换为Collection集合类型
      public Collection doSomething(HashMap map){
         System.out.println("父类被执行...");
         return map.values();
      }
    }

再定义一个子类:

public class Son extends Father {
      //放大输入参数类型
      public Collection doSomething(Map map){
         System.out.println("子类被执行...");
          return map.values();
     }
    }

子类的doSomething方法与父类的方法名相同，但又不是覆写（Override）父类的方法。方法名虽然相同，但方法的输入参数不同，就不是覆写，是重载（Overload）！——继承，子类拥有父类的所有属性和方法，方法名相同，输入参数类型又不 相同，当然是重载。

场景类的调用如下：

public class Client {
      public static void invoker(){
       //父类存在的地方，子类就应该能够存在
       Father f = new Father();
       HashMap map = new HashMap();
       f.doSomething(map);
      }
      public static void main(String[] args) {
        invoker();
     }
    }

运行结果：

父类被执行...

根据里氏替换原则，父类出现的地方子类就可以出现，修改场景类：

public class Client {
      public static void invoker(){
        //父类存在的地方，子类就应该能够存在
        Son f =new Son();
        HashMap map = new HashMap();
        f.doSomething(map);
      }
    
      public static void main(String[] args) {
        invoker();
      }
      
    }

运行结果还是一样。父类方法的输入参数是HashMap类型，子类的输入参数是Map类型，也就是说子类的输入参数类型的范围扩大了，子类代替父类传递到调用者中，子类的方法永远都不会被执行。这是正确的，如果你想让子类的方法运行，就必须覆写父类的方法。大家可以这样想，在一个Invoker类中关联了一个父类，调用了一个父 类的方法，子类可以覆写这个方法，也可以重载这个方法，前提是要扩大这个前置条件，就是输入参数的类型宽于父类的类型覆盖范围。这样说可能比较难理解，我们再反过来想一 下，如果Father类的输入参数类型宽于子类的输入参数类型，会出现什么问题呢？会出现父类存在的地方，子类就未必可以存在，因为一旦把子类作为参数传入，调用者就很可能进入 子类的方法范畴。

把上面的例子修改一下，扩大父类的前置条件：

public class Father {
        public Collection doSomething(Map map){
          System.out.println("父类被执行...");
          return map.values();
         }
     }

把父类的前置条件修改为Map类型，再修改一下子类方法的输入参数，相对父类缩小输入参数的类型范围，也就是缩小前置条件:

public class Son extends Father {
      //缩小输入参数范围
      public Collection doSomething(HashMap map){
        System.out.println("子类被执行...");
        return map.values();
     }
    }

在父类的前置条件大于子类的前置条件的情况下，业务场景:

public class Client {
      public static void invoker(){
        //有父类的地方就有子类
         Father f= new Father();
         HashMap map = new HashMap();
         f.doSomething(map);
      }
      
      public static void main(String[] args) {
       invoker();
      }
    }

运行结果：

父类被执行...

再把里氏替换原则引入进来——有父类的地方子类就可以使用，把Client类修改一下：

public class Client { public static void invoker(){
      //有父类的地方就有子类
      Son f =new Son();
      HashMap map = new HashMap();
      f.doSomething(map);
     }
     public static void main(String[] args) {
       invoker();
     }
    
    }

运行结果：

子类被执行...

子类在没有覆写父类的方法的前提下，子类方法被执行了，这会引起业务 逻辑混乱，因为在实际应用中父类一般都是抽象类，子类是实现类，你传递一个这样的实现 类就会“歪曲”了父类的意图，引起一堆意想不到的业务逻辑混乱，所以子类中方法的前置条 件必须与超类中被覆写的方法的前置条件相同或者更宽松。

\* 覆写或实现父类的方法时输出结果可以被缩小

父类的一个方法的返回值是一个类型T，子类的相同方法（重载或覆写）的返回值为S，那么里氏替换原则就要求S必须小于等于T，也就是说，要么S和T是同一 个类型，要么S是T的子类，为什么呢？分两种情况，如果是覆写，父类和子类的同名方法的 输入参数是相同的，两个方法的范围值S小于等于T，这是覆写的要求，这才是重中之重，子类覆写父类的方法，天经地义。如果是重载，则要求方法的输入参数类型或数量不相同，在 里氏替换原则要求下，就是子类的输入参数宽于或等于父类的输入参数，也就是说你写的这 个方法是不会被调用的，参考上面讲的前置条件。

采用里氏替换原则的目的就是增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑。

#### ![format_png 6][] ####

#### **最近热文阅读：** ####

1、[单怼多线程，60道面试题，你能答上几个？（附答案）][60]

2、[面试：SpringBoot中的条件注解底层是如何实现的？][SpringBoot]

3、[String 也能做性能优化，我只能说牛逼！][String]

4、[超实用的18个Java8日期处理的实践！][18_Java8]

5、[用 float 存储金额，老板说损失从工资里扣！][float]

6、[这12张手绘图，让我彻底搞懂了微服务架构！][12]

7、[别用Date了，Java8新特性之日期处理，现在学会也不迟！][Date_Java8]

8、[Java中当对象不再使用时，不赋值为null会导致什么后果 ？][Java_null_]

9、[SQL 查询总是先执行SELECT语句吗？你们都错了！][SQL _SELECT]

10[、][Link 1][看完这篇Redis缓存三大问题，保你能和面试官互扯。][Redis]

![format_png 7][]

关注 java大数据修炼之道

每天学习java技术，你想学的Java知识这里都有！

![format_png 8][]

微信扫描二维码，关注我的公众号

写留言

####  ####

![format_png 9][]

喜欢就给个“**在看![format_png 10][]**”

[format_png]: /images/20230208/a9039b195221494da94fa1c7fddbdca3.png
[format_png 1]: /images/20230208/c3f9b3a044204ea2b552cba7e7dfb031.png
[format_png 2]: /images/20230208/39d9f4ed2ac64024b9a9643aa3b9659a.png
[format_png 3]: /images/20230208/73f133daa6e5497cb9877cace05e94f9.png
[format_png 4]: /images/20230208/c89cdd72dc0a44a3bf67282b18383e65.png
[format_png 5]: /images/20230208/be01ae583a074c18a1aca396e987471e.png
[format_png 6]: /images/20230208/a40e1e38c1014904bfb4cf660a834d43.png
[60]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d557ccb65c41ec5d3b7dedd6c7a22949ddcb5de1406de482c3b702a1a4768c66b730b219&idx=1&mid=2247490459&scene=21&sn=66bc23ae41a8abcb9a6f00be754b2e47#wechat_redirect
[SpringBoot]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d591ccb65c874368c7940d76355d95185fb379cc3bc5f97fdc505b96ab1a03e68b59a94a&idx=1&mid=2247490397&scene=21&sn=9688c6f29545ea6c11325cbd6ab01c2a#wechat_redirect
[String]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d5c5ccb65cd32067452a76e79685a563fb47be405a259397f0a899396672e935ffa09e4e&idx=1&mid=2247490313&scene=21&sn=f03f579cf5f8653579b305c135fae4e3#wechat_redirect
[18_Java8]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d63bccb65f2da6a1a7ba0f156298c21a172a8854cded565a185d15e99526a148ea6fbc79&idx=1&mid=2247489783&scene=21&sn=eef2ab2031ff582be32294ac08519f20#wechat_redirect
[float]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d5cdccb65cdb97329d4ab51a9362c0515d6fe70c3def3dfa370cc2439fef10f9c2a87c51&idx=1&mid=2247490305&scene=21&sn=5649957d74d035a0919293b92a5659f6#wechat_redirect
[12]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d9ddccb650cbed70bc21e555c752bab52a17c8bcb0e4cfb356f182962292750f8ec76fe1&idx=1&mid=2247489297&scene=21&sn=ab0d58ba00ce54417fd267f46cd31827#wechat_redirect
[Date_Java8]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d61eccb65f0864848b37346e5974185df98744a6509b8330796898926ead638ebf5ef5c9&idx=1&mid=2247489746&scene=21&sn=50c98d26b5f2bf0d3d5be902468b54dc#wechat_redirect
[Java_null_]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d948ccb6505e641ab38065a467bbb95be017e9ca0b75e6a308cdf529b4fdb1eb2e68efcd&idx=1&mid=2247489412&scene=21&sn=08ef767e2395f127d389f768535cb09c#wechat_redirect
[SQL _SELECT]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d4f4ccb65de2f44c7cde53d564b73821a2308e29eecdfdaafa77dada11c557a8a32fb6ab&idx=1&mid=2247490104&scene=21&sn=f0b3928f9ba212ba622f28ee8af41ba1#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzUxOTAxODc2Mg%3D%3D&chksm=f9814d0acef6c41c85dbbcda170e6edf1a973eb487f6854dfced967ea276a9917fc942214fde&idx=1&mid=2247486831&scene=21&sn=056754e9204fc3a3f612b5e2cdb76a2a#wechat_redirect
[Redis]: http://mp.weixin.qq.com/s?__biz=MzU1NjczNTM5NQ%3D%3D&chksm=fbc1d5b1ccb65ca7e6c87ef32d3065111a9181c398e6ad39b66cf4f07f03167998a8b07f3bd1&idx=1&mid=2247490429&scene=21&sn=3c6e19f168166593d5d050bfe6b24410#wechat_redirect
[format_png 7]: /images/20230208/17d255d7c80c4bb99d947e164cd54c31.png
[format_png 8]: /images/20230208/131b01e001074b0e84fa107d2bd1d167.png
[format_png 9]: /images/20230208/e77cd74e1f004e71910366e941c86441.png
[format_png 10]: /images/20230208/a73c0b0b192e46f58ffe2f8f0685ea16.png