软件构造 复习总结（第三章）
数据类型
| Primitive types 基本数据类型（8种） | Object types 对象数据类型（reference types 引用数据类型） |
|---|---|
| Short、int 、long、float、double、boolean、char、byte | 如：String、BigInteger |
| 只有值，没有ID（无法与其他值区分），不能赋值为null；immutable | 有值，也有ID；部分mutable，部分immutable |
| 在栈中分配内存，代价低 | 在堆中分配内存，代价高 |
静态类型检查&动态类型检查
| 静态类型检查 | 动态类型检查 |
|---|---|
| （静态类型语言 如java） 提高程序的正确性和健壮性 | （动态类型语言 如python） |
| 关于"类型"的检查，不考虑值（不知道运行时会是什么值） | 关于"值"的检查 |
Mutable & Immutable
| Immutable 不可变数据类型 | mutable 可变数据类型 | |
|---|---|---|
| 优点 | 安全 | 最少化拷贝以提高效率获得更好的性能，适合于在多个模块之间共享数据 |
| 缺点 | 频繁修改产生大量临时拷贝，需要垃圾回收· | 缺点：不安全 |
| 特点 | 一旦被创建，其值不能改变对于引用类型，加final限制不能改变引用 | 安全地使用可变类型：局部变量（不涉及共享，且只有一个引用）如果有多个引用（别名），不安全 Defensively copy 防御式拷贝：返回全新的对象 |
关于Java中的Mutable 和 Immutable类型
Snapshot Diagram
基本类型：单独一个常量
引用类型：圈住！
重分配：
不可变类型（用双线椭圆），修改引用
可变类型：修改值
引用：
可变引用：单线箭头
不可变引用：双线箭头
Specification
1.作用
- 规约可以隔离"变化"，无需通知客户端
- 规约可以提高代码效率
- 规约扮演"防火墙"角色
- 解耦，不需要了解具体实现
2.内容：只讲"能做什么"，而不讲"怎么实现"
3.Behavior equivalence 行为等价性
是否可以相互替换
- 站在客户端的视角看行为等价性，不同的行为，对用户来说（根据用户需求）可能等价！
- 根据规约判断行为等价，两个方法符合同一个规约，则等价。
4.规约的结构：
- Pre-condition
- Post-condition
- Exceptional behavior 异常行为，如果违背了前置条件，会发生什么
5.规约的强度与替换
- Spec变强：更放松的前置条件（前置条件更弱）+更严格的后置条件（后置条件你更强），两条件同时变强或变弱则无法比较。
若规约强度S2>=S1，则可以用S2替换S1。
6.deterministic spec & undetermined spec 确定的规约和欠定的规约
- 确定的规约：给定一个满足前置条件的输入，其输出唯一、明确
- 欠定的规约：同一个输入可以有多个输出（多次执行输出可能不同）
7.Declarative spec & operational spec 声明式规约和操作式规约
-
操作式规约：如 伪代码
-
声明式规约：没有内部实现的描述，只有"初-终"状态
声明式规约更有价值！ -
内部实现的细节不在规约里呈现，而放在代码实现体内部注释里呈现。
8.Diagraming specification
-
规约定义一个区域，该区域包含所有可能的实现方式。
-
空间中的每个点表示一种方法的实现。
-
对于某个具体实现，若满足规约，则落在其区域内。更强的规约表达为更小的区域。
9.Quality of specification 规约质量 -
内聚性：spec描述的功能应单一、简单、易理解
-
运行结果信息丰富（可能的改变，以及返回值等），不能让客户端产生理解上的歧义
-
足够强（如postcondition中充分阐述各种情况）
-
适当弱（太强的规约，在很多特殊情况下难以达到）
-
在规约里使用抽象类型（在java中，经常使用interface，如Map、List，而不是HashMap、ArrayList），可以给方法的实现体和客户端更大的自由度
-
使用前置条件和后置条件？
客户端不喜欢太强的pre-condition，不满足precondition的输入会导致失败
So：不限定太强的precondition，而在postcondition中抛出异常：输入不合法，
fail fast，避免fail大规模扩散是否使用前置条件取决于：
-
check（检查参数合法性）的代价
-
方法的使用范围：
- 如果只在类内部使用（private），则可以不使用precondition，在使用该方法的各个位置进行check
- 如果在其他地方使用（public），则必须使用precondition，若client不满足则抛出异常
Pre-condition and post-condition 前置条件和后置条件
| Pre-condition 前置条件（requires） | Post-condition 后置条件（effects） |
|---|---|
| @param | @return @throws |
| 对客户端的约束。在使用方法时必须满足的条件 | 对开发者的约束。方法结束时必须满足的条件 |
-
契约：如果前置条件满足了，后置条件必须满足。
-
除非在后置条件中声明，否则方法内部不应该改变输入参数。
-
尽量不设计mutating的spec，否则容易引发bugs。
-
尽量避免使用mutable对象。
-
避免使用可变的全局变量。
ADT
1.ADT及其四种操作
抽象类型：强调"作用于数据上的操作"，程序员和client无需关心数据如何具体存储，只需设计/使用操作即可。
ADT由操作定义，与其内部实现无关。
可变数据类型：提供了可改变其内部数据值的操作；
不可变数据类型：其操作不改变内部值，而构造新的对象。（没有mutators）
ADT操作分类：
- Creators 构造器：
不利用该类型对象产生一个新的对象
可能实现为构造函数或静态函数（factory method） - Producers 生产器：
用已有该类型对象产生新对象
如string.concat()（连接两个字符串，产生一个新的字符串） - Observers 观察器
如list.size()返回int（不同于原类型） - Mutators 变值器（改变对象属性的方法）
通常范围void，如果返回void，则必然意味着它改变了某些对象的内部状态
也可能范围非空类型（如容器类的put、add方法）
Representation Independence 表示独立性
- 表示独立性：client使用ADT时无需考虑其内部如何实现，ADT内部表现的变化不应该影响外部spec和客户端。
Representation exposure 表示泄漏
- 如client能直接接触类成员变量。
- 表示泄漏影响表示不变量，也影响表示独立性：无法在不影响客户端的情况下改变其内部表示。
- 避免方法：private、final、defensive copy
Invariants 不变量 & Representation Invariant 表示不变量
- ADT应保持其不变量在任何时候总是true；
- ADT负责其不变量，与client的任何行为无关。
- 作用：保持程序的"正确性"，容易发现错误。
Abstraction Function 抽象函数
| 表示空间R | 抽象空间A |
|---|---|
| 值的实际实现本质 | 抽象表示（client看到和使用的值） |
| ADT实现者关注表示空间R | 用户关注抽象空间A |
R到A的映射
一定是满射：A中元素总有R中具体的实现
未必是单射：A中一个元素在R中可能有多重实现方式
未必是双射：R中表示不符合A中需求（如图中"abbc"）
抽象函数AF：R和A之间映射关系的函数
AF：R->A
对于RI ：R-> Boolean
RI：某个具体的"表示"是否合法；表示值的一个子集，包含所有合法的表示值；一个条件，描述了什么是"合法"表示值。
Documenting AF 、RI、Safety from Rep Exposure
选择某种特定的表示方式R
进而指定某个子集是"合法"的（RI）
并为该子集中的每个值做出"解释"（AF）
即如何映射
Safety from Rep Exposure
证明代码并未对外泄露其内部表示
保证不变量为true，不变量：
- 通过creators和producers创建
- 受mutators和observers保护
- 无表示泄漏发生
关于ADT的学习总结
OOP
Interface 接口
- 接口的成员变量默认用final关键字修饰，故必须有初值，可用public，default修饰，可用static修饰。
- 接口的方法只能被public、default、abstract、static、strictfp（严格浮点运算）修饰。
更多关于接口的内容
Inheritance、override 继承和重写
- Strict inheritance 严格继承：子类只能添加新方法，无法重写超类（父类）中的方法（final限制）。
- 考虑final修饰类、方法、属性时的不同作用。
- Override 方法：具有一致的signature，复用的基本机制。
Polymorphism ，subtyping and overloading 多态，子类型化，重载
三种多态：
-
Ad hoc polymorphism （特殊多态）
用于function overloading（功能重载），即重载 -
Parametric polymorphism （参数化多态）
泛型
更多关于泛型的内容 -
Subtyping （subtype polymorphism / inclusion polymorphism ）（子类型多态、包含多态）
1.Overloading 重载
重载条件：
- 方法名相同
- 参数列表不同，即参数类型、个数、类型顺序至少有一项不相同
- 返回值类型可以不同
- 方法的修饰符可以不同
- 可以抛出不同的异常
- 可以在类内重载，也可以在子类重载
-
重载是一种静态多态，静态类型检查
（static dispatch 静态分派）并在编译阶段决定具体执行哪个方法（即对方法的调用取决于编译时声明的引用的类型） -
重写（dynamic dispatch 动态分派）则进行动态类型检查，根据运行时堆中的实例类型选择方法。
2.Generic 泛型
-
通配符 ：只有使用泛型的时候出现，不能在定义中出现。
-
类型擦除：编译后、运行时类型擦除
List-> List
注意可能引起重载编译错误。
运行时不能用 instanceof 检查泛型。 -
不能创建泛型数组
不能用在静态变量
不能创建对象（不能new）
3.Subtypes
超类的子类型，如：ArrayList和LinkedList是List的子类型。
- 子类型的规约不能弱化超类型的规约。
- 子类型多态：不同类型的对象可以统一处理而无需区分（不加区分地调用同样的方法等），从而隔离变化
- LSP（Liskov Substitution Principle） 如果S是T的子类型，那么T的对象可以被S的对象替换。
- Type casting 类型转换
避免向下类型转换。
4.Dispatch 分派
| Static dispatch 静态分派 | Dynamic dispatch 动态分派 |
|---|---|
| 将调用的名字与实际方法的名字联系起来（可能有多个） | 决定具体执行哪一个操作 |
| 重载，在编译阶段即可确定执行哪个具体操作 | 重写，在运行时决定 |
| Early/static binding | Lade/dynamic binding |
| 绑定static、private、final方法时发生 | 重写父类子类的同样方法 |
 |
 |
