第2章　预备知识——UML类图与面向对象设计原则

在学习设计模式之前，需要掌握一些预备知识，主要包括UML类图和面向对象设计原则，它们是“基础内功”，将为后续的“深入修行”奠定基础。

UML类图可用于描述每一个设计模式的结构以及对模式实例进行说明，而模式结构又是设计模式解法的核心组成部分。学一个设计模式，如果不能绘制和理解其结构图，基本上等于没学。

面向对象设计原则是评价每个设计模式应用效果的重要依据。每个模式都符合一个或多个面向对象设计原则（个别模式除外），这些原则都是从无数项目中提取出来的经验性原则，它们为消除软件设计和实现中的“臭味（Bad Smell）”而诞生，力图为当前系统提供最好的设计方案。常用的面向对象设计原则包括7个，分别是单一职责原则、开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成复用原则和迪米特法则。

2.1　UML概述

不知道大家在看武侠电视剧的时候有没有注意过一个细节，很多传说中的“武功秘籍”并不全是文字，通常都配有图片，因为与文字相比，图形更加直观易懂。与这些“武功秘籍”相似，设计模式通常也结合一些图形来进行描述，其中最常用、使用最广泛的图形描述技术就是UML（Unified Modeling Language，统一建模语言）。

UML诞生于20世纪90年代，当时面向对象分析和设计方法发展非常迅速。随着面向对象技术的广泛应用，其相关研究也十分活跃，包括面向对象建模技术。在那个群雄逐鹿的年代，先后诞生了50多种建模技术。每一种技术的创造者都在努力推崇并完善自己的产品。每一种技术都有一群自己的粉丝，大家为了让更多人使用与自己相同的技术而不断“游说”他人并相互“诋毁”，于是爆发了一场“方法大战”。

在众多的建模技术中，Grady Booch的Booch方法、James Rumbaugh的OMT（Object Modeling Technology，对象建模技术）、Ivar Jacobson的OOSE（Object Oriented Software Engineering，面向对象软件工程）以及Peter Coad和Edward Yourdon的Coad/Yourdon方法最引人注目，这些技术也各自拥有一个庞大的用户群。为了解决建模方法过多带来的种种问题，Booch方法、OMT和OOSE的3位创始人，为创建一个统一的建模语言而开始合作。他们3人中最先走到一起的是Grady Booch和James Rumbaugh，从1994年开始，他们在Rational软件公司（该公司于2002年被IBM收购）开始了UML的创建工作，当时他们的目标是创建一种新的名为“Unified Method（统一方法）”的方法，用来对当时存在的众多方法进行规范化和标准化，该方法将Booch方法和Rumbaugh的OMT-2方法统一起来。1995年，OOSE方法和Objectory方法的创建者Ivar Jacobson也加入其中。此时，UML 3位创始人正式联手，史称“UML三友”，面向对象建模语言也进入3位大师一统江湖的阶段。

1996年6月和10月，UML发布了0.9版和0.91版，名称也由之前的UM改为UML，同年，UML被OMG（Object Management Group，对象管理组织）提议为面向对象可视化建模语言的推荐标准。1997年11月，在Ivar Jacoboson、Grady Booch以及James Rumbaugh的共同努力下，UML 1.1版本提交给OMG并获得通过，UML 1.1成为建模语言的工业标准。在2003年6月的OMG技术会议上，UML 2.0获得正式通过，UML的发展与应用也上升到一个新的高度，越来越多的人开始学习和使用UML来进行软件建模。正因为如此，软件大师Martin Fowler曾说过“你应该使用UML吗？是！旧的面向对象符号正在快速消失，新的书、文章将全部采用UML作为符号。如果你正要开始使用建模符号，你就该直接学习UML。”

1．UML特性

UML名称中所包含的3个单词正是UML特性的体现：

（1）UML融合了多种优秀的面向对象建模方法以及多种得到认可的软件工程方法，消除了因方法林立且相互独立而带来的种种不便，集百家之所长，故名“统一（Unified）”。UML通过统一的表示方法，让不同知识背景的领域专家、系统分析设计人员和开发人员以及用户可以方便地交流。

