（五）改掉这些坏习惯，还怕写不出精简的代码？（转载）

zhongqill

于 2020-07-30 13:35:47 发布

阅读量134

点赞数

原文链接：https://blog.csdn.net/javaforwork/article/details/106774467?utm_medium=distribute.pc_feed.none-task-blog-alirecmd-4.nonecase&depth_1-utm_source=distribute.pc_feed.none-task-blog-alirecmd-4.nonecase&request_id=

版权

鲁迅说：嬉笑怒骂里充满了无奈和妥协。

小猿说：先生说的不对，在程序员的世界里，编写代码处处充满了无奈和妥协。

Code Review 是一场苦涩但有意思的修行。

（一）改掉这些坏习惯，还怕写不出健壮的代码？

（二）改掉这些坏习惯，还怕写不出优雅的代码？

（三）改掉这些坏习惯，还怕写不出优雅的代码？

（四）改掉这些坏习惯，还怕写不出健壮的代码？

代码修炼的系列分享，书接上篇，本次探讨一下：该如何利用注解写出精简的代码？

编码时：重复的校验，随处可见。
举个栗子：

再举个栗子：

如栗子示意，项目中参数校验随处可见，面对如此简单而又繁琐的工作量，你有何高见？

小猿招式一：七夕，带你生撸一个验证框架

小猿招式二：API参数如何验证？别纠结，拿去用就是

招式一不多说，徒手造轮子而已；重点说说招式二，引用 Hibernate Validator 类库替换参数校验，如下图示意，只需通过注解就轻松实现参数的基本验证。

建议：参数校验直接引用三方的类库实现，例如引用 Hibernate Validator，能让业务代码简化不少，代码 B 格略有提升。

敢问，你会用注解吗？注解还能怎么用？

莫急，容我慢慢讲来。

编码时：注解还可以这么用。
举个栗子：

系统要根据上面常量类中的商户号来判断：是否需要进行校验账户信息、是否需要进行通知商户 … …

实现方式有很多种，看看项目中采用注解怎么实现的。

首先定义 PayAccInfoValidator 注解，用来标注是否需要校验账户信息。

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface PayAccInfoValidator {

boolean verify() default true;

}
然后在商户号属性上加入注解标识。

采用反射+注解，编写验证工具类，主要关注代码中的关注点一、关注点二。

import java.lang.reflect.Field;
import java.util.HashMap;
import java.util.Map;

public class BusinessUtil {

private static final MerIdConstant MERID_CONSTANT = new MerIdConstant();


/**
 * 存放要验证支付账户信息的商户号
 */
public static final Map<String, Boolean> VERIFY_MERID_MAP = new HashMap<String, Boolean>();


static {
    Class<?> clazz = MERID_CONSTANT.getClass();
    for (Field field : clazz.getFields()) {
        // 关注点一
        PayAccInfoValidator validator = field.getAnnotation(PayAccInfoValidator.class);
        if (validator != null) {
            try {
                // 关注点二
                VERIFY_MERID_MAP.put(field.get(MERID_CONSTANT).toString(), validator.verify());
            } catch (IllegalAccessException e) {
            }
        }
    }
}

}
代码不做详细解释，工具类用起来很简单，简易示例如下。

程序输出：

20020：需要进行验证
另外，校验是否需要通知商户该怎么实现呢？其实套路是一样的，照葫芦画瓢而已，拿去先用起来体会体会。