Java设计模式之里氏替换原则精解

1.什么是里氏替换原则?

我们都知道,在面向对象编程中有三大特性(封装、继承、多态),在这里我们来说 继承 这个东西。

继承包含这样一层含义:父类中凡是已经实现好的方法,实际上是在设定规范和契约,虽然它不强制要求所有的子类必须遵循这些契约,但是如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏。

也就是说:继承在给程序设计带来便利的同时,也带来了弊端。比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能产生故障。

问题提出:在编程中,如何正确的使用继承? => 里氏替换原则

  • 里氏替换原则(Liskov Substitution Principle)在1988年,由麻省理工学院的以为姓里的女士提出的。
  • 如果对每个类型为Tl的对象o1,都有类型为T2的对象o2,使得以Tl定义的所有程序Р在所有的对象o1都代换成o2时,程序Р的行为没有发生变化,那么类型T2是类型TI的子类型。换句话说,所有引用基类的地方必须能透明地使用其子类的对象。
  • 在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类的方法。
  • 里氏替换原则告诉我们,继承实际上让两个类耦合性增强了,在适当的情况下,可以通过聚合,组合,依赖来解决问题。

2.代码案例

package com.szh.principle.liskov;

/**
 *
 */
// A类
class A {
    // 返回两个数的差
    public int func1(int num1, int num2) {
        return num1 - num2;
    }
}

// B类继承了A
// 增加了一个新功能:完成两个数相加,然后和9求和
class B extends A {
    //这里,重写了A类的方法, 可能是无意识
    public int func1(int a, int b) {
        return a + b;
    }

    public int func2(int a, int b) {
        return func1(a, b) + 9;
    }
}

public class Liskov {
    public static void main(String[] args) {
        A a = new A();
        System.out.println("11-3=" + a.func1(11, 3));
        System.out.println("1-8=" + a.func1(1, 8));
        System.out.println("-----------------------");

        B b = new B();
        System.out.println("11-3=" + b.func1(11, 3));  //这里本意是求出11-3
        System.out.println("1-8=" + b.func1(1, 8));    //这里本意是求出1-8
        System.out.println("11+3+9=" + b.func2(11, 3));
    }
}

从代码运行结果中看到,有两行出了问题,这是因为B继承A之后,并且重写了func1方法,那么此时就不会再去执行A类的func1方法了,而是执行B自己的func1方法,而B中func1方法的逻辑是对两个数求和,所以这里你以为的就不再是你以为的了。

3.改进代码

我们发现原来运行正常的相减功能发生了错误。原因就是类B无意中重写了父类的方法,造成原有功能出现错误。在实际编程中,我们常常会通过重写父类的方法完成新的功能,这样写起来虽然简单,但整个继承体系的复用性会比较差。特别是运行多态比较频繁的时候。

通用的做法是: 原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,采用依赖,聚合,组合等关系代替。

package com.szh.principle.liskov.improve;

/**
 *
 */
//创建一个更加基础的基类
class Base {
    //把更加基础的方法和成员写到Base类
}

// A类
class A extends Base {
    // 返回两个数的差
    public int func1(int num1, int num2) {
        return num1 - num2;
    }
}

// B类继承了A
// 增加了一个新功能:完成两个数相加,然后和9求和
class B extends Base {
    //如果B需要使用A类的方法,使用组合关系
    private A a = new A();

    //这里,重写了A类的方法, 可能是无意识
    public int func1(int a, int b) {
        return a + b;
    }

    public int func2(int a, int b) {
        return func1(a, b) + 9;
    }

    //我们仍然想使用A的方法
    public int func3(int a, int b) {
        return this.a.func1(a, b);
    }
}

