LSP之instanceof

2021-03-23 15:19:18 浏览数 (1)

从年初就开始温习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的嫌疑;在这个场景中也差不多,但抓住了这一点,重新思考一下,类层次与结构行为可以设计得更合理

0 人点赞