背景
最近在重构业务中的相关代码,在看之前的代码的时候有很多的感想。记录下来之前的不好之处。
业务需求
组装订单VO给客户端,每个字段可能都有一些业务逻辑组装。
实体类
@Data
public class Order {
private Integer id;
private Integer cTime;
private Integer uTime;
private String phone;
private String address;
.....
}
现有组装订单VO
@Test
public void componentOrderVo() {
Order order = new Order();
//1.构建基础信息
order.setId(4324324);
order.setCTime(323123123);
order.setUTime(323123123);
//模拟设置其他信息
this.setPhoneToOrderVo(order);
}
/**
* 设置电话信息
* @param orderVo
*/
private void setPhoneToOrderVo(Order orderVo) {
orderVo.setPhone("188xxxx3432");
}
....设置其他信息
良好的组装VO
软件的设计原则有包括单一职责原则和最小依赖原则,我们在设计接口和方法的时候一定要注意这个原则,一个方法尽可能只做一件事情,那么它的输入和输出应该也是比较单一的,只能满足本模块和方法的功能即可,不应该给与它更多的输入,防止在后续的迭代中方法的无良扩大。
@Test
public void componentOrderVo() {
Order order = new Order();
//1.构建基础信息
order.setId(4324324);
order.setCTime(323123123);
order.setUTime(323123123);
//模拟设置其他信息
String phone = this.getPhoneToOrderVo();
order.setPhone(phone);
}
小结
在涉及一个接口和写一个功能的时候我们不止要想怎么实现它当前的功能,需要考虑随着时间和业务的迭代,它可能会变成什么样子,也不要过度设计,防止后续的业务迭代可能不会按照你当前的思路进行,反而显得复杂,难懂。虽然是一个小功能,并且简单,但是使用两种方式设置值对之后的代码和可读性的影响完全不同。