【OO设计原则】——03里氏替换原则

里氏替换原则LSP（Liskov Substitution Principle）

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

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

这句话的意思是，一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别。只有衍生类可以替换基类，软件单位的功能才能不受影响，基类才能真正被复用，而衍生类也能够在基类的基础上增加新功能。

也就是说，LSP特征是：

• 所以使用基类代码的地方，用派生类代码替换后，能够正确的执行动作处理。
• 换句话说，如果派生类替换了基类后，不能够正确执行动作，那么他们的继承关系就应该废除。

里氏替换原则由Barbar Liskov(芭芭拉.里氏)提出，是继承复用的基石。即里氏替换原则LSP是使代码符合开闭原则的一个重要保证。  

例01

以此例来展示里氏替换原则，并引申出LSP的两个原则。

西方著名的例程为:正方形是否是长方形的子类(答案是"否")。类似的还有椭圆和圆的关系。

长方形

class Rectangle {
    double width;
    doubleheight;
       
    public double getHeight() {
        returnheight;
    }
    public void setHeight(doubleheight) {
        this.height = height;
    }
    public double getWidth() {
        returnwidth;
    }
    public void setWidth(doublewidth) {
        this.width = width;
    }  
}

正方形

class Square extends Rectangle {
    public void setHeight(doubleheight) {
        super.setHeight(height);
        super.setWidth(height);
    }
    
    public void setWidth(doublewidth) {
        super.setHeight(width);
        super.setWidth(width);
    }
}

这里Rectangle是基类，Square从Rectangle继承。

这种继承关系有什么问题吗？

假如已有的系统中存在以下既有的求面积的业务逻辑代码：

void area(Rectangle r) {
    r.setWidth(5);
    r.setHeight(4);
    if (r.getWidth() * r.getHeight() != 20) {
        throw new RuntimeException();
    }
}

则对应于扩展类Square，在调用既有业务逻辑时：

 Rectangle square = newSquare();
 area(square);

会抛出一个RuntimeException异常。这显然违反了LSP原则。

LSP体现了：

◇类的继承原则：如果一个继承类的对象可能会在基类出现的地方出现运行错误，则该子类不应该从该基类继承，或者说，应该重新设计它们之间的关系。

◇动作正确性保证：从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。

要满足里氏替换原则，达到继承扩展的目的，先决条件或本质是满足动作正确性保证

动作正确性：

基于契约设计(Design By Constract),简称DBC"这项技术对LISKOV代换原则提供了支持.该项技术Bertrand Meyer伯特兰做过详细的介绍:

使用DBC,类的编写者显式地规定针对该类的契约.客户代码的编写者可以通过该契约获悉可以依赖的行为方式.契约是通过每个方法声明的前置条件(preconditions)和后置条件(postconditions)来指定的.要使一个方法得以执行,前置条件必须为真.执行完毕后,该方法要保证后置条件为真.就是说,在重新声明派生类中的例程(routine)时,只能使用相等或者更弱的前置条件来替换原始的前置条件,只能使用相等或者更强的后置条件来替换原始的后置条件。

也就是说现在把前提条件以及后续条件应用到继承子类中，子类方法应该满足：

1.前提条件不强于基类

 覆写或重载父类方法时输入参数可以被放大
覆写或重载时同名方法的输入参数，子类必须要比父类更加宽松而不能小于父类的参数范围，否则就会出现父类出现的地方子类不能代替，从而违背LSP原则。

2.后续条件不弱于基类

覆写或重载父类方法时输出结果可以被缩小
父类的一个方法返回值的类型为T，子类相同方法的返回类型为S，LSP原则要求S必须小于等于T，即要么S和T是同一类型，要么S是T的子类。

例02

如果子类将违反LSP原则，那么应该如何重新设计它们之间的关系呢？下面的例子是经典的射击类游戏CS游戏当中涉及到场景，类图如下：

