3.2设计规约

• 方法的规约
• 前置/后置条件
• 欠定规约、非确定规约
• 陈述式、操作式规约
• 规约的强度及其比较
• 如何写出好的规约

编程语言中的功能&方法

规约：Programming for communication

(1)Document in programming

(2)Specification and Contract(of a Method)

规约可以隔离“变化”，无需通知客户端
规约也可以提高代码效率
规约:扮演“防火墙”角色
实现了解耦，（不需要了解具体实现）

Behavioral equivalence(行为等价性）

站在客户端视角看行为等价性
根据规约判断是否行为等价
若函数符合规约，则等价

Specification(规约)结构：前置条件和后置条件

• 前置条件：对客户端的约束，在使用方法时必须满足的条件；

• Postcondition(后置条件):对开发者的约束，方法结束时必须满足的条件；

• 契约：如果前置条件满足了，后置条件必须满足；

• 前置条件满足，则后置条件必须满足。

• 前置条件不满足，则方法可做任何事情。
  
  
  可变方法的规约

• 除非在后置条件里声明过，否则方法内部不应该改变输入参数。
• 应尽量遵循此规则，尽量不设计mutating的spec,否则容易引发bugs;
• 尽量避免使用mutable的对象；

规约分类

• 确定性
• 陈述性
• 强度
  如果前置条件更弱，后置条件更强，规约的强度更高；

操作式规约：如伪代码；
声明式规约：没有内部实现的描述，只有“初-终”状态；
声明式规约更有价值；内部实现的细节步不在规约里呈现，放在代码实现体内部注释中呈现；

如何设计一个好的规约

• 规约应该是内聚（coherent）的：

• 规约应该是信息丰富的
  
• 规约应该是足够强的
  
• 规约也应该是适当弱的
  
• 规约应该使用抽象类型
  
• 前置条件 or 后置条件？

如果代码内部check会使方法运行太慢，那么前置条件是必要的

不写Precondition，就要在代码内部check；若代价太大，在规约里加入precondition，把责任交给client

惯用做法是：
不限定太强的precondition，而是在postcondition中抛出异常：输入不合法