前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >LSP之instanceof

LSP之instanceof

作者头像
码农戏码
发布2021-03-23 15:19:18
6220
发布2021-03-23 15:19:18
举报
文章被收录于专栏:DDD

从年初就开始温习SOLID原则,原则看似很简单,有些其实就是一句话,但对照这些原则去观看自己的过往代码,还是很多违背这些原则的,诚然,没有完美的实践,但需要保持在走向完美的路上

当然,如果你说天天在CRUD,从没有用到过这些原则,这就是另一个话题了

最近就写了一段很臭的代码,反省一下

代码语言:javascript
复制
public AbstractInvoice(InvoiceCode invoiceCode, InvoiceNo invoiceNo, PaperDrewDate paperDrewDate, CheckCode checkCode) {
    this.invoiceCode = invoiceCode;
    this.invoiceNo = invoiceNo;
    this.paperDrewDate = paperDrewDate;
    if (checkCode instanceof VerifyCheckCode) {
        this.checkCode = checkCode.toNormal();
    } else {
        this.checkCode = checkCode;
    }
}

这段代码很简单,业务是发票,一张发票由基本的几个要素组成:发票代码、发票号码、开票时间、检验码、金额

形象点,找个平常普通发票的票样

其次,这是一个抽象类,构建时带有发票几票素,这些InvoiceCode,InvoiceNo,PaperDrewDate,CheckCode都是简单的Primitive Domain(不了解这个概念也没关系,下回分解;简单讲就是业务自包含的基本类型)

完整的抽象类关系

但代码里面用到了instanceof,当用到这个关键字,而且是在抽象实体时,基本上可以断定是抽象的层次不够, 可能违背了LSP

LSP原则很明了:子类可以随时替换父类;这儿用了instanceof,说明有不可替换的成份在

再追看CheckCode的层次

一个简单的校验码,为什么也要抽象成这样?

代码语言:javascript
复制
public abstract class CheckCode {

    protected String checkCode;

    public CheckCode(String checkCode) {
        this.checkCode = checkCode;
    }

    public CheckCode(int length, String checkCode, boolean isNumeric) {
    }
}

校验码有几种形式

  1. 标准的20位长度的完整检验码
  2. 后6位简短的检验码,发票做验真业务时使用
  3. 区块链发票的检验码,5位长度,字母数字组合

因为有三种形态,不同的长度就是不同的类型;验真时只需要简短检验码;查看完整信息时需要完整的检验码

在发票接口中,也有相应的获取行为,也正因为有这种形为,需要在创建发票对象时,把VerifyCheckCode转换成NormalCheckCode

代码语言:javascript
复制
public interface Invoice {

    public CheckCode getCheckCode();

    public String getVerifyCheckCode();

这儿有个疑问,为什么不在构建发票前,把verifyCheckCode转成normalCheckCode,而不是到Invoice的构建内部再转化,那也就没有instanceof的事


但再细想,对于发票来讲,其实只有一个checkCode属性,没有VerifyCheckCode,那只是在请求验真时的一种形态,所以在发票对象中,不应该有verifyCheckCode属性

所以Invoice对象应该是这样

代码语言:javascript
复制
public interface Invoice {

    public CheckCode getCheckCode();
}

public AbstractInvoice(InvoiceCode invoiceCode, InvoiceNo invoiceNo, PaperDrewDate paperDrewDate, CheckCode checkCode) {
        this.invoiceCode = invoiceCode;
        this.invoiceNo = invoiceNo;
        this.paperDrewDate = paperDrewDate;
        this.checkCode = checkCode;
}

对于primitive domain,CheckCode自包含中应该带有verifyCheckCode

每一种CheckCode都有各自不同的行为


一般通过instanceof判断子类型时,都有不满足LSP的嫌疑;在这个场景中也差不多,但抓住了这一点,重新思考一下,类层次与结构行为可以设计得更合理

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-04-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 码农戏码 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档