匠心精神--来看一个小迭代的代码实现

问题

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

修改方案

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

代码实现

先介绍这个模型类QueryInvoiceResultResponse，是一个普通的POJO，一堆field，一堆getter&setter，往下翻还有个使用IDE生成的toString方法，洋洋洒洒300余行代码。

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

是的，就是这么简单。

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

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

2）再说说这个300余行的POJO类，显然缺乏代码简洁度。在需求不断迭代过程中，我们不应该总是新增代码，而要适时调优代码。就拿这个POJO来说，我们做一番小改造，首先用lombok的@Data注解来取代getter&setter，以及IDE快捷生成的toString方法。这些都是举手之劳，却能带来极好的效果。这次CR时我就发现开发人员遗忘了重新生成toString方法，致使toString方法中没有体现新增的invoiceTypeId，这对于一个300余行代码的POJO类来说是很容易漏掉的，因此，我们完全借助lombok的@Data或@ToString就好了，没必要自己每次都生成。

/**
 * 查询开票结果返回实体
 *
 * @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;

    ...
    ...

    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;
    }
}