"围观"设计模式(2)--里氏替换原则(LSP,Liskov Substitution Principle)

来源：互联网发布：淘宝卡哪个好编辑：程序博客网时间：2024/06/05 08:34

在面向对象的程序设计中，里氏替换原则（Liskov Substitution principle）是对子类型的特别定义。它由芭芭拉·利斯科夫（Barbara Liskov）在1987年在一次会议上名为“数据的抽象与层次”的演说中首先提出。

里氏替换原则的内容可以描述为： “派生类（子类）对象能够替换其基类（超类）对象被使用。” 以上内容并非利斯科夫的原文，而是译自罗伯特·马丁（Robert Martin）对原文的解读。其原文为：

Let $q(x)$ be a property provable about objects $x$ of type $T$ . Then $q(y)$ should be true for objects $y$ of type $S$ where $S$ is a subtype of $T$ .

芭芭拉·利斯科夫与周以真（Jeannette Wing）在1994年发表论文并提出的以上的Liskov代换原则。----维基百科

里氏替换原则我个人的理解是：在继承关系中，父类的对象如果替换为子类的对象，他原来执行的行为依然保持不变，那么这样的程序才符合里氏替换原则，否则违背了里氏替换原则。

下面我们看这样一个实例，体会下，里氏替换原则是在什么情况下违背的。

一个简单的继承结构，在子类中，重写父类的方法calc方法。

父类Calc：

[java] view plain copy
package cn.design.pattern2016032004LiskovSubstitutionPrinciple;  
  
public class Calc {  
  
    public void calc(int a, int b) {  
        // a-b = ?  
        System.out.println(a + " - " + b + " = " + (a - b));  
          
    }  
}  

子类CalcSon,通过将父类中calc这个方法重写为两个数相加。

[java] view plain copy
package cn.design.pattern2016032004LiskovSubstitutionPrinciple;  
  
public class CalcSon extends Calc{  
  
    public void calc(int a, int b) {  
        // a+b = ?  
        System.out.println(a + " + " + b + " = " + (a + b));  
    }  
      
    // other method  
    public void addThem(int a, int b) {  
        System.out.println(a + b);  
    }  
}  

测试类：这里如果符合里氏替换原则的话，那么应该说将父类的调用的这个地方直接换为子类的话，那么原来的行为不会发生任何的改变。但是下面的程序证明了，这样的做法是违背了里氏替换原则的。将原先父类调用的替换为子类的时候，会由原来的父类的方法：减法，变为现在子类中的：加法。结果发生变化，从而违背了里氏替换原则。

[java] view plain copy
Calc cal = new Calc();  
cal.calc(10, 20);  
          
/** 
* 根据里氏替换原则，当父类替换为子类的时候，使用父类的时候的行为不应该 
* 发生变化，那么下面的这段代码，显然发生了变化，这样显然违反了里氏替换 
* 原则。 
*/  
CalcSon calcSon = new CalcSon();  
calcSon.calc(10, 20);  

我们在子类继承父类之后，重写了父类的方法时，需要注意，这样的做法并不好，降低了整个继承体系的复用性，出错几率会相应的增加。

总结前人的诸多经验来看，里氏替换原则主要是有四点：

1. 子类不要覆盖父类的非抽象的方法。可以实现其抽象方法。

2. 子类可以实现自己独有的方法。

3. 子类的方法重写父类方法的时候，参数部分，要比父类的参数范围要大或者等于（宽松）。释义：举个例子>如果说父类的方法中形参是ArrayList,那么，其子类重写这个方法的时候，形参要是List.

4. 子类重写父类方法的时候，返回值要求，父类的返回值要比子类的返回值要小于或者等于。

面对这样的情况，一般的，将当前的继承结构解除掉，变为依赖或者聚合组合的形式。抽象出更高一层的抽象类，定义好这样的一个抽象方法，同时由原先的两个类继承实现。

[java] view plain copy
public abstract class Calculator {  
  
    public abstract void calc(int a, int b);  
}  

[java] view plain copy
public class Calc extends Calculator{  
  
    public void calc(int a, int b) {  
        // a-b = ?  
        System.out.println(a + " - " + b + " = " + (a - b));  
          
    }  
}  

[java] view plain copy
public class CalcSon extends Calculator{  
  
    public void calc(int a, int b) {  
        // a+b = ?  
        System.out.println(a + " + " + b + " = " + (a + b));  
    }  
      
    // other method  
    public void addThem(int a, int b) {  
        System.out.println(a + b);  
    }  
}  

通过这样的途径将原来的继承结构重新解构重组后的继承体系，应该说相对来说，出错的几率大大降低了。

源码已经上传至GitHub:下载设计模式代码

0 0