软件构造感想4

设计规约

编程语言中的函数和方法

参数类型是否匹配与返回值类型是否匹配是在静态类型检查阶段完成
这里需要注意的是：大程序是用小方法构建的，且方法可以单独开发，测试和重用，但是方法的用户不需要知道它是如何工作的

规约

编程记录

写下我们的假设是必要的：

• 自己有可能记不住，以及其他需要阅读或更改的人及
  程序以后将不会知道它们的作用

并且要保证程序语法正确且类型正确以及使逻辑正确，以便在运行时给出正确的结果。 即我们的代码需要给编译器读
我们还需要使程序易于了解，以便当有人必须对其进行修复，改进或使其适应未来时，他们可以这样做。

规约和合同

规约对方法的实现者有益，因为他们赋予实施者更改实施的自由却不告诉客户。
规范可以使代码更快并提高代码效率
规约扮演“防火墙”角色

• 保护客户免受工作细节的影响
• 屏蔽了实施者的细节单位的使用情况。
• 此防火墙导致用户不需了解具体实现，从而允许代码
  单元的代码和要更改的客户代码只要变化尊重规约即可

规约相当于对象与其用户之间的协议，即输入/输出的数据类型、功能和正确性与性能。且规约只讲能做什么，不讲怎么实现

行为对等

单纯的看实现代码，并不足以判定不同的implmentation是否是“行为等价的”，需要根据代码的spec（开发者与client之间形成的contract）判定行为等价性，在编写代码之前，需要弄清楚spec如何协商形成、如何撰写

规格结构：前置条件和后置条件

前置条件：对客户端的约束，在使用方法时必须满足的条件
后置条件：对开发者的约束，方法结束时必须满足的条件
注意：

1. 如果前置条件满足了，后置条件必须满足
2. 前置条件不满足，则方法可做任何事情。
3. 静态类型声明是一种规约，可据此进行静态类型检查static checking。
4. 方法前的注释也是一种规约，但需人工判定其是否满足

方法的规约可以讨论参数并返回方法的值，但永远不要谈论方法的局部变量、方法或方法类的私有字段，即应该认为规范的读者看不见该实现。
除非在后置条件里声明过，否则方法内部不应该改变输入参数
应尽量不设计mutating的spec，否则就容易引发bugs。
除非spec必须如此，否则不应修改输入参数
所以，尽量避免使用mutable的对象

设计规约

规约的分类

规约的正确性、陈述性与强度
规约的强度S2>=S1：S2的前置条件更弱且后置条件更强，这样我们可以用S2代替S1
规格较高的前提条件可能较弱，并且/或者后置条件更强。在这两种情况下，实施者都必须更加小心； 越强的规约，意味着implementor的自由度和责任越重，而client的责任越轻。

图表规约

某个具体实现，若满足规约，则落在其范围内；否则，在其之外。
更强的规约，表达为更小的区域：因为更强的后置条件意味着实现的自由度更低了，更弱的前置条件意味着实现时要处理更多的可能输入，实现的自由度低了

设计好规约

一个好的“方法”设计，并不是你的代码写的多么好，而是你对该方法的spec设计得如何。 一方面让client用着舒服， 另一方面让开发者编着舒服
Spec描述的功能应单一、简单、易理解且不能让客户端产生理解的歧义
该规约应在一般情况下为客户提供足够有力的保证-它需要满足他们的基本要求。在指定特殊情况时，我们必须格外小心，以确保它们不会破坏原本有用的方法。（例如，没有理由为错误的论据抛出异常，而是允许任意突变，因为客户将无法确定实际进行了哪些突变。）
太弱的spec，client不放心、不敢用 (因为没有给出足够的承诺)，太强的spec，在很多特殊情况下难以达到，给开发者增加了实现的难度。我们需要平衡二者，其衡量标准就是检查参数合法性的代价有多大
在规约里使用抽象类型，可以给方法的实现体与客户端更大的自由度

总结

规范充当过程的实现者及其客户端之间的重要防火墙。这使单独开发成为可能：客户端可以自由编写使用该过程的代码而无需查看其源代码，而实现者可以自由编写用于实现该过程的代码而无需知道其用法。
其中声明性规范在实践中最有用，前提条件（削弱了规范）使客户的生活更艰难，但明智地应用这些前提条件是软件设计人员必不可少的工具，允许实现者进行必要的假设。
并且规约可以让我们防止错误、易于理解、随时准备改变