前置条件断言

标签：表示   开发   als   禁用   异常   obj   断言   含义   规范   

断言（assert），是编程术语，表示为一些布尔表达式，程序员相信在程序中的某个特定点该表达式值为真，可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言而在部署时禁用断言。

断言的使用通常在单元测试中，使用断言可以创建更稳定，品质更好且不易于出错的代码。

2、断言特性：

前置条件断言：代码执行之前必须具备的特性

后置条件断言：代码执行之后必须具备的特性

前后不变断言：代码执行前后不能变化的特性

3、前置条件断言

程序的业务逻辑处理,一般是有必须满足的条件,才能进行对应的处理,否则就不能正确的执行。

而代码开发中，如果不在业务处理前，对其所需的条件进行判定，则在后续中，就会出现各种隐患。

在PRD中，对于业务逻辑，也是有一定满足条件才能执行的。

在敏捷开发中，TDD是其一项核心实践。

在测试用例中，对于测试场景来说，也是应有前置条件的约束的。

那么，综上所诉，是不是在写业务功能之前，进行断言判断呢？

答案是肯定的，进行前置条件断言，不仅符合业务实际，也对代码规范进行了约束，同时，也会避免大量的不必要的隐患。

在项目中，我们通过在应用接口层进行对外交互。那么对应的，条件断言，也应在这里进行。

我们假设，进行断言，如果不通过，则抛异常码，并且显示在返回结果中。
那么，首先，应定义全局异常码，在项目中，每个码都应唯一并且有确定的含义。

在全局异常码，可以根据业务，进一步分为错误码，转向提示码。

错误码，很容易理解，他的信息可以由用户或上游调用方显示看到。

转向提示码，则是需要根据码，可以进行一些对应业务处理，比如，用户登录信息session超时，可以使用转向提示码，通知上游，直接转向登录页面。

4、断言执行流程

接下来，我们可以简单的尝试一下做个断言工具类 AssertUtils。

public class AssertUtils {
?
  /**
   * check if source is equals target.<p>
   * if source == null && target == null,will not throws Exception
   * @param code
   * @param source
   * @param target
   */
  public static void eq(int code,Object source,Object target)  {

    boolean eq = false;

    eq = source == null ? target == null ? true : false : target == null ? false :           source.equals(target) ;

    if(!eq)
      ExceptionUtils.throwSimpleEx(code);
  } }  

ExceptionUtils是自定义异常Utils，里面对异常进行了封装，并且对code进行了配置注册。
在使用上，我们可以这样来使用：

int a1 = 12;
Integer a2 = 123;
AssertUtils.eq(1401,a1,a2);

就对a1和a2进行了相等的断言，不符合，则抛出1401的异常码。

来源：宜信技术学院，weiwei

前置条件断言

标签：表示   开发   als   禁用   异常   obj   断言   含义   规范   

原文地址：https://blog.51cto.com/14159827/2524612