（2）UML是一种通用的可视化建模（Modeling）语言，不同于编程语言，它通过一些标准的图形符号和文字来对系统进行建模，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，UML是一种总结了以往建模技术的经验并吸收了当今最优秀成果的标准建模方法。

（3）UML是一种语言（Language），也就意味着它有属于自己的标准表达规则，它不是一种类似Java、C++、C＃的编程语言，而是一种分析设计语言，也就是一种建模语言。

2．UML结构

UML是一种由图形符号表达的建模语言，其结构主要包括以下几个部分：

（1）视图（View）：UML视图用于从不同的角度来表示待建模系统。视图是由许多图形组成的一个抽象集合，在建立一个系统模型时，只有通过定义多个视图，每个视图显示该系统的一个特定方面，才能构造出该系统的完整蓝图，视图也将建模语言链接到开发所选择的方法和过程。

UML视图包括用户视图、结构视图、行为视图、实现视图和环境视图。其中，用户视图以用户的观点表示系统的目标，它是所有视图的核心，用于描述系统的需求；结构视图表示系统的静态行为，描述系统的静态元素，如包、类与对象，以及它们之间的关系；行为视图表示系统的动态行为，描述系统的组成元素（如对象）在系统运行时的交互关系；实现视图表示系统中逻辑元素的分布，描述系统中物理文件以及它们之间的关系；环境视图表示系统中物理元素的分布，描述系统中硬件设备以及它们之间的关系。

（2）图（Diagram）：UML图是描述UML视图内容的图形。最新的UML 2.0提供了13种图，分别是用例图（Use Case Diagram）、类图（Class Diagram）、对象图（Object Diagram）、包图（Package Diagram）、组合结构图（Composite Structure Diagram）、状态图（State Diagram）、活动图（Activity Diagram）、顺序图（Sequence Diagram）、通信图（Communication Diagram）、定时图（Timing Diagram）、交互概览图（Interaction Overview Diagram）、组件图（Component Diagram）和部署图（Deployment Diagram），通过它们之间的相互结合可提供待建模系统的所有视图。其中，用例图对应用户视图，类图、对象图、包图和组合结构图对应结构视图，状态图、活动图、顺序图、通信图、定时图和交互概览图对应行为视图，组件图对应实现视图，部署图对应环境视图。

（3）模型元素（Model Element）：模型元素是指UML图中所使用的一些概念，它们对应于普通的面向对象概念，如类、对象、消息以及这些概念之间的关系，如关联关系、依赖关系、泛化关系等。同一个模型元素可以在多个不同的UML图中使用，但是无论在哪个图中，同一个模型元素都必须保持相同的意义并具有相同符号。

（4）通用机制（General Mechanism）：UML提供的通用机制为模型元素提供额外的注释、信息和语义，这些通用机制也提供了扩展机制，允许用户对UML进行扩展，如定义新的建模元素、扩展原有元素的语义、添加新的特殊信息来扩展模型元素的规则说明等，以便适用于一个特定的方法或过程、组织或用户。

2.2　类与类的UML图示

在UML 2.0的13种图形中，类图是使用频率最高的两种UML图之一（另一种是用于需求建模的用例图），它用于描述系统中所包含的类以及它们之间的相互关系，帮助人们简化对系统的理解，是系统分析和设计阶段的重要产物，也是系统编码和测试的重要模型依据。

在设计模式中，可以使用类图来描述一个模式的结构并对每一个模式实例进行分析。

1．类

类（Class）封装了数据和行为，是面向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。在系统中，每个类都具有一定的职责。职责指的是类要完成什么样的功能，要承担什么样的义务。一个类可以有多种职责，设计得好的类一般只有一种职责。在定义类的时候，将类的职责分解成为类的属性和操作（即方法）。类的属性即类的数据职责，类的操作即类的行为职责。设计类是面向对象设计中最重要的组成部分，也是最复杂和最耗时的部分。

在软件系统运行时，类将被实例化成对象（Object），对象对应于某个具体的事物，是类的实例（Instance）。