士兵使用枪来杀敌人，具体是使用什么枪要调用的时候才知道，而枪的职责是负责射击，不同的枪射击方法不一样，具体要在在枪的各个子类中去实现。相关代码实现：

抽象类 （基类） AbstractGun

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 {
    @Override
    public void shoot() {
        System.out.println("步枪射击");
    }
}

//机枪
public class MachineGun extends AbstractGun {
    @Override
    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("士兵开始杀敌....");
        this.gun.shoot();
    }
}

public class Client {
    public static void main(String[] args) {
        //创造一个士兵
        Soldier soldier = new Soldier();
        //给士兵一支步枪
        soldier.setGun(new Rifle());
        soldier.killEnemy();

        //给士兵一支手枪
        soldier.setGun(new HandGun());
        soldier.killEnemy();

        //给士兵一支机枪
        soldier.setGun(new MachineGun());
        soldier.killEnemy();
    }
}

注意，我们的Soldier类当中定义的gun是AbstractGun类型的，是一把抽象的枪，具体是一把什么样的枪在上战场前setGun才能确定，而在Client类当中我们给士兵一把步枪，士兵便使用步枪开始杀敌，士兵要使用手枪我们就set一个HandGun对象进去，士兵便使用手枪开始杀敌，士兵要使用机枪我们就set一个MachineGun对象进去，士兵便使用机枪开始杀敌。可以看到，在实现Soldier类的代码时我们根本就不需要关心士兵到底使用的是一把什么样的枪，只要是一把枪AbstractGun就行，在实际使用的场景当中它会被替换为一把真正的枪。

假如现在我们有一把玩具枪（不具备射击杀敌能力），把它添加到上面的设计中去，理所当然的，类图被修改如下：

因为玩具枪是不能射击杀人的所以我们不能实现shoot方法，代码修改如下：

public class ToyGun extends AbstractGun {
    @Override
    public void shoot() {
        //玩具枪不能射击杀人，所以这个方法空实现
    }
}

public class Client {
    public static void main(String[] args) {
        Soldier soldier = new Soldier();
        soldier.setGun(new ToyGun());
        soldier.killEnemy();
    }
}

 

假如我们在Client中使用这把玩具枪，结果是

士兵开始杀敌....

动作正确性保证（后置条件）遭到破坏。

可以看到我们的士兵在使用玩具枪开始杀敌了，但是玩具枪是不具备射击杀人功能，所以士兵会干着急。那么怎么解决这个问题呢：

在Soldier类的killEnemy方法中使用instanceof判断，如果是玩具枪就不用来杀敌。

if (this.gun instanceof ToyGun) {
      //do nothing
 } else {
      System.out.println("士兵开始杀敌....");
      this.gun.shoot();
}

这样可以解决问题，但是这样以后每增加一个类型的枪就可能要去修改Soldier类，很显然这违反了OCP原则。

正确办法，ToyGun脱离继承，建立独立的类。类图如下：

在AbstractToy我们将声音和形状委托给AbstractGun处理，这样以后两个基类下面的子类扩展就互不影响了。

上面的例子体现了LSP原则的一个特点：子类必须完全实现父类的方法。如果子类不能完全实现父类的方法，那么最好不再继续使用继承关系，使用依赖、组合关系来代替继承。

总结：

LSP: 子类必须能够替换基类。

Subtypes must besubstitutable  for their base types.

1. LSP关注的是怎样良好的使用继承，体现的OO特征：继承、多态。

2.  必须要清楚是使用一个Method还是要扩展它，但是绝对不是改变它。

3. LSP让我们得出一个重要的结论：一个模型如果孤立的看，并不具有真正意义的有效性。模型的有效性只能通过它的客户程序来表现。必须根据设计的使用者做出的合理假设来审视它。而假设是难以预测的，直到设计臭味出现的时候才处理它们。

4.对于LSP的违反也潜在的违反了OCP