API：application programming interface，是Java自己提供的标准类库；
查API就是让你去看Java自己实现的函数，查看它怎样调用，要传什么参数等；
为什么要写我们的想法：自己不能记住，其他阅读的人更改程序的人也不知道。
与电脑沟通，先说服编译器你的程序是合理的 - 语法正确和类型正确。 然后让逻辑正确，以便在运行时提供正确的结果
与其他人沟通。 使程序易于理解，以便在有人修复，改进或未来适应时，他们可以这样做
规约给实施者自由地改变实现而不告诉客户端。通过对输入的限制说明，省略掉 一些耗时的检查工作，提升效率
合同充当客户和实施者之间的防火墙
它将客户从单位运作的细节中屏蔽掉
它使执行者免于单位使用的细节。 - 此防火墙导致解耦（解耦），允许单元的代码和客户端的代码独立更改，只要更改符合规范即可。
行为等价性
要确定行为等同性，问题是我们是否可以用另一个实现替代另一个实现（站在客户端视角看行为等价性） 这些方法不仅具有不同的代码，而且实际上具有不同的行为。 但是，当val恰好出现在数组的一个索引处时，这两个方法的行为相同
规范不应该谈论方法类的局部变量或方法类的私有字段
前置条件和后置条件
前置条件 requires表示 对客户端的约束，在使用方法时必须满足条件
后置条件 effects表示 对开发者的约束，在方法结束时必须满足的条件 契约：如果前置条件满足，则后置条件必须满足
如果在调用该方法时前置条件成立，则该方法完成后，后置条件必须成立。
如果在调用方法时前置条件不成立，则实现不受后置条件的限制。 它可以自由地做任何事情，包括不终止，抛出异常，返回任意结果，进行任意修改等。
Java的静态类型声明（也是一种规约）实际上是方法的前提条件和后置条件的一部分，该方法是编译器自动检查和执行的一部分。
方法前的注释也是规约但需要人工检查判定
@param 参数（前置条件）
@return @throws 返回结果（后置条件）
Java API文档是从Java标准库源代码中的Javadoc注释生成的
除非后置条件中声明过，否则方法内部不应改变输入参数
尽量不设计变化的spec很容易出现错误
除非有声明必须如此，否则不应改变输入参数
可变的对象使规约变得复杂，降低可变性，尽量少用
对同一个可变对象（对象的别名）的多次引用可能意味着程序中的多个地方 - 可能分隔很大 - 依靠该对象保持一致，需要程序维护一致性
此时合同不再是单纯的在客户和实现者之间维持，不再是在一个地方执行，需 要每一个引用者都有良好的行为
可变的对象使全局属性难于理解，难于确保程序正确性
我们仍然必须这样做 - 为了性能和便利性 - 但是为了这样做，我们在bug安全方面付出了巨大的代价
可变对象使得客户端和实现者之间的契约更加复杂，并且减少了客户端和实现者改变的自由（使用允许更改的对象会使代码难以改变）
测试验证规约
记录每个参数，返回值，每个异常（选中和未选中）方法执行的操作，包括目的，副作用，任何线程安全问题，任何性能问题
手动工作; 部分自动化; 不能自动确定
黑盒测试：以独立于实现的方式检查测试的程序是否遵循指定的规范。
比较规约：确定性 如何声明的 强度
确定性：给定一个满足前置条件的输入，输出是唯一的明确的 欠定的规约：一个输入有多个输出 非确定的规约：同一个输入多次执行得到的输出可能不同
S2>=S1强
S2的前提条件是弱于或等于S1的
对于满足S1前提条件的状态，S2的后置条件强于或等于S1。然后，满足S2的实现也可以用来满足S1，并且在程序中用S2代替S1是安全的。
削弱先决条件：减少对客户的要求永远不会让他们不高兴。 - 加强后置条件，这意味着做出更多承诺。
更强的规约表达更小的区域