类图（Class Diagram）是用出现在系统中的不同类来描述系统的静态结构，主要用来描述不同的类以及它们之间的关系。

图2-1　类的UML图示

2．类的UML图示

在UML中，类使用包含类名、属性和操作且带有分隔线的长方形来表示，如定义一个Employee类，它包含属性name、age和email，以及操作modifyInfo（），在UML类图中该类如图2-1所示。

图2-1对应的Java代码片段如下：

在UML类图中，类一般由三部分组成。

（1）类名：每个类都必须有一个名字，类名是一个字符串。

（2）类的属性（Attributes）：属性是指类的性质，即类的成员变量。一个类可以有任意多个属性，也可以没有属性。

UML规定属性的表示方式为：

    可见性 名称：类型[ = 默认值]

其中：

①“可见性”表示该属性对于类外的元素而言是否可见，包括公有（public）、私有（private）和受保护（protected）3种，在类图中分别用符号+、-和＃表示。

②“名称”表示属性名，用一个字符串表示。

③“类型”表示属性的数据类型，可以是基本数据类型，也可以是用户自定义类型。

④“默认值”是一个可选项，即属性的初始值。

（3）类的操作（Operations）：操作是类的任意一个实例对象都可以使用的行为，是类的成员方法。

UML规定操作的表示方式为：

    可见性 名称([参数列表])[：返回类型]

其中：

①“可见性”的定义与属性的可见性定义相同。

②“名称”即方法名，用一个字符串表示。

③“参数列表”表示方法的参数，其语法与属性的定义相似，参数个数是任意的，多个参数之间用逗号“，”隔开。

④“返回类型”是一个可选项，表示方法的返回值类型，依赖于具体的编程语言，可以是基本数据类型，也可以是用户自定义类型，还可以是空类型（void）。如果是构造方法，则无返回类型。

2.3　类之间的关系

在软件系统中，类并不是孤立存在的，类与类之间存在各种关系。对于不同类型的关系，UML提供了不同的表示方式。

1．关联关系

关联（Association）关系是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系，如汽车和轮胎、师傅和徒弟、班级和学生等。在UML类图中，用实线连接有关联关系的对象所对应的类，在使用Java、C＃和C++等编程语言实现关联关系时，通常将一个类的对象作为另一个类的成员变量。在使用类图表示关联关系时可以在关联线上标注角色名，一般使用一个表示二者之间关系的动词或者名词表示角色名（有时该名词为实例对象名），关系的两端代表两种不同的角色。因此，在一个关联关系中可以包含两个角色名，角色名不是必需的，可以根据需要增加，其目的是使类之间的关系更加明确。

例如在一个登录界面类LoginForm中包含一个JButton类型的注册按钮loginButton，它们之间可以表示为关联关系。代码实现时可以在LoginForm中定义一个名为loginButton的属性对象，其类型为JButton，如图2-2所示。

图2-2　关联关系实例

图2-2对应的Java代码片段如下：

在UML中，关联关系通常又包含如下几种形式。

1）双向关联

默认情况下，关联是双向的。例如，顾客（Customer）购买商品（Product）并拥有商品，反之，卖出的商品总有某个顾客与之相关联。因此，Customer类和Product类之间具有双向关联关系，如图2-3所示。

图2-3　双向关联实例

图2-3对应的Java代码片段如下：

2）单向关联

类的关联关系也可以是单向的，在UML中单向关联用带箭头的实线表示。例如，顾客（Customer）拥有地址（Address），则Customer类与Address类具有单向关联关系，如图2-4所示。

图2-4　单向关联实例

图2-4对应的Java代码片段如下：

图2-5　自关联实例

3）自关联

在系统中可能会存在一些类的属性对象类型为该类本身，这种特殊的关联关系称为自关联。例如，一个节点类（Node）的成员又是节点Node类型的对象，如图2-5所示。

图2-5对应的Java代码片段如下：

4）多重性关联

多重性关联关系又称为重数性（Multiplicity）关联关系，表示两个关联对象在数量上的对应关系。在UML中，对象之间的多重性可以直接在关联直线上用一个数字或一个数字范围表示。

