里氏替换原则:切忌按照常识实现类间的继承关系

前端之家收集整理的这篇文章主要介绍了里氏替换原则:切忌按照常识实现类间的继承关系前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

什么是里氏替换原则

里氏替换原则(Liskov Substitution Principle LSP)定义为:任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。

为什么需要里氏替换原则

里氏替换原则看起来好像没啥了不起的,不就是继承要注意的一丢丢细节么,年轻人呐,你这样的思想很危险啊。事实上里氏替换原则常常会被违反,我在下面举例说明吧:

我们定义了一个矩形类:

public class Rectangle {
    private int width;
    private int height;

    public void setWidth(int width){
        this.width = width;

        System.out.println("Rectangle width" + width);
    }

    public void setHeight(int height){
        this.height = height;

        System.out.println("Rectangle height" + height);
    }
}

从数学知识来看,我们认为正方形是特殊的矩形(长宽相等),那么如果我们需要一个正方形类,一般都会把代码写成下面那样:

public class Square extends Rectangle{

}

大家有没有想到,本来正方形只需要边长的值就足够完成它的需求了,但是,由于 Square 继承于 Rectangle,那么 Square 类中必然拥有 width 和 height,即使我们在设置它们大小的时候让它们同时改变,但是 width 和 height 一定有一个是多余的。那么如果我们需要画成千上万个正方形的时候,就会产生成千上万个多余的 width 或 height。

此外,让 Square 继承 Rectangle 还会出现很奇怪的问题:由于里氏替换原则,只要是 Rectangle 类能出现的地方,Square 类必须也能出现,那么,任何对 Rectangle 类的对象进行 setWidth()/setHeight() 方法操作的地方,应该都能使用 Square 类的对象进行相同的操作。但是,Square 类明明长宽相等,为什么要进行同样的操作两次呢?

可能大家觉得这个例子说服力不够,那我再举一个例子来说明即使我们重写了 setWidth()/setHeight() 方法,仍然会存在问题:

public class Square extends Rectangle{
    @Override
    public void setHeight(int height) {
        super.setWidth(height);
        super.setHeight(height);

        System.out.println("Square height" + height);
    }

    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width);

        System.out.println("Square width" + width);
    }
}

然后在操作 Square 和 Rectangle 的类中添加一个这样的方法

public void initRec(Rectangle r){
        r.setWidth(6);
        r.setHeight(10);
    }

由于里氏替换原则,我们当然可以将 Square 类对象传入这个方法,那么问题就来了,此时 Square 类对象的边长到底是哪一个呢?我们分别将 Rectangle 和 Square 传入该方法,看看实际的输出

Rec
Rectangle width6
Rectangle height10
Squ
Rectangle width6
Rectangle height6
Square width6
Rectangle width10
Rectangle height10
Square height10

大家也会发现了,这个时候 Squ 的行为已经变得很奇怪了,它的边长到底是6还是10呢?当然了,要修复这个 Bug 很简单,但这不代表代码是没有问题的,因为为了修正这个错误,我们又得回去修改类,以符合实际的情况,不信的话再看下面的例子:

矩形能够计算面积很正常对吧?那我们就为 Rectangle 类添加计算面积的方法

public int getRecArea(Rectangle r){
        return r.getHeight()*r.getWidth();
    }

然后把这个方法放到 initRec() 方法里面执行,那么,当我们把 Square 对象传到 initRec() 方法内部时肯定没有问题,但是计算出来的面积肯定有问题,因为我们刚刚就说了,连 Square 对象的边长都确定不了,我们要怎么去确定它的面积呢?

问题到底出在哪?

大家到现在也许会发现,即使是这么简单的 Square 和 Rectangle 类间关系,都会让我们在维护过程中痛苦不已,不断地回去修改类内的代码添加各种各样规避错误的逻辑。很多人就会觉得很奇怪了,这样写类应该是没有问题的啊,为什么会出现这样的错误啊?

实际上,问题的根源在于,在程序设计时,Square 类并不能被看作 Rectangle 类的子类,即使在数学上正方形就是特殊的矩形。因为 Square 类的行为和属性和 Rectangle 类的行为和属性是不一致的,将两个类的行为和属性进行抽象我们会发现两者根本不能达到一致:

Square 的属性只有边长,而 Rectangle 有 width 和 height
Square 只需要一个设置边长的方法,而 Rectangle 则需要两个 set 方法

所以从这个例子中我们也能发现,在程序设计的过程中,进行类间继承关系的设计并不能按照常识去执行,而是需要从实际出发,从类的抽象行为、抽象属性出发,考虑类间的关系是否能成为一个 is-a 关系,如果子类 B 和父类 A 不能实现完全的 is-a 关系,那么我们能就不能进行继承。换句话说,如果类 B 中的某些实现又需要依赖类 A 的某些实现,那么我们就该考虑将这部分实现转到接口之中,让类 A 和类 B 同时实现该接口。

猜你在找的设计模式相关文章