一、程序设计语言中的函数和方法
参数类型、返回值类型是否匹配是在静态类型检查阶段完成的
“方法”是程序的“积木”，可以被独立开发、测试、复用
使用“方法”的客户端，无需了解方法内部具体如何工作—“抽象“
二、规约
规约中的东西是给自己和别人读，但不要包含具体的实现。
规约给程序员和客户都确定了响应的责任。
很多bug来自于双方之间的误解；不写下来，那么不同开发者的理解就可能不同；没有规约，难以定位错误。
精确的规约，有助于区分责任。客户端无需阅读调用函数的代码，只需理解spec即可。
注意规约是不需要了解具体实现的。
三、行为等价性
行为等价性是指对客户来说，最后的结果是否相同，不管其中的具体实现。
四、规约的结构（前置条件和后置条件）
规约包括前置条件和后置条件
前置条件是对客户端的约束，在使用方法是必须满足的条件
后置条件是对开发者的约束，即方法结束时必须满足的条件
如果前置条件满足了，后置条件必须满足；前置条件不满足后置条件可以做任何事
考：给你描述，判断规约的强弱，哪个最合理
面对错误，错误需要可控可调。
写规约的时候还可加上静态类型声明，可据此进行静态类型检查。
一定要注意我们不可以写上具体的实现，只可以出现接口或抽象数据类型。
一个方法的规范可以谈论方法的参数和返回值，但它永远不应该谈论方法的局部变量或方法类的私有字段。
除非在后置条件里声明过，否则方法内部不应该改变输入参数，尽量避免使用可变数据类型进行操作。
就规范而言，合同不能再仅在一个地方执行，例如 在类的客户和类的实现者之间。
对于可变的对象，复杂度会上升
五、设计规约
如果新规约的前置条件比旧规约的要弱，新规约的后置条件比旧规约的要强，则可以进行替换（前弱后强可替换原则）
前弱后弱 ,是不可⽐较的 (考试常出）
这个空间中的每个点代表一个方法实现
某个具体实现，若满足规约，则落在其范围内；否则，在其之外。
程序员可以在规约的范围内自由选择实现方式
客户端无需了解具体使用了哪个实现
更强的后置条件，更弱的前置条件意味着实现时要处理更多的可能输入，实现的自由度低了在图中的面积更小
六、如何设计一个好的规约
规约描述的功能应该单一、简单、易于理解
太弱的spec，client不放心、不敢用 (因为没有给出足够的承诺)。开发者应尽可能考虑各种特殊情况，在post-condition给出处理措施。
太强的spec，在很多特殊情况下难以达到，给开发者增加了实现的难度（client当然非常高兴）客户端不喜欢太强的precondition，不满足precondition的输入会导致失败。
惯用做法是：不限定太强的precondition，而是在postcondition中抛出异常：输入不合法
