软件构造复习要点（一）

1,2,3章

Five key quality objectives of software construction

– Easy to understand: elegant and beautiful code / understandability

– Ready for change: maintainability and adaptability

– Cheap for develop: design for/with reuse: reusability

– Safe from bugs: robustness

– Efficient to run: performance

How OOP improves quality

Correctness: encapsulation, decentralization

Robustness: encapsulation, error handling

Extendibility: encapsulation, information hiding

Reusability: modularity, component, models, patterns

Compatibility: standardized module and interface

Portability: information hiding, abstraction

Ease of use: GUI components, framework

Efficiency: reusable components

Timeliness: modeling, reuse

Economy: reuse

Functionality: extendibility

Static Typing vs. Dynamic Typing

静态类型语言 – 在编译阶段进行类型检查

动态类型语言 – 在运行阶段进行类型检查

Static Checking and Dynamic Checking

静态检查：关于“类型”的检查，不考虑值

动态检查：关于“值”的检查

---

静态类型检查 >> 动态 >> 无检查

静态类型检查：可在编译阶段发现错误，避 免了将错误带入到运行阶段，可提高程序正 确性/健壮性

Static checking

Syntax errors 语法错误

Wrong names 类名/函数名错误

Wrong number of arguments 参数数目错误

Wrong argument types 参数类型错误

Wrong return types 返回值类型错误

**补充：**如果编译器无法确定final变量不会改变，就提示错误，这也是静态类型检查的一部分

Dynamic checking

Illegal argument values 非法的参数值. 例如：除0

Unpresentable return values 非法的返回值

Out-of-range indexes 越界

Calling a method on a null object reference. 空指针

Immutable Wrappers

– Collections.unmodifiableList

– Collections.unmodifiableSet

– Collections.unmodifiableMap

这种包装器得到的结果是不可变的：只能看

但是这种“不可变”是在运行阶段获得的，编译阶段 无法据此进行静态检查

所以如果对这种类型变量来 sort() ，java不会warn ，会在运行的时候报 exception

ADT

Spec

除非spec的后置条件中有说明，否则方法不应该修改输入参数

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

越强的规约，意味着implementer的自由度和责任越重，而client的 责任越轻。

Diagramming specifications

某个具体实现， 若满足规约，则落在其范围内；否则，在其之外。

更强的规约，表达为更小的区域

ADT operations

creator : t* → T

producer : T+, t* → T

observer : T+, t* → t

mutator : T+, t* → void | t | T

注：

Each T is the abstract type itself

Each t is some other type.

举例：

操作	类型
Integer.valueOf()	Creator
String.toUpperCase()	Producer
BufferedReader.readLine()	Mutator ！！！
Map.keySet()	Observer ！！！

how to establish invariants

established by creators and producers(创建要合法，checkRep)

preserved by mutator and observers(修改要合法，checkRep)

no representation exposure occurs (没有表示暴漏)

Override & Overload

重写(Override)
即外壳不变，核心重写！
重载(Overload)
方法名字相同，而参数不同,

相同/不同的返回值类型

相同/不同的public/private/protected

区别：
Override 在运行阶段时决定执行哪个方法 (dynamic type checking)
Overload 在编译阶段时决定执行哪个方法 (static type checking)

Equality of ADT

Equality of Immutable Types

看AF： AF映射到同样的结果，则等价

看observation：站在外部观察者角度，对两个对象调用任何相同的操作，都会得到相同的结果，则认为这 两个对象是等价的。

观察等价性和行为等价性对Immutable Types来说等价

Equality of mutable Types

行为等价性：调用对象的任何方法都展示出一致的结果（很严格）；接近于==；object的equals就是按照行为等价性

java中 list,set实现观察等价性(只需要里面装的东西，属性相同，即等价)

Equality contract

用“是否为等价关系”检验你的equals()是否正确，如下：

Reflexive – every object is equal to itself

Symmetric – if a.equals(b) then b.equals(a)

Transitive – if a.equals(b) and b.equals©, then a.equals©

Consistent– equal objects stay equal unless mutated

“Non-null” – a.equals(null) returns false

hashcode contract

等价的对象，hashCode()必须相同

So

So immutable types must override both equals() and hashCode() .

So mutable types should not override equals() and hashCode() at all,

Autoboxing and Equality

观察下面现象

Map<String,Integer> a=new HashMap<>();
Map<String,Integer> b=new HashMap<>();
a.put("c", 1);
b.put("c", 1);
System.out.print(a.get("c")==b.get("c"));

result： true

Map<String,Integer> a=new HashMap<>();
Map<String,Integer> b=new HashMap<>();
a.put("c", 130);
b.put("c", 130);
System.out.print(a.get("c")==b.get("c"));

result： false

为什么！

-128~127，java内存中提前new好了，每次自动Autoboxing 的时候都去指向它们。

不是Autoboxing，当然不会这样

Map<String,Integer> a=new HashMap<>();
Map<String,Integer> b=new HashMap<>();
a.put("c", new Integer(13));
b.put("c", new Integer(13));
System.out.print(a.get("c")==b.get("c"));

result： false