【Java设计模式 经典设计原则】三 SOLID-LSP里式替换原则

简介: 【Java设计模式 经典设计原则】三 SOLID-LSP里式替换原则

首先,不要误解这里的LSP哈,里式替换原则:Liskov Substitution Principle,缩写为 LSP。

理解里式替换原则

里式替换原则用中文描述出来,是这样的:子类对象(object of subtype/derived class)能够替换程序(program)中父类对象(object of base/parent class)出现的任何地方,并且保证原来程序的逻辑行为(behavior)不变及正确性不被破坏

这里的要求可不仅仅是功能一致,异常逻辑也需要一致才可以。举个例子:父类 Transporter 使用 org.apache.http 库中的 HttpClient 类来传输网络数据。子类 SecurityTransporter 继承父类 Transporter,增加了额外的功能,支持传输 appId 和 appToken 安全认证信息

父类Transporter

public class Transporter {
  private HttpClient httpClient;
  public Transporter(HttpClient httpClient) {
    this.httpClient = httpClient;
  }
  public Response sendRequest(Request request) {
    // ...use httpClient to send request
  }
}

子类SecurityTransporter

public class SecurityTransporter extends Transporter {
  private String appId;
  private String appToken;
  public SecurityTransporter(HttpClient httpClient, String appId, String appToken) {
    super(httpClient);
    this.appId = appId;
    this.appToken = appToken;
  }
  @Override
  public Response sendRequest(Request request) {
    if (StringUtils.isNotBlank(appId) && StringUtils.isNotBlank(appToken)) {
      request.addPayload("app-id", appId);
      request.addPayload("app-token", appToken);
    }
    return super.sendRequest(request);
  }
}

父子类的使用

public class Demo {    
  public void demoFunction(Transporter transporter) {    
    Reuqest request = new Request();
    //...省略设置request中数据值的代码...
    Response response = transporter.sendRequest(request);
    //...省略其他逻辑...
  }
}
// 里式替换原则
Demo demo = new Demo();
demo.demofunction(new SecurityTransporter(/*省略参数*/););

目前看起来是符合LSP的,但是只要稍微改动一下实现就可以破坏LSP:

// 改造前:
public class SecurityTransporter extends Transporter {
  //...省略其他代码..
  @Override
  public Response sendRequest(Request request) {
    if (StringUtils.isNotBlank(appId) && StringUtils.isNotBlank(appToken)) {
      request.addPayload("app-id", appId);
      request.addPayload("app-token", appToken);
    }
    return super.sendRequest(request);
  }
}
// 改造后:
public class SecurityTransporter extends Transporter {
  //...省略其他代码..
  @Override
  public Response sendRequest(Request request) {
    if (StringUtils.isBlank(appId) || StringUtils.isBlank(appToken)) {
      throw new NoAuthorizationRuntimeException(...);
    }
    request.addPayload("app-id", appId);
    request.addPayload("app-token", appToken);
    return super.sendRequest(request);
  }
}

在改造之后的代码中,如果传递进 demoFunction() 函数的是父类 Transporter 对象,那 demoFunction() 函数并不会有异常抛出,但如果传递给 demoFunction() 函数的是子类 SecurityTransporter 对象,那 demoFunction() 有可能会有异常抛出。尽管代码中抛出的是运行时异常(Runtime Exception),我们可以不在代码中显式地捕获处理,但子类替换父类传递进 demoFunction 函数之后,整个程序的逻辑行为有了改变。这样就违反了LSP

违背LSP的例子

进一步理解LSP:子类在设计的时候,要遵守父类的行为约定(或者叫协议)。父类定义了函数的行为约定,那子类可以改变函数的内部实现逻辑,但不能改变函数原有的行为约定。这里的行为约定包括:函数声明要实现的功能;对输入、输出、异常的约定;甚至包括注释中所罗列的任何特殊说明。实际上,定义中父类和子类之间的关系,也可以替换成接口和实现类之间的关系 ,基于这样的理解我们来看看有哪些违背LSP的例子:

1 子类违背父类声明要实现的功能

父类中提供的sortOrdersByAmount()订单排序函数,是按照金额从小到大来给订单排序的,而子类重写这个方法之后是按照创建日期来给订单排序的。那子类的设计就违背里氏替换原则。

2 子类违背父类对输入、输出、异常的约定

父类中某个函数约定:运行出错返回null;获取数据为空时返回空集合。子类重写函数之后,运行出错返回异常,获取不到数据返回null。那子类的设计就违背里氏替换原则。

父类中某个函数约定,输入数据可以是任意整数,子类实现只允许输入数据是正整数,负数就抛出,也就是说子类对输入的数据的校验比父类更加严格,那子类的设计就违背了里氏替换原则。

