“Java与模式”读书笔记(1)

 

Chapter 2 UML简介

 

1.       UML包括两类图：(P16)

a)         结构型图：Class Diagram; Object Diagram; Component Diagram; Deployment Diagram

b)        行为型图：Use Case Diagram; Activity Diagram; State Diagram; Sequence Diagram; Collaboration Diagram.

2.       Class Diagram中的关系

a)         Generalization关系：类与类的继承关系；接口与接口的继承关系；类对接口的实现关系。在Java中翻译为关键字extends和implements。(P21)

b)        Association关系：类与类之间的联接，它使一个类知道另一个类的属性和方法，可以双向也可以单身，通常不鼓励双向的关联。在每一个关联的端点，可以有一个Multiplicity，表明这一端的类可以有几个实例。(P22)

Aggregation关系：Association关系的一种，比Association更强，是整体与个体之间的关系。Association关系所涉及的两个类是处在同一层面上的，而在Aggregation关系中两个类是处在不平等的层次上的，一个代表整体，一个代表部分。(P22)

Composition关系：Association关系的一种，比Aggregation更强。要求普通的Aggregation关系中代表整体的对象负责代表部分的对象的生命周期，Composition关系不能共享。(P23)

Java语法无法分辨Association关系，需要考察所涉及类之间的逻辑关系。(P22)

c)        Dependency亲系：类与类之间的联接，总是单向的，表示一个类依赖于另一个类的定义。(P23)

一般而言，Dependency关系在Java中体现为局域变量、方法的参量，以及对静态方法的调用。如果是实例变量，则会变成某种Association关系。(P24)

 

Chapter 3 软件的可维护性和可复用性

 

1.       导致一个软件设计的可维护性较低的真正原因有四个：过于僵硬(Rigidity)、过于脆弱(Fragility)、复用率低(Immobility)、黏度过高(Viscosity)。(P35)

2.       一个好的系统设计应该有如下的性质：可扩展性(Extensibility)、灵活性(Flexibility)、可插入性(Pluggability)。（P36）

3.       OOD的四个重要特征：抽象、继承、封装和多态。抽象和继承使得概念和定义可以复用；多态使得实现和应该可以复用；抽象和封装可以保持和促进系统的可维护性。这样一来，复用的焦点不再集中在函数和算法等具体实现上(面向过程的复用特征)。而是集中在最重要的含有宏观商业逻辑的抽象层次上。即是说，复用的焦点发生了“倒转”。OOD中，可维护性复用是以设计原则和设计模式为基础的。（P38）

4.       重要的OOD设计原则有：

a)         OCP：对扩展开放，对修改关闭。

b)        LSP：任何基类出现的地方，子类一定可以出现。

c)        DIP：要依赖于抽象，不要依赖于实现。

d)        ISP：为客户端提供尽可能小的单独的接口，不要提供大的总接口。

e)         CARP：尽量使用合成/聚合而不是继承关系达到复用的目的。

f)         LoD：一个软件实体应当与尽可能少的其他实体发生相互作用。

这些设计原则首先都是复用的原则，遵循这些设计原则可以有效地提高系统的复用性，同时提高系统的可维护性。(P39)

 

Chapter 4 Open-Closed Principle(OCP)

 

1.       Software entities should be open for extension, but closed for modification.两大优越性：

a)         通过扩展已有的软件系统，可以提供新的行为，以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性。

b)        已有的软件模块，特别是最重要的抽象层次模块不能再修改，使变化中的软件系统有一定的稳定性和适应性。（P41）

2.       OCP就是所谓的EVP（Principle of Encapsulation of Variation），EVP思想：找到一个系统的可变因素，将它封装起来。EVP意味着：

a)         一种可变性不应当散落在代码的很多角落里，而应当被封装到一个对象里面。继承应该被看做是封装变化的方法，而不应当被认为是从一般对象生成特殊对象的方法。

b)        一种可变性不应当与另一种可变性混合在一起。因此，层次太多的继承结构通常是不合理的。（P43）

3.       所有设计模式都是对不同的可变性的封装。（P46）