说明：所谓I/F制约是指，方法为了提供特定的功能，对输入所期望的条件。

　　在调用方法时传入的参数值是否妥当?

　　在方法内部调用其他方法时，其返回值是否妥当?

　　如果不对这些值进行检查，就会导致Bug的产生。

　　如果是调用方法时的参数，那就一定要检查，参数的值是否在想定的范围之内，或者引用的对象会不会是null。

　　为了构筑健壮的系统，不能只考虑正常的输入情况，还必须实现对异常输入的响应。

　　那么，当输入没有满足I/F制约时，我们该怎么办呢?当输入没有满足I/F制约，发生了异常，那么这个异常是交给调用方去处理呢，还是在当前的方法里处理，这是一个设计的问题。有兴趣的读者可以去参阅参考文献。

　　另外，关于异常的详细情况，也希望参照该文章第5条。

　　例子：给HashMap赋值的add方法中的检查逻辑　

Public class ScoreBook { 　　pulic static final int MAX = 100; 　　private HashMap scoreBook; 　　public ScoreBook(){ 　　scoreBook = new HshMap(); 　　} 　　//add方法：将参数name和score赋值给HashMap;IIIegaIInputException，//AleadyAddedException是用户定义异常。 　　public void add(StriERROR name, int score) throws IIIegaIInputException,AleradyAddedException{ 　　//预期条件1：参数name满足name != null 　　//预期条件2：参数name不是空字符串 →检查上述条件是否满足，如果不满足，则//抛出异常交给调用方处理 　　if (name == null || name.trim().equals(“”)){ 　　throw new IIIegaIInputException(“姓名输入错误”); 　　} 　　//预期条件3：参数score满足0 <= score <= MAX →检查条件是否满足，如果不满//足，则抛出异常交给调用方处理 　　if (!(0 <= score && score < MAX)){ 　　throw new IIIegaIInputException(“分数输入错误”); 　　} 　　//预期条件4：参数name不能2重登录 →检查上述条件是否满足，如果不满足，则//抛出异常交给调用方处理 　　if (scoreBook.containsKey(name){ 　　throw new AoreadyAddedException(“输入值已经登录过了”); 　　} 　　scoreBook.put(name,score); 　　} 　　}

　　最后，面向某方法的输入不仅仅指这个方法的参数和这个方法调用其他方法时的返回值。方法中引用的实例变量，还有类变量都有可能成为方法的输入，也是需要检查的。

　　补充说明：

　　在考虑I/F制约的时候，必须了解以下的两种区别。

　　1. 产品交付后仍然可能需要检查的条件

　　本页下面的图中所显示的，来自于功能模块以外的输入情况。对运行时的异常输入必须加以检查。另外，从模块的复用来看，即使现在的模块构成中不可能发生的输入情况，将来也是有可能发生的。头脑中最好建立起这样的意识，从而主动地进行检查。

　　2. 为了使调试更加方便而希望检查的条件

　　可以使用从J2SE1.4开始提供的assert命令。Assert是从1.4版开始提供支持的，assert异常时产生AssertionError，强制停止程序运行，因此为调试提供了便利。但是，这里要注意，这种情况下不能对上面1所说的，也就是产品交付后也有可能需要检查的那些制约条件进行检查。Assert是用于调试的，产品交付时，Assert检查会被省略。

　　基于相同的理由，assert命令里一定不能包含可能产生副作用(#)的逻辑或公式。

　　#指可能使运行环境状态发生变化的作用。有代表的例子是变量的值发生变化，或是文件读写等。