equals()
1.引用等价性 ==
- 比较内存地址ID
- 用于比较基本数据类型
2.对象等价性 equals()
- 验证正确性：reflexive 自反性、symmetric 对称性、transitive 传递性、非空（a.equals(null) return false）
hashCode()
- 等价的对象必须有相同的hashCode
- Rule：重写equals时重写hashcode
Equality of Mutable Types 可变对象的等价性
| Observational equality 观察等价性 | Behavioral equality 行为等价性 |
|---|---|
| 在不改变状态的形况下，两个mutable看起来是否一致 | 调用对象的任何方法都展示出一致的结果 |
| 调用observer，producer，creator | 调用任何方法，包括mutator |
| 当前情况下，看起来（如成员变量）相同 | 经过改变后，依然相同（只是别名引用） |
- 对不可变类型，观察等价性和行为等价性完全等价。
- 对可变类型，往往倾向于实现严格的观察等价性。（但有时观察等价性可能导致bug，甚至破坏RI）
- 对可变类型，应当实现行为等价性，即只有指向内从空间中同样的objects才相等（即equals比较引用，如==而hashcode把引用映射为一个值）。
- 所以对可变类型，无需重写equals和hashcode，直接继承object。（比较引用）
- 若一定要判断两个可变对象是否一致，最好定义一个新的方法。