设计模式6大原则（2）：里氏替换原则

里氏替换原则

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

刚看到这项原则的时候很困惑，完全不懂什么意思，不过根据西方人思维，喜欢用人名来命名，以纪念或彰显某个人的功绩等等，猜测是一个叫里氏的人提出来的。后来查阅维基百科，这个原则由麻省理工学院的芭芭拉·利斯科夫（Barbara Liskov）在1987年在一次会议上名为“数据的抽象与层次”的演说中首先提出。

这里说说Barbara，很牛x的一位女性，美国第一个获得计算机科学博士学位的女性（1968年，斯坦福大学），1972年成为麻省理工学院的教授。2008年度美国计算机学会（ACM）图灵奖（Turing Award）获得者。为计算机的发展做出了很大贡献。

言归正题，说里氏替换之前，不得不先说说继承。

以下这段摘自《设计模式之禅》
 
在面向对象的语言中，继承是必不可少的、非常优秀的语言机制，它有如下优点：

    代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
    提高代码的重用性；
    子类可以形似父类，但又异于父类，“龙生龙，凤生凤，老鼠生来会打洞”是说子拥有父的“种”，“世界上没有两片完全相同的叶子”是指明子与父的不同；
    提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，君不见很多开源框架的扩展接口都是通过继承父类来完成的；
    提高产品或项目的开放性。


 
自然界的所有事物都是优点和缺点并存的，即使是鸡蛋，有时候也能挑出骨头来，继承的缺点如下：

    继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法；
    降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束；
    增强了耦合性。当父类的常量、变量和方法被修改时，必需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大片的代码需要重构。
 
Java使用extends关键字来实现继承，它采用了单一继承的规则，C++则采用了多重继承的规则，一个子类可以继承多个父类。从整体上来看，利大于弊，怎么才能让“利”的因素发挥最大的作用，同时减少“弊”带来的麻烦呢？

里氏替换原则就是用来描述使用继承的一种原则，达到利最大，弊最小。

里氏替换的定义有两种，原始的说法是：

If for each object o1 of type S there is an object o2of type T such that for all programs P defined in terms of T,the behavior of Pis 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 baseclasses must be able to use objects of derived classes without knowing it.所有引用基类的地方必须能透明地使用其子类的对象。

其实就是高层不应该依赖底层，父类可以替换成子类，即子类必须能够完全代替父类，而父类不能替换子类，否则就是不合理的继承。

具体有4层含义

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

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

3.当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。

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

前两个含义意思就是，子类可以扩展父类功能，但是不能修改父类原有的功能，如果修改了，子类就不能替换父类了，这个子类就太有个性了，里氏替换就是不让子类有个性，子类一旦有个性，就只能单独使用子类，这样会让类间的耦合关系变得扑朔迷离——缺乏类替换标准，比如。

class Math {
    public int func(int a,int b) {
       return a + b;
    }
}
class MathExt extends Math {
    @Override
    public int func(int a,int b) {
       return a - b;
    }
}
class Client {
    public static void main(String[] args) {
       Math math = new Math();
       Math math2 = new MathExt();
    }
}

MathExt虽然继承Math了，但是math和math2实现了不同的两个功能，使用者完全不明白这种继承关系的含义。

后两个含义也是前两个含义的补充，第3个含义，子类方法传入的参数要比父类宽松，即子类接收的参数要大于父类，要能包含父类，这样使用类型是父类，实例是子类时，能保证传入的参数一定能符合要求。比如下面这段代码：

class Father {
    public void func(HashMap m) {
       System.out.println("执行父类...");
    }
}
class Son extends Father {
    public void func(Map m) {// 方法的形参比父类的更宽松
       System.out.println("执行子类...");
    }
}

最后一个，子类返回值要比父类的严格，即子类返回值范围要小于父类，这样才能保证使用父类时，子类返回值一定符合父类要求。比如下面这段代码：

abstract class Father {
    public abstract Map func();
}
 
class Son extends Father {
    @Override
    public HashMap func() {// 方法的返回值比父类的更严格
        return new HashMap();
    }
}

其实，我们会发现在自己编程中常常会违反里氏替换原则，而且有时候故意这么做的，比如子类继承父类了，而且为了不让别人使用某个父类的方法，子类覆写时，里面直接抛出异常。比如：

class Father {
    public void fuck(String name) {
        System.out.println("fuck" + name);
    }
}
 
class Son extends Father {
    @Override
    public void fuck(String name) {// 方法不想让别人用
        throw new RuntimeException("We need to be polite");
    }
}

这样也没有问题，还是那句话，原则是死的，人是活的，这么写不好，我们应该避免，但有时候受各方面因素制约，我们也要有取舍。非要不遵循里氏替换原则的后果就是：你写的代码出问题的几率将会大大增加。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!