public class Liskov {
    public static void main(String[] args) {
        A a = new A();
        System.out.println("11-3=" + a.func1(11, 3));
        System.out.println("1-8=" + a.func1(1, 8));
        System.out.println("-----------------------");

        B b = new B();
        //因为B类不再继承A类,因此调用者不会再认为func1方法是求减法
        //调用完成的功能就会很明确
        System.out.println("11+3=" + b.func1(11, 3));//这里本意是求出11+3
        System.out.println("1+8=" + b.func1(1, 8));//这里本意是求出1+8
        System.out.println("11+3+9=" + b.func2(11, 3));
        //使用组合仍然可以使用到A类相关方法
        System.out.println("11-3=" + b.func3(11, 3));// 这里本意是求出11-3
    }

}

此时我们创建一个更基础的Base类,让A和B都继承这个类,如果还想像之前那样在B中使用A,那么就采用 组合 来解决,即在B类中声明一个 私有的A类成员变量就可以了。

到此这篇关于Java设计模式之里氏替换原则精解的文章就介绍到这了,更多相关Java 里氏替换原则内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Java设计模式之依赖倒转原则精解

    目录 1.什么是依赖倒转原则? 2.代码案例 3.依赖关系传递的三种方式和案例举例 3.1 接口传递 3.2 构造方法传递 3.3 setter方法传递 4.依赖倒转原则总结 1.什么是依赖倒转原则? 高层模块不应该依赖低层模块,二者都应该依赖其抽象. 抽象不应该依赖细节,细节应该依赖抽象. 依赖倒转 (倒置) 的中心思想是面向接口编程. 依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多.以抽象为基础搭建的架构比以细节为基础的架构要稳定的多.在Java中,抽象指的是接口

  • Java设计模式之开闭原则精解

    目录 1.什么是开闭原则? 2.违反Ocp代码案例 3.遵守Ocp代码案例 1.什么是开闭原则? 开闭原则(Open Closed Principle)是编程中最基础.最重要的设计原则. 一个软件实体如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方).用抽象构建框架,用实现扩展细节. 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化. 编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则. 2.违反Ocp代码案例 package c

  • 详解java设计模式中的门面模式

    门面模式又叫外观模式(Facade Pattern),主要用于隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口. 我们知道电视剧操作很简单,但是里面的设计和原理很少人明白,这就是因为电视剧的设计应用了门面模式 一个电视剧至少需要有以下几个模块的功能:信号输入.音频处理.视频处理.信号输出等 /** * 射频信号输入 */ public class SignalIn { // } * 音频/视频信号输出 public class SignalOut { * 音频处理 public c

  • java设计模式(实战)-责任链模式

    目录 一:模式说明 二:项目实战 三:源代码 一:模式说明 模式定义:使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关系.将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止. 责任链模式的重点是在“链”上,由一条链去处理相似的请求在链中决定谁来处理这个请求,并返回相应的结果(取自<设计模式之禅>). 翻译:Client对象调用一个处理者(类)的方法,可能有多个处理者(实现类),但是该对象只需要调用第一个处理者(类)即可,该模式会自动分配谁来处理这个请求:这

  • Java设计模式之迪米特原则精解

    目录 1.什么是迪米特原则? 2.违反迪米特原则代码案例 3.遵守迪米特原则代码案例 4.迪米特原则的注意事项 1.什么是迪米特原则? 一个对象应该对其他对象保持最少的了解. 类与类关系越密切,耦合度越大. 迪米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的类知道的越少越好.也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部.对外除了提供的public方法,不对外泄露任何信息. 迪米特法则还有个更简单的定义:只与直接的朋友通信. 直接的朋友:每个

  • Java依赖倒转原则_动力节点Java学院整理

    定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率. 依赖倒置原则基于这样一个事实:相对于细节的多变性,

  • Java设计模式之职责链模式详解

    目录 前言 一.职责链模式的定义与特点 二.职责链模式的结构 三.职责链模式案例 前言 本文简单介绍了设计模式的一种--职责链模式  一.职责链模式的定义与特点 定义: 为了避免请求发送者与多个请求处理者耦合在一起,于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链:当有请求发生时,可将请求沿着这条链传递,直到有对象处理它为止. 比如我们的审批制度,低等级的审批不了的,交给上一级审批,依次类推,直到审批结束. 在责任链模式中,客户只需要将请求发送到责任链上即可,无须关心请求的处

  • 详解Java设计模式中的装饰模式

    目录 一.装饰模式的定义和特点 二.装饰模式的结构 三.咖啡点单案例演示 四.总结 一.装饰模式的定义和特点 在软件开发过程中,有时想用一些现存的组件.这些组件可能只是完成了一些核心功能.但在不改变其结构的情况下,可以动态地扩展其功能.所有这些都可以釆用装饰器模式来实现. 就像我们做菜,需要用到调料,菜,刀,火等一系列抽象的组件来最终完成一道菜. 装饰模式的定义: 指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)的模式,它属于对象结构型模式.就增加功能来说,装饰模式

  • Java设计模式之里氏替换原则精解

    1.什么是里氏替换原则? 我们都知道,在面向对象编程中有三大特性(封装.继承.多态),在这里我们来说 继承 这个东西. 继承包含这样一层含义:父类中凡是已经实现好的方法,实际上是在设定规范和契约,虽然它不强制要求所有的子类必须遵循这些契约,但是如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏. 也就是说:继承在给程序设计带来便利的同时,也带来了弊端.比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到

  • Java设计模式之接口隔离原则精解

    1.什么是接口隔离原则? 客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口范围上. 2.对应代码 上面这张图呢,就违反了接口隔离原则.它对应的代码如下: package com.szh.principle.segregation; /** * */ interface Interface1 { void operation1(); void operation2(); void operation3(); void operation4(); void operati

  • Java设计模式之单一职责原则精解

    1.什么是单一职责原则? 首先我们可以对某个类来说,即一个类应该只负责一项职责.如类A负责两个不同职责: 职责1,职责2.当职责1需求变更而改变A时,可能造成职责2执行错误,所以需要将类A的粒度分解为A1,A2. 我们来看下面这段代码: package com.szh.principle.singleresponsibility; /** * 交通工具类 * 方式1 * 1. 在方式1的run方法中,违反了单一职责原则 * 2. 解决的方案非常的简单,根据交通工具运行方法不同,分解成不同类即可

  • Java设计模式七大原则之里氏替换原则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 定义 里氏替换原则(Liskov Substitution Principle,LSP),官方定义如下: 如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象 o1都代换成o2时,程序P的行为没有发生变化,那么类型S是类型T的子类型,所有引用基类的地方必须能透明地使用其子类的对象.则通俗的来讲:子类可以扩展父类的功能,但是子类不能修改父类原有的功能 里氏替换原则就是给继承性的使用制定了规范 案例 需求

  • java面向对象设计原则之里氏替换原则示例详解

    目录 概念 实现 拓展 概念 里氏替换原则是任何基类出现的地方,子类一定可以替换它:是建立在基于抽象.多态.继承的基础复用的基石,该原则能够保证系统具有良好的拓展性,同时实现基于多态的抽象机制,能够减少代码冗余. 实现 里氏替换原则要求我们在编码时使用基类或接口去定义对象变量,使用时可以由具体实现对象进行赋值,实现变化的多样性,完成代码对修改的封闭,扩展的开放.如:商城商品结算中,定义结算接口Istrategy,该接口有三个具体实现类,分别为PromotionalStrategy (满减活动,两

  • 详解Java设计模式编程中的里氏替换原则

    定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型. 定义2:所有引用基类的地方必须能透明地使用其子类的对象. 问题由来:有一功能P1,由类A完成.现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成.新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障. 解决方

  • 解析Java实现设计模式六大原则之里氏替换原则

    一.什么是里氏替换原则 1.1.里氏替换原则定义 里氏替换原则(Liskov Substitution principle)是对子类型的特别定义的. 为什么叫里氏替换原则呢?因为这项原则最早是在1988年,由麻省理工学院的一位姓里的女士(Barbara Liskov)提出来的. 里氏替换原则有两层定义: 定义1 If S is a subtype of T, then objects of type T may be replaced with objects of type S, withou

随机推荐