从年初就开始温习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) {
}
}
校验码有几种形式
- 标准的20位长度的完整检验码
- 后6位简短的检验码,发票做验真业务时使用
- 区块链发票的检验码,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的嫌疑;在这个场景中也差不多,但抓住了这一点,重新思考一下,类层次与结构行为可以设计得更合理