来点小匠心- - - -一个POJO类的开发迭代和代码调优

知识就是力量，但更重要的是运用知识的能力。

【本文运用的知识点】1.最少知道原则；2.保留必要的javadoc注释；3.借助工具消除冗余代码

迭代背景

我司平台为合作商户提供的对接API中，有一个年久失修的开票记录查询接口，近期在一次集中测试时，发现这个接口的响应值与接口文档里描述的不一致。代码里定义的属性名是type，而文档里参数名是invoiceTypeId。显然，要解决这个不一致。

修改方案

因为无法确定原先的type有没有商户在用，所以，在模型类里新增invoiceTypeId，以保证与文档一致。

 

代码实现

先介绍这个模型类QueryInvoiceResultResponse，是一个普通的POJO，一堆field属性，一堆样板代码（getter & setter & toString），洋洋洒洒300余行代码。

代码怎么改呢？
这还不太简单！新增一个名为invoiceTypeId的私有field，增加getter&setter方法，再在声明这个对象的业务类里，调setInvoiceTypeId，妥了。

是的，就是这么简单。

 

once you do, do it well. 我们来看更好的代码实现方式

下面两点，各位判官评判一下是否可以体现出来一点点匠心精神。

1）比较type与invoiceTypeId这2个字段名，不难看出type无法完整表达其含义，invoiceTypeId更优。既然如此，根据最少知识原则（LKP,又称迪米特法则），我们将type隐藏起来，不让外部业务类再关注type，只需关注invoiceTypeId即可。另外，既然保留了type，那么，就要在其javadoc注释里注明保留的背景和原因，便于维护和理解。

2）这个300余行的POJO类，显然缺乏代码简洁度。在需求不断迭代过程中，我们不应该总是追加代码，而要适时refactor。我们系统依赖了Lombok工具包，大可利用Lombok功能强大的注解来为其瘦身，仅保留field属性，屏蔽掉getter&setter、toString()、equals()和hashCode()等方法。举手之劳，收益丰厚。首先，减少冗余的样板代码，没必要每次迭代都手动添加，大大简化类的维护成本。其次，在CR时我发现开发人员遗忘了重新生成toString方法，致使toString方法中没有体现新增的invoiceTypeId，这对于一个300余行冗长代码的POJO类来说不足为奇。

/**
 * 查询开票结果返回实体
 *
 * @Author :  peanut
 * @Created : 2020/11/23 下午11:16
 */
@Data
public class QueryInvoiceResultResponse {
    /**
     * 服务商ID
     **/
    private Long levyId;
    /**
     * 商户号
     **/
    private String merId;
    /**
     * 发票类目。 2023-5-15经验证发现对外暴露API里，发票类目参数名是{@link #invoiceTypeId}，但不确定这个type是否有商户使用，暂时保留
     **/
    private Long type;
    /**
     * 发票类目id
     */
    private Long invoiceTypeId;
    /**
     * 申请开票金额（单位：分）
     **/
    private Long amt;

    private String ...;

    private ...;

    public void setInvoiceTypeId(Long invoiceTypeId) {
        this.invoiceTypeId = invoiceTypeId;
        this.setType(invoiceTypeId);
    }

    /**
     * 不再对外暴露setType方法
     * @see #setInvoiceTypeId(Long) 
     * @param type
     */
    private void setType(Long type) {
        this.type = type;
    }
}