对象之间可以存在多种多重性关联关系，常见的多重性表示方式如表2-1所示。

表2-1　多重性表示方式

例如，一个界面（Form）可以拥有零个或多个按钮（Button），但是一个按钮只能属于一个界面，因此，一个Form类的对象可以与零个或多个Button类的对象相关联，但一个Button类的对象只能与一个Form类的对象关联，如图2-6所示。

图2-6　多重性关联实例

图2-6对应的Java代码片段如下：

5）聚合关系

聚合（Aggregation）关系表示整体与部分的关系。在聚合关系中，成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在。在UML中，聚合关系用带空心菱形的直线表示。例如，汽车发动机（Engine）是汽车（Car）的组成部分，但是汽车发动机可以独立存在，因此，汽车和发动机是聚合关系，如图2-7所示。

图2-7　聚合关系实例

在代码实现聚合关系时，成员对象通常作为构造方法、Setter方法或业务方法的参数注入整体对象中。图2-7对应的Java代码片段如下：

6）组合关系

组合（Composition）关系也表示类之间整体和部分的关系，但是在组合关系中整体对象可以控制成员对象的生命周期。一旦整体对象不存在，成员对象也将不存在，成员对象与整体对象之间具有同生共死的关系。在UML中，组合关系用带实心菱形的直线表示。例如，人的头（Head）与嘴巴（Mouth），嘴巴是头的组成部分之一，而且如果头没了，嘴巴也就没了，因此头和嘴巴是组合关系，如图2-8所示。

图2-8　组合关系实例

在代码实现组合关系时，通常在整体类的构造方法中直接实例化成员类。图2-8对应的Java代码片段如下：

2．依赖关系

依赖（Dependency）关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。例如，驾驶员开车，在Driver类的drive（）方法中将Car类型的对象car作为一个参数传递，以便在drive（）方法中能够调用Car类的move（）方法，且驾驶员的drive（）方法依赖车的move（）方法，因此类Driver依赖类Car，如图2-9所示。

图2-9　依赖关系实例

在系统实施阶段，依赖关系通常通过3种方式来实现：第1种也是最常用的一种方式，是如图2-9所示的将一个类的对象作为另一个类中方法的参数；第2种方式是在一个类的方法中将另一个类的对象作为其局部变量；第3种方式是在一个类的方法中调用另一个类的静态方法。图2-9对应的Java代码片段如下：

3．泛化关系

泛化（Generalization）关系也就是继承关系，用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛化关系用带空心三角形的直线来表示。在代码实现时，使用面向对象的继承机制来实现泛化关系，如在Java语言中使用extends关键字、在C++/C＃中使用冒号“：”来实现。例如，Student类和Teacher类都是Person类的子类，Student类和Teacher类继承了Person类的属性和方法，Person类的属性包含姓名（name）和年龄（age），每一个Student和Teacher也都具有这两个属性。另外Student类增加了属性学号（studentNo），Teacher类增加了属性教师编号（teacherNo），Person类的方法包括行走move（）和说话say（），Student类和Teacher类继承了这两个方法，而且Student类还新增方法study（），Teacher类新增方法teach（），如图2-10所示。

图2-10　泛化关系实例

图2-10对应的Java代码片段如下：

4．接口与实现关系

在很多面向对象语言中都引入了接口的概念，如Java、C＃等。在接口中，通常没有属性，而且所有的操作都是抽象的，只有操作的声明，没有操作的实现。UML中用与类的表示法类似的方式表示接口，如图2-11所示。

接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现（Realization）关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。例如，定义了一个交通工具接口Vehicle，包含一个抽象操作move（），在类Ship和类Car中都实现了该move（）操作，不过具体的实现细节将会不一样，如图2-12所示。

图2-11　接口的UML图示

图2-12　实现关系实例

实现关系在编程实现时，不同的面向对象语言也提供了不同的语法，如在Java语言中使用implements关键字，而在C＃中使用冒号“：”来实现。图2-12对应的Java代码片段如下：

