业务代码开发总结

1、参数校验

说明：每次开始编写一个service，首先要做的就是参数校验。各种不为NULL、不为空的代码随处可见，很不爽。所以我们要找一种方法，来简化这部分的业务无关代码。

1.1. Apache给我们提供了一个工具类可以满足我们的需求：org.apache.commons.lang3.Validate，提供了各种校验notBlank、notEmpty、notNull等，可以满足我们的一般需求。还可以自定义未通过校验的提示语。

try {
      long num = 40;
      Validate.exclusiveBetween(1, 10, num, "num参数不在1-10范围内");
}catch (Exception e){
      e.printStackTrace();
}

1.2. Guava的Preconditions也实现了类似的功能。

Preconditions.checkArgument(!(StringUtils.isEmpty(userName)
     || StringUtils.isEmpty(password)), "用户名或密码不能为空");

1.3. 实体类约束检查：Hibernate-validator

BeanValidators.validateWithException(validator, dto);

---

2、分支判断

说明：选择正确的判断语句会对性能有所提升。所以我们要合理的运用switch case、if else、while、for。

• 如果分支的条件判断都是等值判断，且值的范围较小，则应该使用switch case而不是if else。因为switch内部维护了一个路由表，不需要像if else那样挨个判断。但是如果判断是范围，则只能用if else来操作了。

• 双层for循环判断的情况：把内层for拿出来，转换成字典。

• 使用策略模式和多态去掉if/else、switch
  参考1
  参考2 利用设计模式替代项目中的if else
  注： if else 并不都适合用策略模式替代，只有每个分支足够复杂，且每个分支用不同方法做同一件事，才需要使用策略模式。

3、编译阶段做检查

改变编码方式，在编译阶段做错误检查，而不是等到运行阶段。
比如switch，如果参数拼写错误，会走default分支，导致不可预测的结果。但是如果参数改为enum类型，则编译阶段就会发现该错误，及时改正。

4、方法可见性

对共有方法进行判定，是否需要公布。

5、不断去发现更新工具类

不应该一直使用项目里一些老旧的工具类，应该不断的去发现探索新的好用的工具类，例如Apache Commons、Google Guava或者Joda Date。

6、静态导入使用

Eg: import static com.google.common.base.Preconditions.checkNotNull;
好处：减少代码的书写量；可读性高。
缺点：如果滥用，可读性会很差，代码中都是方法名，看不到类名，类是极具描述性的表示的。
所以，如果方法具有很好的表述性含义，则建议多用静态导入。对于枚举类，还是建议老老实实的书写。

7、避免脏数据

宁愿让程序出错、停止运行，也不要把一些错误的数据插入到数据库。正式的线上系统，数据的准确性是最重要的。操作前，一定要反复的进行数据检查。

第一步：基本判断约束(null值等基本判断)
第二步：实体属性约束(满足jsr 303等基础判断)
第三步：业务条件约束(需求提出的不同的业务约束)
第四步：处理业务逻辑

Eg: 下面贴出一段用户发表文章的示例代码：

  public ResponseEntity addArticle(Integer uid, Article article) {
    //参数数据检验
    // 1.用户id不能为空，且此用户存在
    Preconditions.checkNotNull(uid);
    User user = userDao.findOne(uid);if(null== user){
      throw new RuntimeException("找不到当前用户!");
    }
    // 2.文章的必要字段不能为空
    BeanValidators.validateWithException(validator, article);
    
    // 业务逻辑代码
    article.setUser(user);
    ResponseEntity ret = articleDao.save(article);
    return ret;
  }

---

后面会抽时间不定期补充