抽象数据类型（ADT）和面向对象编程（OOP）3.2规约

Posted 2020-11-19 xgl122

API：application programming interface，是Java自己提供的标准类库；

          查API就是让你去看Java自己实现的函数，查看它怎样调用，要传什么参数等；

为什么要写我们的想法：自己不能记住，其他阅读的人更改程序的人也不知道。

与电脑沟通，先说服编译器你的程序是合理的 - 语法正确和类型正确。 然后让逻辑正确，以便在运行时提供正确的结果

与其他人沟通。 使程序易于理解，以便在有人修复，改进或未来适应时，他们可以这样做

规约给实施者自由地改变实现而不告诉客户端。通过对输入的限制说明，省略掉 一些耗时的检查工作，提升效率

合同充当客户和实施者之间的防火墙

它将客户从单位运作的细节中屏蔽掉
它使执行者免于单位使用的细节。 - 此防火墙导致解耦（解耦），允许单元的代码和客户端的代码独立更改，只要更改符合规范即可。

 

行为等价性

要确定行为等同性，问题是我们是否可以用另一个实现替代另一个实现（站在客户端视角看行为等价性）     这些方法不仅具有不同的代码，而且实际上具有不同的行为。 但是，当val恰好出现在数组的一个索引处时，这两个方法的行为相同

规范不应该谈论方法类的局部变量或方法类的私有字段

 

前置条件和后置条件

前置条件 requires表示  对客户端的约束，在使用方法时必须满足条件

后置条件 effects表示   对开发者的约束，在方法结束时必须满足的条件        契约：如果前置条件满足，则后置条件必须满足

如果在调用该方法时前置条件成立，则该方法完成后，后置条件必须成立。

如果在调用方法时前置条件不成立，则实现不受后置条件的限制。 它可以自由地做任何事情，包括不终止，抛出异常，返回任意结果，进行任意修改等。

Java的静态类型声明（也是一种规约）实际上是方法的前提条件和后置条件的一部分，该方法是编译器自动检查和执行的一部分。

方法前的注释也是规约但需要人工检查判定

@param  参数（前置条件）

@return  @throws  返回结果（后置条件）

Java API文档是从Java标准库源代码中的Javadoc注释生成的

除非后置条件中声明过，否则方法内部不应改变输入参数

尽量不设计变化的spec很容易出现错误

除非有声明必须如此，否则不应改变输入参数

可变的对象使规约变得复杂，降低可变性，尽量少用

 对同一个可变对象（对象的别名）的多次引用可能意味着程序中的多个地方 - 可能分隔很大 - 依靠该对象保持一致，需要程序维护一致性

此时合同不再是单纯的在客户和实现者之间维持，不再是在一个地方执行，需 要每一个引用者都有良好的行为

可变的对象使全局属性难于理解，难于确保程序正确性

我们仍然必须这样做 - 为了性能和便利性 - 但是为了这样做，我们在bug安全方面付出了巨大的代价

可变对象使得客户端和实现者之间的契约更加复杂，并且减少了客户端和实现者改变的自由（使用允许更改的对象会使代码难以改变）

测试验证规约

记录每个参数，返回值，每个异常（选中和未选中）方法执行的操作，包括目的，副作用，任何线程安全问题，任何性能问题