父类中某个函数约定,只会抛出ArgumentNullException异常,子类的设计实现抛出了其他的异常,那子类的设计就违背了里氏替换原则。

3 子类违背父类注释中所罗列的任何特殊说明

父类中定义的 withdraw() 提现函数的注释是这么写的:“用户的提现金额不得超过账户余额……”,而子类重写 withdraw() 函数之后,针对 VIP 账号实现了透支提现的功能,也就是提现金额可以大于账户余额,那这个子类的设计也是不符合里式替换原则的。

4 子类不能通过父类的单元测试

判断子类的设计实现是否违背里氏替换原则,我们可以拿父类的单元测试去验证子类的代码。如果某些单元测试运行事呗,就有可能说明子类的设计实现没有完全遵守父类的约定,子类就有可能违背了里氏替换原则。

多态和里氏替换原则的区别

多态是面向对象编程的一大特性,也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计原则,用来指导继承关系中子类该如何设计,子类的设计要保证在替换父类的时候,不改变原有程序的逻辑及不破坏原有程序的正确性。也就是说LSP基于多态,又可以反过来指导多态的设计。LSP的指导,可以在无副作用的情况下有如下优势

  • 改进已有实现。例如程序最开始实现时采用了低效的排序算法,改进时使用LSP实现更高效的排序算法。
  • 指导程序开发。告诉我们如何组织类和子类(subtype),子类的方法(非私有方法)要符合contract。
  • 改进抽象设计。如果一个子类中的实现违反了LSP,那么是不是考虑抽象或者设计出了问题。

例如一些通用框架的版本升级能保证正确的向后兼容。

总结一下

LSP乍一看对子类的实现限制有点儿死,但这样的好处是让父子类的继承关系更加健壮,相同方法子类能对父类功能做增强但又不会因此而带来预期外的结果或副作用。例如1.0版本的Sort接口基于LSP的实现为冒泡排序,2.0版本基于LSP增加了快速排序,这个时候用快速排序替换冒泡排序增强了排序效果,但又不脱离Sort的功能范围,不影响Sort的正常逻辑。

相关文章
|
13天前
|
设计模式 Java 程序员
[Java]23种设计模式
本文介绍了设计模式的概念及其七大原则,强调了设计模式在提高代码重用性、可读性、可扩展性和可靠性方面的作用。文章还简要概述了23种设计模式,并提供了进一步学习的资源链接。
31 0
[Java]23种设计模式
|
29天前
|
设计模式 监控 算法
Java设计模式梳理:行为型模式(策略,观察者等)
本文详细介绍了Java设计模式中的行为型模式,包括策略模式、观察者模式、责任链模式、模板方法模式和状态模式。通过具体示例代码,深入浅出地讲解了每种模式的应用场景与实现方式。例如,策略模式通过定义一系列算法让客户端在运行时选择所需算法;观察者模式则让多个观察者对象同时监听某一个主题对象,实现松耦合的消息传递机制。此外,还探讨了这些模式与实际开发中的联系,帮助读者更好地理解和应用设计模式,提升代码质量。
Java设计模式梳理:行为型模式(策略,观察者等)
|
2月前
|
存储 设计模式 安全
Java设计模式-备忘录模式(23)
Java设计模式-备忘录模式(23)
|
2月前
|
设计模式 存储 缓存
Java设计模式 - 解释器模式(24)
Java设计模式 - 解释器模式(24)
|
29天前
|
设计模式 Java
Java设计模式
Java设计模式
26 0
|
29天前
|
缓存 Java 数据库
JAVA分布式CAP原则
JAVA分布式CAP原则
46 0
|
1月前
|
设计模式 Java
Java设计模式之外观模式
这篇文章详细解释了Java设计模式之外观模式的原理及其应用场景,并通过具体代码示例展示了如何通过外观模式简化子系统的使用。
26 0
|
1月前
|
设计模式 Java
Java设计模式之桥接模式
这篇文章介绍了Java设计模式中的桥接模式,包括桥接模式的目的、实现方式,并通过具体代码示例展示了如何分离抽象与实现,使得两者可以独立变化。
41 0
|
1月前
|
设计模式 Java
Java设计模式之适配器模式
这篇文章详细讲解了Java设计模式中的适配器模式,包括其应用场景、实现方式及代码示例。
40 0
|
1月前
|
缓存 前端开发 Java
Java中的RESTful API原则
总结而言,遵循RESTful原则不仅能够提升API的互操作性,还便于维护和扩展,是构建现代Web服务的重要实践。通过精心设计的URI、利用HTTP协议特性以及采用成熟框架如Spring Boot,Java开发者能够高效地创建出既强大又易于使用的RESTful API。
49 0