2.4　面向对象设计原则概述

面向对象设计的目标之一在于支持可维护性复用，一方面需要实现设计方案或者源代码的重用，另一方面要确保系统能够易于扩展和修改，具有较好的灵活性。面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则。面向对象设计原则也是用于评价一个设计模式的使用效果的重要指标之一，在之后的设计模式学习中，大家经常会看到诸如“×××模式符合×××原则”“×××模式违反了×××原则”这样的语句。

最常用的7种面向对象设计原则如表2-2所示。

表2-2　7种常用的面向对象设计原则

2.5　单一职责原则

单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。单一职责原则定义如下：

单一职责原则的核心思想是：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中；如果多个职责总是同时发生改变，则可将它们封装在同一类中。

单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，这需要设计人员具有较强的分析设计能力和相关实践经验。

下面通过一个简单实例来进一步分析单一职责原则。

图2-13　初始设计方案结构图

Sunny软件公司开发人员针对某CRM（Customer Relationship Management，客户关系管理）系统中客户信息图形统计模块提出了如图2-13所示的初始设计方案结构图。

在图2-13中，CustomerDataChart类中的方法说明如下：getConnection（）方法用于连接数据库，findCustomers（）方法用于查询所有的客户信息，createChart（）方法用于创建图表，displayChart（）方法用于显示图表。

现使用单一职责原则对其进行重构。

在图2-13中，CustomerDataChart类承担了太多的职责，既包含与数据库相关的方法，又包含与图表生成和显示相关的方法。如果在其他类中也需要连接数据库或者使用findCustomers（）方法查询客户信息，则难以实现代码的重用。无论是修改数据库连接方式，还是修改图表显示方式，都需要修改该类，它拥有不止一个引起它变化的原因，违背了单一职责原则。因此需要对该类进行拆分，使其满足单一职责原则。类CustomerDataChart可拆分为如下3个类。

（1）DBUtil：负责连接数据库，包含数据库连接方法getConnection（）。

（2）CustomerDAO：负责操作数据库中的Customer表，包含对Customer表的增／删／改／查等方法，如findCustomers（）。

（3）CustomerDataChart：负责图表的生成和显示，包含方法createChart（）和displayChart（）。

对图2-13使用单一职责原则重构后的结构如图2-14所示。

图2-14　对图2-13重构后的结构图

2.6　开闭原则

开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则。开闭原则由Bertrand Meyer于1988年提出，其定义如下：

在开闭原则的定义中，软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。

任何软件都需要面临一个很重要的问题，即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时，应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行扩展，而且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大，软件寿命越来越长，软件维护成本越来越高，设计满足开闭原则的软件系统也变得越来越重要。

为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。在Java、C＃等编程语言中，可以为系统定义一个相对稳定的抽象层，而将不同的实现行为移至具体的实现层中完成。在很多面向对象编程语言中都提供了接口、抽象类等机制，可以通过它们定义系统的抽象层，再通过具体类来进行扩展。如果需要修改系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

在本书所要介绍的24种设计模式中，大部分设计模式都符合开闭原则。在对每个模式进行优缺点评价时，都会将开闭原则作为一个重要的评价依据，以判断基于该模式设计的系统是否具备良好的灵活性和可扩展性。

2.7　里氏代换原则

里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士Barbara Liskov教授和卡内基·梅隆大学Jeannette Wing教授于1994年提出。其严格表述如下：如果对每个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。这个定义比较拗口且难以理解，因此一般使用它的另一个通俗版定义：

里氏代换原则表明，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。如果一个软件实体使用的是一个子类对象，那么它不一定能够使用基类对象。例如，我喜欢动物，那我一定喜欢狗，因为狗是动物的子类；但是我喜欢狗，不能据此断定我喜欢动物，因为我并不喜欢老鼠，虽然它也是动物。

里氏代换原则是实现开闭原则的重要方式之一。由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

在运用里氏代换原则时，应该将父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法。程序运行时，子类实例替换父类实例，可以很方便地扩展系统的功能，无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。

2.8　依赖倒转原则

