第五章 设计规约

第五章 设计规约

Reading Source

Objectives

理解方法的规约

理解规约的前置，后置条件

欠定规约，非确定规约

规约的强度及其比较

懂得如何写出好的规约

编程语言中的函数和方法

参数：参数类型的匹配的检查在静态检查阶段

返回值：返回值的匹配的检查在静态检查阶段

方法：Blocks individually abstraction

规约:Programing for communication

Documenting assumption#

写出假设：变量的数据类型定义 final关键字定义

why:assumptions?
自己能记住 别人也能看懂
Programs的两个目的：给人读 给编译器读

Specification and Contract#

delegate responsibility for implementing a method

一种契约：
– States method’s and caller’s responsibilities
– Defines what it means for implementation to be correct

给供需双方都确立了责任

实例：

规约的作用：
规约可以隔离“变化”，无需通知客户端

规约也可以提高代码效率

规约：扮演“防火墙”角色

firewall-->decoupling(解耦：不需了解具体实现)

规约说什么：
输入输出的数据类型
功能和正确性
性能

What the method does, not how it does it

行为等价性#

站在客户端的角度-->根据规约 判断是否行为等价

规约的结构：前置条件和后置条件#

组成：

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

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

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

前置条件不满足，方法可以做任何事

Java中的规约#

静态类型声明：由编译器自动检查和强制执行的

方法前的注释

What a specification may talk about#

A specification of a method can talk about the parameters and return value of the method, but it should never talk about local variables of
the method or private fields of the method’s class.

Specifications for mutating methods#

设计规约

规约的分类#

比较：确定性 陈述性 强度

Sronger vs Weaker
问题：如何比 较两个规约，以判断是否可以用一个规约替换另一个？
-->规约的强度S2>=S1,就可以用S2替代S1

问题：如何比较规约的强度？
-->前置条件更弱，后置条件更强

注：存在无法比较规约强度的规约
注：越强的规约，意味着implementor的自由度和责任越重，而client的 责任越轻。

图表表示规约#

问题：如何表示？
-->
1.空间中的每个点代表一种方法实现
2.规约定义了一个包含所有可能实现的空间
3.某个具体实现， 若满足规约，则落在其范围内；否则，在其之外。

程序员可以在 规约的范围内自由选择实现方式
客户端无需 了解具体使用了哪个实现

表示规约的强弱
更强的后置 条件意味着实现的自由度更低了-

在图中的面积更小
更弱的前置条件意味着 实现时要处理更多的可能输入，
实现的自由度低了->面积更小
-->更强的规约，表达为更小的区域

设计好的规约#

Useful guidelines:
1.Coherent(内聚的)
功能应单一，简单，易理解

2.Strong enough

3.Weak enough

4.Use abstract tyoes:更高的自由度

5.前置条件
是否使用前置条件？或者check()?

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

归纳

总结

规约的意义

设计原则