SPEC

Designing Specification
Methods: Building Blocks
方法的用户不需要知道方法是如何工作的—称 之为抽象

Java API documentation
API：Application Programming Interface,应用程序编程接口

Documenting Assumptions
定义变量 时声明其类型是一种文档约定(编译器会进行检查以确保正确性
声明变量是final类型的也是一种文档约定

Specifications (or called Contract)
规格说明是团队开发的关键，是分配责任的基础
规格说明是实现者和使用者之间的一种契约，实现者有责 任满足契约，使用者可以信赖契约

Why specifications?
·对两部分代码接口处行为的错误理解
·不是所有实现者把规格说明文档化
·规格说明没有文档化，出错时难以定位问题

优点：
1.准确的规格说明利于确定错误的位置和责任
2.客户端不需要阅读代码，通过说明了解程序

Specification structure: pre-condition and post-condition
– Precondition , 由关键词require表示
– Postcondition , 由关键词 effects 表示
– Exceptional behavior异常行为: 1.前提条件是义务(义务)客户端 2.后置条件是方法实现者的义务

逻辑蕴涵：
·规格说明蕴含了以下逻辑：如果 前置条件满足了，则后置条件必须满足
·反之，如果前置条件不满足，后置条件 则无需满足

Specifications in Java
·前置和后置条件中对类型的声明，将 由编译器进行检查，确保正确性
·其余部分通过注释的形式进行描述，由人来保证正确性

Stronger vs. weaker specs
如何比较 两个规格说明的行为，以决定是否可以进行替换？
要求更少，承诺更多，则spec强度越大
加强后置条件 ，意味着对输出要求更多，实现自由变少
弱化前置条件，实现中 需要处理更多的情况
上述两点使可满足的实现变少(点变少)，故规格说明越强，区域越小

无法比较的情况
如果S3既不比S1强也不比S1弱，那么就需要说明。可能会重叠(这样就存在只满足S1、S3和S1和S3的实现)，或者是不相交的。在这两种情况下，S1和S3都是不可比拟的

Diagramming specifications
每个 点代表一个实现

一个规格说明定义了一个区域，其中包含的点为其 实现
一个实现或者满 足规格说明(区域内)，或者不满足(区域外)

Precondition or postcondition?
Java API类倾向 于采用后置条件的方式处理，当参数不合适时它们会抛出未检查异常
找到由传递的错误参数引起的bug 更加容易
快速失败是好的决策，使失败点离bug尽可能的近，易于定位

选择前置或后置的关键因素是检 查的代价以及方法的作用范围。
·如仅在类的内部调用，则可以通过仔细检查调用该方法的所有位置来确 保前提条件的满足
·如果是public的方法，则适宜采用后置条件(抛出异常)