【思维导图】HIT软件构造Java笔记——第五章设计规约

(在app上图片看不清的话可以复制链接到浏览器里，就可以看清了，电脑端也可以看清）
尝试根据上课的PPT整理出了一份不是很全的思维导图，省略了一些东西，如果有不对的地方或者困惑的地方请多多指正。下附xmind导出大纲，希望能对大家的学习有所帮助.

规约Specification

编程中的文字描述（假设）

Java API描述

为什么要写assumptions-设计决策

• 帮助自己和别人理解代码

Specification and Contract

必要性

• 没规约没办法分派任务/判断程序对错

  • linchpin of teamwork

• 程序与client达成的一致

• Spec给供需双方明确责任

  • 需要双方遵守

重要性

• 帮助不同开发者产生相同的understanding

  • 减少bug的产生

• 帮助开发者定位错误

• 精确的规约可以帮助区分责任

• client不需要阅读被调用函数的代码

  • 只需要理解Spec

规约的功能

• 规约可以隔离“变化”

  • 无需通知客户端

• like a firewall

  • 实现者不需要写代码确保输入的正确性

    • 来自调用者的责任

  • 实现了client和implementor解耦

    • 实现者不需要了解如何被使用
    • 使用者不需要了解如何实现

规约的格式

行为等价性

• 站在客户端视角看行为等价性

  • 是否可相互替换
  • 根据规约判断行为是否等价

• 需要根据代码的spec

编程语言中的功能和方法

方法是程序的积木

• 可以被独立的开发/测试。复用
• 客户端不需要了解方法内部具体如何工作

完整的方法

• 方法的规约specification

  • @param
  • @return

• 方法的实现体implementation

规约内容和结构

前置条件

• 对客户端的约束

  • 使用方法时必须满足的条件

后置条件

• 对开发者的约束

  • 方法结束时必须满足的条件

契约

• 前置条件满足–则后置条件必须被满足

设计规约

• 规约的分类

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

• 规约强度比较

  • 规约S2>=S1

    • 前置条件更弱或相等
    • 后置条件更强或相等

notes

• 能与不能

  • 参数和返回值

    • yes

  • 永远不能谈论私有函数与变量/本地or局部变量

• 可变方法规约

  • 除非在后置条件中声明过

    • 否则方法内部不应该改变输入参数

  • 应尽量遵循次规则，尽量不设计mutating的spec

    • 否则就容易引发bugs

  • 程序员之间应达成的默契：除非必须如此

    • 否则不应修改输入参数

图表规范

note

• 程序员可以在规约的范围内自由选择实现方式
• client无需了解具体使用了哪个实现
• 更强的后置条件——实现的自由度更低了
• 更弱的前置条件——处理更多的输入

一个良好的规约

与代码好坏无关

• 对该方法的设计

  • 便于client使用
  • 便于开发者编写

内聚的

• 描述的功能单一简单易理解

信息丰富的

• 不能让client产生理解的歧义

健壮性

• 尽可能考虑各种特殊情况

适当的弱

• 不要增加不必要的spec

  • 增加开发者的难度

使用抽象类型

• 方法实现体和client的更大自由度

前置与后置条件

- 衡量标准