从年初就开始温习SOLID原则，原则看似很简单，有些其实就是一句话，但对照这些原则去观看自己的过往代码，还是很多违背这些原则的，诚然，没有完美的实践，但需要保持在走向完美的路上
当然，如果你说天天在CRUD，从没有用到过这些原则，这就是另一个话题了
最近就写了一段很臭的代码，反省一下
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的层次
一个简单的校验码，为什么也要抽象成这样？
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
public interface Invoice { public CheckCode getCheckCode(); public String getVerifyCheckCode();
这儿有个疑问，为什么不在构建发票前，把verifyCheckCode转成normalCheckCode，而不是到Invoice的构建内部再转化，那也就没有instanceof的事
但再细想，对于发票来讲，其实只有一个checkCode属性，没有VerifyCheckCode，那只是在请求验真时的一种形态，所以在发票对象中，不应该有verifyCheckCode属性
所以Invoice对象应该是这样
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的嫌疑；在这个场景中也差不多，但抓住了这一点，重新思考一下，类层次与结构行为可以设计得更合理
