文章收录在我的 GitHub 仓库,欢迎Star/fork:
Java-Interview-Tutorialhttps://github.com/Wasabi1234/Java-Interview-Tutorial
本文就教你如何优雅消除重复代码并改变你对业务代码没技术含量的观念。
很多 crud 工程师抱怨业务开发没有技术含量,什么设计模式、高并发都用不到,就是堆CRUD。每次面试被问到“讲讲常用设计模式?”,都只能把单例讲到精通,其他设计模式即使听过也只会简单说说,因为根本没实际用过。
对于反射、注解,也只是知道在框架中用的很多,但自己又不写框架,更不知道该如何使用。
提升项目的可维护性是每个 coder 必须注意的,非常重要的一个手段就是减少代码重复,因为重复过多会导致:
开发购物车下单,对不同用户不同处理:
实现三种类型的购物车业务逻辑,把入参Map对象(K:商品ID,V:商品数量),转换为出参购物车类型Cart。
VIP用户能享受同类商品多买的折扣。只需额外处理多买折扣部分。
免运费、无折扣,只处理商品折扣和运费时的逻辑差异。
三种购物车超过一半代码重复。
虽然不同类型用户计算运费和优惠的方式不同,但整个购物车的初始化、统计总价、总运费、总优惠和支付价格逻辑都一样。
代码重复本身不可怕,可怕的是漏改或改错。
比如,写VIP用户购物车的同学发现商品总价计算有Bug,不应该是把所有Item的price加在一起,而是应该把所有Item的price*quantity
相加。
他可能只修VIP用户购物车的代码,漏了普通用户、内部用户的购物车中重复逻辑实现的相同Bug。
有三个购物车,就需根据不同用户类型使用不同购物车。
就只能不断增加更多的购物车类,写重复的购物车逻辑、写更多if逻辑吗?
当然不是,相同的代码应该只在一处出现!
可以把重复逻辑定义在抽象类,三个购物车只要分别实现不同部分的逻辑。
这其实就是模板方法模式。
在父类中实现购物车处理的流程模板,然后把需要特殊处理的留抽象方法定义,让子类去实现。由于父类逻辑无法单独工作,因此需要定义为抽象类。
如下代码所示,AbstractCart抽象类实现了购物车通用的逻辑,额外定义了两个抽象方法让子类去实现。其中,processCouponPrice方法用于计算商品折扣,processDeliveryPrice方法用于计算运费。
有抽象类,三个子类的实现就简单了。
既然三个购物车都叫XXXUserCart
,可将用户类型字符串拼接UserCart
构成购物车Bean的名称,然后利用IoC容器,通过Bean的名称直接获取到AbstractCart,调用其process方法即可实现通用。
这就是工厂模式,借助Spring容器实现:
若有新用户类型、用户逻辑,只要新增一个XXXUserCart类继承AbstractCart,实现特殊的优惠和运费处理逻辑即可。
工厂+模板方法模式,消除了重复代码,还避免修改既有代码。这就是设计模式中的开闭原则:对修改关闭,对扩展开放。
银行提供了一些API接口,对参数的序列化不使用JSON,而需要我们把参数依次拼在一起构成一个大字符串。
比如,创建用户方法和支付方法的定义是这样的:
直接根据接口定义实现填充、加签名、请求调用:
public class BankService {
// 创建用户
public static String createUser(String name, String identity, String mobile, int age) throws IOException {
StringBuilder stringBuilder = new StringBuilder();
// 字符串靠左,多余的地方填充_
stringBuilder.append(String.format("%-10s", name).replace(' ', '_'));
stringBuilder.append(String.format("%-18s", identity).replace(' ', '_'));
// 数字靠右,多余的地方用0填充
stringBuilder.append(String.format("%05d", age));
// 字符串靠左
stringBuilder.append(String.format("%-11s", mobile).replace(' ', '_'));
// MD5签名
stringBuilder.append(DigestUtils.md2Hex(stringBuilder.toString()));
return Request.Post("http://localhost:45678/reflection/bank/createUser")
.bodyString(stringBuilder.toString(), ContentType.APPLICATION_JSON)
.execute().returnContent().asString();
}
// 支付
public static String pay(long userId, BigDecimal amount) throws IOException {
StringBuilder stringBuilder = new StringBuilder();
// 数字靠右
stringBuilder.append(String.format("%020d", userId));
// 金额向下舍入2位到分,以分为单位,作为数字靠右,多余的地方用0填充
stringBuilder.append(String.format("%010d", amount.setScale(2, RoundingMode.DOWN).multiply(new BigDecimal("100")).longValue()));
// MD5签名
stringBuilder.append(DigestUtils.md2Hex(stringBuilder.toString()));
return Request.Post("http://localhost:45678/reflection/bank/pay")
.bodyString(stringBuilder.toString(), ContentType.APPLICATION_JSON)
.execute().returnContent().asString();
}
}
这段代码的重复粒度更细:
针对银行请求的所有逻辑均使用一套代码实现,不会出现任何重复。
要实现接口逻辑和逻辑实现的剥离,首先要以POJO类定义所有的接口参数。
@Data
public class CreateUserAPI {
private String name;
private String identity;
private String mobile;
private int age;
}
有了接口参数定义,就能通过自定义注解为接口和所有参数增加一些元数据。
再定义一个自定义注解@BankAPIField
,描述接口的每一个字段规范,包含参数的次序、类型和长度三个属性:
CreateUserAPI
类描述创建用户接口的信息,通过为接口增加@BankAPI注解,来补充接口的URL和描述等元数据;通过为每一个字段增加@BankAPIField注解,来补充参数的顺序、类型和长度等元数据:
通过这俩类,即可在几秒钟内完成和API清单表格的核对。若我们的核心翻译过程(即把注解和接口API序列化为请求需要的字符串的过程)没问题,只要注解和表格一致,API请求翻译就不会有问题。
通过注解实现了对API参数的描述。看反射如何配合注解实现动态的接口参数组装:
private static String remoteCall(AbstractAPI api) throws IOException {
// 从类上获得BankAPI注解,然后拿到其URL属性,后续进行远程调用
BankAPI bankAPI = api.getClass().getAnnotation(BankAPI.class);
bankAPI.url();
StringBuilder stringBuilder = new StringBuilder();
// 使用stream快速实现获取类中所有带BankAPIField注解的字段,并把字段按order属性排序,然后设置私有字段反射可访问。
Arrays.stream(api.getClass().getDeclaredFields()) //获得所有字段
//查找标记了注解的字段
.filter(field -> field.isAnnotationPresent(BankAPIField.class))
// 根据注解中的order对字段排序
.sorted(Comparator.comparingInt(a -> a.getAnnotation(BankAPIField.class).order()))
.peek(field -> field.setAccessible(true)) //设置可以访问私有字段
.forEach(field -> {
// 实现了反射获取注解的值,然后根据BankAPIField拿到的参数类型,按照三种标准进行格式化,将所有参数的格式化逻辑集中在了这一处
// 获得注解
BankAPIField bankAPIField = field.getAnnotation(BankAPIField.class);
Object value = "";
try {
// 反射获取字段值
value = field.get(api);
} catch (IllegalAccessException e) {
e.printStackTrace();
}
// 根据字段类型以正确的填充方式格式化字符串
switch (bankAPIField.type()) {
case "S": {
stringBuilder.append(String.format("%-" + bankAPIField.length() + "s", value.toString()).replace(' ', '_'));
break;
}
case "N": {
stringBuilder.append(String.format("%" + bankAPIField.length() + "s", value.toString()).replace(' ', '0'));
break;
}
case "M": {
if (!(value instanceof BigDecimal))
throw new RuntimeException(String.format("{} 的 {} 必须是BigDecimal", api, field));
stringBuilder.append(String.format("%0" + bankAPIField.length() + "d", ((BigDecimal) value).setScale(2, RoundingMode.DOWN).multiply(new BigDecimal("100")).longValue()));
break;
}
default:
break;
}
});
// 实现参数加签和请求调用
// 签名逻辑stringBuilder.append(DigestUtils.md2Hex(stringBuilder.toString()));
String param = stringBuilder.toString();
long begin = System.currentTimeMillis();
//发请求
String result = Request.Post("http://localhost:45678/reflection" + bankAPI.url())
.bodyString(param, ContentType.APPLICATION_JSON)
.execute().returnContent().asString();
log.info("调用银行API {} url:{} 参数:{} 耗时:{}ms", bankAPI.desc(), bankAPI.url(), param, System.currentTimeMillis() - begin);
return result;
}
所有处理参数排序、填充、加签、请求调用的核心逻辑,都汇聚在remoteCall
。有这方法,BankService中每一个接口的实现就非常简单了,只是参数的组装,然后调用remoteCall。
涉及类结构性的通用处理,都可按照该模式减少重复代码。
对于三层架构系统,层间解耦及每层对数据的不同需求,每层都会有自己的POJO实体。
手动写这些实体之间的赋值代码,容易出错。对于复杂业务系统,实体有几十甚至几百个属性也很正常。比如ComplicatedOrderDTO,描述一个订单中几十个属性。如果转换为一个类似的DO,复制其中大部分的字段,然后把数据入库,势必需要进行很多属性映射赋值操作。就像这样,密密麻麻的代码是不是已经让你头晕了?
ComplicatedOrderDTO orderDTO = new ComplicatedOrderDTO();
ComplicatedOrderDO orderDO = new ComplicatedOrderDO();
orderDO.setAcceptDate(orderDTO.getAcceptDate());
orderDO.setAddress(orderDTO.getAddress());
orderDO.setAddressId(orderDTO.getAddressId());
orderDO.setCancelable(orderDTO.isCancelable());
orderDO.setCommentable(orderDTO.isComplainable()); //属性错误
orderDO.setComplainable(orderDTO.isCommentable()); //属性错误
orderDO.setCancelable(orderDTO.isCancelable());
orderDO.setCouponAmount(orderDTO.getCouponAmount());
orderDO.setCouponId(orderDTO.getCouponId());
orderDO.setCreateDate(orderDTO.getCreateDate());
orderDO.setDirectCancelable(orderDTO.isDirectCancelable());
orderDO.setDeliverDate(orderDTO.getDeliverDate());
orderDO.setDeliverGroup(orderDTO.getDeliverGroup());
orderDO.setDeliverGroupOrderStatus(orderDTO.getDeliverGroupOrderStatus());
orderDO.setDeliverMethod(orderDTO.getDeliverMethod());
orderDO.setDeliverPrice(orderDTO.getDeliverPrice());
orderDO.setDeliveryManId(orderDTO.getDeliveryManId());
orderDO.setDeliveryManMobile(orderDO.getDeliveryManMobile()); //对象错误
orderDO.setDeliveryManName(orderDTO.getDeliveryManName());
orderDO.setDistance(orderDTO.getDistance());
orderDO.setExpectDate(orderDTO.getExpectDate());
orderDO.setFirstDeal(orderDTO.isFirstDeal());
orderDO.setHasPaid(orderDTO.isHasPaid());
orderDO.setHeadPic(orderDTO.getHeadPic());
orderDO.setLongitude(orderDTO.getLongitude());
orderDO.setLatitude(orderDTO.getLongitude()); //属性赋值错误
orderDO.setMerchantAddress(orderDTO.getMerchantAddress());
orderDO.setMerchantHeadPic(orderDTO.getMerchantHeadPic());
orderDO.setMerchantId(orderDTO.getMerchantId());
orderDO.setMerchantAddress(orderDTO.getMerchantAddress());
orderDO.setMerchantName(orderDTO.getMerchantName());
orderDO.setMerchantPhone(orderDTO.getMerchantPhone());
orderDO.setOrderNo(orderDTO.getOrderNo());
orderDO.setOutDate(orderDTO.getOutDate());
orderDO.setPayable(orderDTO.isPayable());
orderDO.setPaymentAmount(orderDTO.getPaymentAmount());
orderDO.setPaymentDate(orderDTO.getPaymentDate());
orderDO.setPaymentMethod(orderDTO.getPaymentMethod());
orderDO.setPaymentTimeLimit(orderDTO.getPaymentTimeLimit());
orderDO.setPhone(orderDTO.getPhone());
orderDO.setRefundable(orderDTO.isRefundable());
orderDO.setRemark(orderDTO.getRemark());
orderDO.setStatus(orderDTO.getStatus());
orderDO.setTotalQuantity(orderDTO.getTotalQuantity());
orderDO.setUpdateTime(orderDTO.getUpdateTime());
orderDO.setName(orderDTO.getName());
orderDO.setUid(orderDTO.getUid());
如果原始的DTO有100个字段,我们需要复制90个字段到DO中,保留10个不赋值,最后应该如何校验正确性呢?
使用类似BeanUtils
这种Mapping工具来做Bean的转换,copyProperties
方法还允许我们提供需要忽略的属性:
重复代码多了总有一天会出错。
代码重复度是评估一个项目质量的重要指标,如果一个项目几乎没有任何重复代码,那么它内部抽象一定非常好。重构时,首要任务是消除重复。
参考
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。