1700439962
1700439963
assert list.remove（element）：“删除元素”+element+“失败”；
1700439964
1700439965
/*业务处理*/
1700439966
1700439967
}
1700439968
1700439969
这段代码在assert启用的环境下，没有任何问题，但是一旦投入到生产环境，就不会启用断言了，而这个方法也就彻底完蛋了，list的删除动作永远都不会执行，所以也就永远不会报错或异常，因为根本就没有执行嘛！
1700439970
1700439971
以上两种情况下不能使用assert，那在什么情况下能够使用assert呢？一句话：按照正常执行逻辑不可能到达的代码区域可以放置assert。具体分为三种情况：
1700439972
1700439973
（1）在私有方法中放置assert作为输入参数的校验
1700439974
1700439975
在私有方法中可以放置assert校验输入参数，因为私有方法的使用者是作者自己，私有方法的调用者和被调用者之间是一种弱契约关系，或者说没有契约关系，其间的约束是依靠作者自己控制的，因此加上assert可以更好地预防自己犯错，或者无意的程序犯错。
1700439976
1700439977
（2）流程控制中不可能达到的区域
1700439978
1700439979
这类似于JUnit的fail方法，其标志性的意义就是：程序执行到这里就是错误的，例如：
1700439980
1700439981
public void doSomething（）{
1700439982
1700439983
int i=7；
1700439984
1700439985
while（i＞7）{
1700439986
1700439987
/*业务处理*/
1700439988
1700439989
}
1700439990
1700439991
assert false：“到达这里就表示错误”；
1700439992
1700439993
}
1700439994
1700439995
（3）建立程序探针
1700439996
1700439997
我们可能会在一段程序中定义两个变量，分别代表两个不同的业务含义，但是两者有固定的关系，例如var1=var2*2，那我们就可以在程序中到处设“桩”，断言这两者的关系，如果不满足即表明程序已经出现了异常，业务也就没有必要运行下去了。
1700439998
1700439999
1700440000
1700440001
1700440003
编写高质量代码：改善Java程序的151个建议 建议20：不要只替换一个类
1700440004
1700440005
我们经常在系统中定义一个常量接口（或常量类），以囊括系统中所涉及的常量，从而简化代码，方便开发，在很多的开源项目中已采用了类似的方法，比如在Struts2中，org.apache.struts2.StrutsConstants就是一个常量类，它定义了Struts框架中与配置有关的常量，而org.apache.struts2.StrutsStatics则是一个常量接口，其中定义了OGNL访问的关键字。
1700440006
1700440007
关于常量接口（类）我们来看一个例子，首先定义一个常量类：
1700440008
1700440009
public class Constant{
1700440010
1700440011
//定义人类寿命极限
[
上一页 ]
[ :1.700439962e+09 ]
[
下一页 ]