如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要实现机制之一，它是系统抽象化的具体实现。依赖倒转原则是Robert C. Martin在1996年为“C++Reporter”所写的专栏Engineering Notebook的第3篇，后来加入他在2002年出版的经典著作Agile Software Development，Principles，Patterns，and Practices一书中。依赖倒转原则定义如下：

依赖倒转原则要求在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。

在引入抽象层后，系统将具有很好的灵活性。在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中。这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，就能扩展系统的功能，满足开闭原则的要求。

在实现依赖倒转原则时，需要针对抽象层编程，而将具体类的对象通过依赖注入（Dependency Injection，DI）的方式注入其他对象中。依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有3种：构造注入、设值注入（Setter注入）和接口注入。构造注入是指通过构造函数来传入具体类的对象，设值注入是指通过Setter方法来传入具体类的对象，而接口注入是指通过实现在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象来覆盖父类对象。

下面通过一个简单实例来加深对开闭原则、里氏代换原则和依赖倒转原则的理解。

Sunny软件公司开发人员在开发某CRM系统时发现：该系统经常需要将存储在TXT或Excel文件中的客户信息转存到数据库中，因此需要进行数据格式转换。在客户数据操作类中将调用数据格式转换类的方法实现格式转换和数据库插入操作，初始设计方案结构如图2-15所示。

图2-15　初始设计方案结构图

在编码实现图2-15所示结构时，Sunny软件公司开发人员发现该设计方案存在一个非常严重的问题，由于每次转换数据时数据来源不一定相同，因此需要更换数据转换类，如有时需要将TXTDataConvertor改为ExcelDataConvertor。此时，需要修改CustomerDAO的源代码，而且在引入并使用新的数据转换类时也不得不修改CustomerDAO的源代码，系统扩展性较差，违反了开闭原则，现需要对该方案进行重构。

在本实例中，由于CustomerDAO针对具体数据转换类编程，因此在增加新的数据转换类或者更换数据转换类时都不得不修改CustomerDAO的源代码。可以通过引入抽象数据转换类解决该问题。在引入抽象数据转换类DataConvertor之后，CustomerDAO针对抽象类DataConvertor编程，而将具体数据转换类的类名存储在配置文件中，符合依赖倒转原则。根据里氏代换原则，程序运行时，具体数据转换类对象将替换DataConvertor类型的对象，程序不会产生任何异常。更换具体数据转换类时无须修改源代码，只需要修改配置文件；如果需要增加新的具体数据转换类，只要将新增数据转换类作为DataConvertor的子类并修改配置文件即可，原有代码无须做任何修改，满足开闭原则。重构后的结构如图2-16所示。

图2-16　对图2-15重构后的结构图

在上述重构过程中，使用了开闭原则、里氏代换原则和依赖倒转原则。在大多数情况下，这3个设计原则会同时出现，开闭原则是目标，里氏代换原则是基础，依赖倒转原则是手段，它们相互补充，相辅相成，目标一致，只是分析问题时所站角度不同而已。

2.9　接口隔离原则

接口隔离原则定义如下：

根据接口隔离原则，当一个接口太大时，需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每个接口应该承担一种相对独立的角色。这里的“接口”有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另一种是指某种语言具体的“接口”定义，有严格的定义和结构，例如Java语言中的interface。对于这两种不同的含义，ISP的表达方式以及含义都有所不同。

（1）当把“接口”理解成一个类型所提供的所有方法特征的集合时，这就是一种逻辑上的概念，接口的划分将直接带来类型的划分。可以把接口理解成角色，一个接口只能代表一个角色，每个角色都有它特定的一个接口，此时，这个原则可以叫作“角色隔离原则”。

（2）如果把“接口”理解成狭义的特定语言的接口，那么ISP表达的意思是指接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。在面向对象编程语言中，实现一个接口就需要实现该接口中定义的所有方法，因此大的总接口使用起来不一定很方便。为了使接口的职责单一，需要将大接口中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便，并各承担某一单一角色。接口应该尽量细化，同时接口中的方法应该尽量少，每个接口中只包含一个客户端（如子模块或业务逻辑类）所需的方法即可，这种机制也称为“定制服务”，即为不同的客户端提供宽窄不同的接口。

