HIT软件构造期末复习3.2设计规约

HIT软件构造期末复习3.2

参数类型是否匹配，返回值是否匹配，都在静态类型检查阶段完成

代码中的“设计决策”：给编译器读
注释形式的“设计决策”：给自己和他人读

规约是程序与客户端之间达成的一致。
没有规约，就无法分派任务，无法写程序；即便写出来也不知道对错

• 规约可以隔离“变化”，无需通知客户端
• 规约可以提高代码效率

前置条件：对客户端的约束，在使用方法时必须满足的条件
后置条件：对开发者的约束，方法结束时必须满足的条件
契约：如果前置条件满足了，后置条件必须满足。
若前置条件不满足，则后置条件不用满足，方法可做任何事情

Specification:

• 静态类型声明是一种规约，可据此进行静态类型检查；
• 方法前的注释也是种规约，但需要人工判定是否满足
  @param表示前置条件
  @return/@throws表示后置条件
• 尽量避免使用mutable（可变）的对象

※行为等价性&观察等价性

用一个方法替换另一个方法，观察两个方法的行为是否等价，是否可相互替换

需要站在客户端（用户）视角来看行为等价性

根据规约判断行为是否等价，若两个函数符合同一个规约，则这两个函数等价

设计规约：

• 规约的确定性
• 规约的陈述性
• 规约的强度

※规约强度

规约强度S2>=S1，则S2的前置条件更弱（或相等） 并且S2的后置条件更强（或相等）（在满足S2后置条件上），在这种情况下可以用S2替代S1

spec变强：更放松的前置条件+更严格的后置条件

※当一个规约更强的时候，前置条件变松，有更多的客户端代码满足调用关系

确定的规约：给定一个满足precondition的输入，其输入是唯一的、明确的；
欠定的规约：同一个输入可以有多个输出（通常有具体的实现，实现之后输出的值确定）；
非确定的规约：同一个输入，多次执行时得到的输出可能不同

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

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

好的“方法”设计，不在于代码写的多好，而是对方法的spec设计的如何，client用的舒服，开发者也要用的舒服

规约的要求：

• 内聚的，描述的功能应单一、简单、易于理解
• 信息应是丰富完备的，不能让客户端产生歧义
• 规约应足够强
• 规约应足够弱
• 规约里使用抽象类型（如List、Set），可以给方法的实现体和客户端更大的自由度
• 是否使用前置条件取决于
  ①check的代价，②方法的使用范围。
  如果只在类的内部使用该方法(private)，那么可以不使用前置条件，在使用该方法的各个位置进行check——责任交给内部client；
  如果在其他地方使用该方法(public)，那么必须使用前置条件，若client端不满足则方法抛出异常