软件构造笔记 3.2 Designing Specification

1.函数与方法

参数类型和返回类型匹配在静态检查阶段完成。

“方法”是程序的“积木”，可以被独立开发、测试、复用；

 使用“方法”的客户端，无需了解方法内部具体如何工作——“抽象”。

2.方法的规约

需要规约的原因：很多bug来自于双方的误解；不写清楚规约，不同开发者的理解会不同；没有规约难以定位错误。

规约的优点：精确的规划，有助于区分责任；客户端无需阅读调用函数的代码，只需阅读spec。

规约可以隔离“变化”，无需通知客户端；扮演防火墙的角色。

3.行为等价性

行为等价性的关键是确定两个实现间是否可以相互替换，需要站在客户端的角度看待。具体可以通过规约来判断，若两个函数符合一致的规约，那么它们是等价的。

4.前置/后置条件

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

后置条件:对开发者的约束，方法结束时必须满足的条件。

契约:如果前置条件满足了，后置条件必须满足。

前置条件不满足， 那么方法可以做任何事情，“你违约在先，我自然不遵守承诺”。

静态类型声明是一种规约，可据此进行静态类型检查static checking。方法前的注释也是一种规约，但需人工判定其是否满足。

注意：

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

应尽量遵循此规则，尽量不设计 mutating的spec，否则就容易引发bugs。

程序员之间应达成的默契:除非spec必须如此，否则不 应修改输入参数。

尽量避免使用mutable的对象。

避免使用可变的全局变量!但是为了性能原因，有时候却不得不用，这对程序的安全性造成了巨大破坏。

5.欠定规约、非确定规约

确定的规约:给定一个满足precondition的输入，其输出是唯一的、明确的。

欠缺的规约：同一个输入可能有多个输出。

非确定的规约：同一个输入，多次执行时得到的结果可能不同。

6.陈述式、操作式规约

操作式规约，例如伪代码。

声明式规约：没有内部实现的描述，只有“初-终”状态。声明式规约更有价值。

7.规约的强度及其比较

当判断两个规约间的替换关系时，引入规约的强度：若S2的前置条件更弱且后置条件更强，那么S2的强度更强，可以用S2替代S1。

8.图像规约（Diagramingspecification）

对于一个实现，若满足规约则落在范围内，否则在范围外。程序员可以在规约的范围内自由选择实现方式，客户端无需了解使用了哪个实现。

更弱的前置条件意味着实现时要处理的输入更多，更强的后置条件意味着实现的自由度更低，都会使得面积减小。更强的规约表示为更小的区域。

9.设计好的规约

1）spec描述的功能应单一、简单、易理解。

2）不能让客户端产生理解的歧义。

3）具有强度，即为客户端强有力的保证。

4）在不能完全保证功能时需要足够弱。

5）在规约里面使用抽象类型，可以给方法的实现体与客户端更大的自由度。

6）注意前置条件和后置条件。不写前置条件，那么就需要在代码内部check，但客户端也不喜欢太强的前置条件。惯用做法是不限定太强的前置条件，而是在后置条件中抛出异常，尽可能的在错误的根源处fail，避免大规模扩散。

是否使用前置条件取决于方法的使用范围；check的代价;

如果只在类的内部使用该方法(private)，那么可以不使用前置条件，在使用该方法的各个位置进行check，责任交给内部client。

如果在其他地方使用该方法(public)，那么必须要使用前置条件，若client端不满足则方法抛出异常。