下面通过一个简单实例来加深对接口隔离原则的理解。

Sunny软件公司开发人员针对某CRM系统的客户数据显示模块设计了如图2-17所示的CustomerDataDisplay接口。其中，方法readData（）用于从文件中读取数据；方法transformToXML（）用于将数据转换成XML格式；方法createChart（）用于创建图表；方法displayChart（）用于显示图表；方法createReport（）用于创建文字报表；方法displayReport（）用于显示文字报表。

图2-17　初始设计方案结构图

在实际使用过程中发现该接口很不灵活。例如，如果一个具体的数据显示类无须进行数据转换（源文件本身就是XML格式），但由于实现了该接口，将不得不实现其中声明的transformToXML（）方法（至少需要提供一个空实现）。如果需要创建和显示图表，除了需实现与图表相关的方法外，还需要实现创建和显示文字报表的方法，否则程序在编译时将报错。

现使用接口隔离原则对其进行重构。

在图2-17中，由于在接口CustomerDataDisplay中定义了太多方法，即该接口承担了太多职责。一方面导致该接口的实现类很庞大，在不同的实现类中都不得不实现接口中定义的所有方法，灵活性较差，如果出现大量的空方法，将导致系统中产生大量的无用代码，影响代码质量；另一方面由于客户端针对大接口编程，将在一定程度上破坏程序的封装性，客户端看到了不应该看到的方法，没有为客户端定制接口。因此需要将该接口按照接口隔离原则和单一职责原则进行重构，将其中的一些方法封装在不同的小接口中，确保每个接口使用起来都较为方便，并各承担某一单一角色，每个接口中只包含一个客户端（如模块或类）所需的方法即可。

通过使用接口隔离原则，本实例重构后的结构如图2-18所示。

在使用接口隔离原则时，需要注意控制接口的粒度。接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可。

图2-18　对图2-17重构后的结构图

2.10　合成复用原则

合成复用原则又称为组合／聚合复用原则（Composition/Aggregate Reuse Principle，CARP），其定义如下：

合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能的目的。简言之：复用时要尽量使用组合／聚合关系（关联关系），少用继承。

在面向对象设计中，可以通过两种方法在不同的环境中复用已有的设计和实现，即通过组合／聚合关系或通过继承，但首先应该考虑使用组合／聚合，组合／聚合可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。

通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白箱”复用。如果基类发生改变，那么子类的实现也不得不发生改变。从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性。而且继承只能在有限的环境中使用（如类没有声明为不能被继承）。

由于组合或聚合关系可以将已有的对象（也可称为成员对象）纳入新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现细节对于新对象不可见，所以这种复用又称为“黑箱”复用。相对继承关系而言，“黑箱”复用的耦合度相对较低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作。合成复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。

一般而言，如果两个类之间是“Has-A”的关系，应使用组合或聚合；如果是“Is-A”关系，可使用继承。“Is-A”是严格的分类学意义上的定义，意思是一个类是另一个类的“一种”；而“Has-A”则不同，它表示某一个角色具有某一项责任。

下面通过一个简单实例来加深对合成复用原则的理解。

Sunny软件公司开发人员在初期的CRM系统设计中，考虑到客户数量不多，系统采用MySQL作为数据库，与数据库操作有关的类（如CustomerDAO类等）都需要连接数据库，连接数据库的方法getConnection（）封装在DBUtil类中。由于需要重用DBUtil类的getConnection（）方法，设计人员将CustomerDAO作为DBUtil类的子类，初始设计方案结构如图2-19所示。

图2-19　初始设计方案结构图

随着客户数量的增加，系统决定升级为Oracle数据库，因此需要增加一个新的OracleDBUtil类来连接Oracle数据库。由于在初始设计方案中CustomerDAO和DBUtil之间是继承关系，因此在更换数据库连接方式时需要修改CustomerDAO类的源代码，将CustomerDAO作为OracleDBUtil的子类，这将违反开闭原则。（当然也可以修改DBUtil类的源代码，同样会违反开闭原则。）

现使用合成复用原则对其进行重构。

根据合成复用原则，在实现复用时应该多用关联，少用继承。因此在本实例中可以使用关联复用来取代继承复用，重构后的结构如图2-20所示。

图2-20　对图2-19重构后的结构图

在图2-20中，CustomerDAO和DBUtil之间的关系由继承关系变为关联关系，采用依赖注入的方式将DBUtil对象注入CustomerDAO中，可以使用构造注入，也可以使用设值注入。如果需要对DBUtil的功能进行扩展，可以通过其子类来实现，如通过子类OracleDBUtil来连接Oracle数据库。由于CustomerDAO针对DBUtil编程，根据里氏代换原则，DBUtil子类的对象可以覆盖DBUtil对象，只需在CustomerDAO中注入子类对象即可使用子类所扩展的方法。例如在CustomerDAO中注入OracleDBUtil对象，即可实现Oracle数据库连接，原有代码无须修改，而且还可以很灵活地增加新的数据库连接方式。

2.11　迪米特法则

迪米特法则来自1987年美国东北大学（Northeastern University）一个名为Demeter的研究项目。迪米特法则又称为最少知识原则（Least Knowledge Principle，LKP），其定义如下：

如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易。这是对软件实体之间通信的限制。迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。

迪米特法则还有几种定义形式：不要和“陌生人”说话，只与你的直接朋友通信等。在迪米特法则中，对于一个对象，其“朋友”包括以下几类：

（1）当前对象本身（this）。

（2）以参数形式传入到当前对象方法中的对象。

（3）当前对象的成员对象。

（4）如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友。

（5）当前对象所创建的对象。

任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。在应用迪米特法则时，一个对象只能与直接朋友发生交互，不要与“陌生人”发生直接交互，这样做可以降低系统的耦合度，一个对象的改变不会给太多其他对象带来影响。

迪米特法则要求在设计系统时，应该尽量减少对象之间的交互。如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用；如果其中一个对象需要调用另一个对象的方法，可以通过第三者转发这个调用。简言之，就是通过引入一个合理的第三者来降低现有对象之间的耦合度。

在将迪米特法则运用到系统设计中时，要注意以下几点：在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

下面通过一个简单实例来加深对迪米特法则的理解。

Sunny软件公司所开发的CRM系统包含很多业务操作窗口。在这些窗口中，某些界面控件之间存在复杂的交互关系，一个控件事件的触发将导致多个其他界面控件产生响应。例如，当一个按钮（Button）被单击时，对应的列表框（List）、组合框（ComboBox）、文本框（TextBox）、文本标签（Label）等都将发生改变，在初始设计方案中，界面控件之间的交互关系可简化为如图2-21所示结构。

图2-21　初始设计方案结构图

在图2-21中，由于界面控件之间的交互关系复杂，导致在该窗口中增加新的界面控件时需要修改与之交互的其他控件的源代码，系统扩展性较差，也不便于增加和删除控件。

现使用迪米特对其进行重构。

在本实例中，可以通过引入一个专门用于控制界面控件交互的中间类（Mediator）来降低界面控件之间的耦合度。引入中间类之后，界面控件之间不再发生直接引用，而是将请求先转发给中间类，再由中间类来完成对其他控件的调用。当需要增加或删除新的控件时，只需修改中间类即可，无须修改新增控件或已有控件的源代码。重构后的结构如图2-22所示。

图2-22　对图2-21重构后的结构图

在图2-22中省略了中间类以及控件的属性和方法定义，在本书第20章中将进一步对该实例进行讲解，详细说明中间类Mediator的设计和实现。

至此，常用的7个面向对象设计原则全部介绍完毕，在此后的设计模式讲解中会多次提到这些原则。这7个原则也如同修炼设计模式内功的“入门功夫”，将为后续设计模式的学习奠定基础。大部分设计模式都通过应用一个或多个设计原则来为系统提供设计方案，从而构建出支持可维护性复用的软件。