内容

在软件系统中，类不是孤立存在的，类与类之间存在相互关系，因此需要通过UML来描述这些类之间的关系。类之间具有如下几种关系。

1. 关联关系
   1. 双向关联
   2. 单向关联
   3. 自关联
   4. 多重性关联
   5. 聚合关系
   6. 组合关系
2. 依赖关系
3. 泛化关系（继承关系）
4. 接口与实现关系
   以上是按照刘伟的分类方式来说的。

更易理解、符合名字定义的分类方式如下：

1. 继承关系（即泛化关系，将接口与实现关系也包含在内）
2. 组合关系
3. 聚合关系
4. 依赖关系
5. 关联关系

关联关系

关联关系（Association）是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系，如汽车和轮胎、师傅和徒弟、班级和学生等。

在UML类图中，用实线连接有关联的对象所对应的类，在使用Java、C#和C++等编程语言实现关联关系时，通常将一个类的对象作为另一个类的属性。

• 要点
  • 在使用类图表示关联关系时可以在关联线上标注角色名，一般使用一个表示两者之间关系的动词或者名词表示角色名(有时该名词为实例对象名)
  • 关系的两端代表不同的两种角色，因此在一个关联关系中可以包含两个角色名。
  • 角色名不是必需的，可以根据需要增加，其目的是使类之间的关系更加明确。

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

关联关系可以细分为6种。

双向关联

默认情况下，关联是双向的。例如，顾客(Customer)购买商品(Product)并拥有商品；反之，卖出的商品总有某个顾客与之相关联。因此，Customer类和Product类之间具有双向关联关系，用直线表示，如图所示。

单向关联

类的关联关系也可以是单向的，单向关联用带箭头的实线表示。例如，顾客(Customer)拥有地址(Address),则Customer类与Address类具有单向关联关系。与第一个图LoginForm - JButton的关系一样。用直线加箭头表示。

自关联

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

多重性关联

又称为重数性关联关系（Multiplicity），表示一个类的对象与另一个类的对象连接的个数。

在UML中多重性关联关系可以直接在关联直线上增加一个数字表示与之对应的另一个类的对象的个数。

• 下表：多重性表示方式列表

例如，一个界面(Form)可以拥有0个或多个按钮(Button)，但是一个按钮只能属于一个界面。因此，一个Form类的对象可以与0个或多个Button类的对象相关联，但一个Button类的对象只能与一个Form类的对象关联，如图。

聚合关系

聚合关系（Aggregation）表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。如一台计算机包含显示器、主机、键盘、鼠标等部分，就可以使用聚合关系来描述整体与部分之间的关系。

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

Car中定义了一个Engine类型的成员变量，从语义上来说，Engine是Car的一部分，但是Engine对象可以脱离Car单独存在。因此，在类Car中并不直接实例化Engine，而是通过构造函数或者setter设值将在类外部实例化好的Engine对象以参数形式传入Car中，这种传入方式称为注入（Injection）。正因为Car和Engine的实例化时刻不相同，因此它们之间不存在生命周期的制约关系，而仅仅只是整体与部分之间的关系而已。

组合关系

组合关系（Composition）也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。例如一个界面对象与其包含的按钮、文本框、静态文本等成员对象，如果界面对象在内存中被销毁，则所有成员均被销毁。

在组合关系中，成员类是整体类的一部分，而且整体类可以控制成员类的生命周期，即成员类的存在依赖于整体类。

在UML中，组合关系用带实心菱形的直线表示。例如，人的头(Head)与嘴巴(Mouth)，嘴巴是头的组成部分之一，而且如果头没了，则嘴巴也就没了，因此头和嘴巴是组合关系，如图所示。

Head中定义了一个Mouth类型的成员，而且在Head的构造函数中实例化Mouth对象，因此在创建Head对象的同时将创建Mouth对象，在销毁Head对象的同时销毁Mouth对象。它们之间不仅仅只是整体与部分之间的关系，而且整体还可以控制部分的生命周期。

• 聚合和组合的对比
  • 聚合关系表示整体与部分的关系比较弱，而组合关系比较强；
  • 聚合关系中代表部分事物的对象与代表整体事物的对象的生存期无关，删除整体对象并不表示部分对象被删除。
  • 从代码实现的角度来看也略有区别，聚合关系通过对象注入的方式来实现，而组合关系通过在整体类的构造函数中实例化成员类来实现。
  • 但是它们的共同点是一个类的实例为另一个类的成员对象。

聚合关系和组合关系与普通的关联关系主要是语义上的区别，如表示客户类与产品类的关系就不能用聚合和组合，因为产品并不是客户的一部分，不存在整体与部分关系，只能用普通的关联关系。

依赖关系

依赖关系（Dependency）是一种使用关系，被使用者的改变有可能会影响到使用者，在需要表示一个事物使用另一个事物时使用依赖关系。

大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。

在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。例如，驾驶员开车，在Driver类的drive()方法中将Car类型的对象car作为一个参数传递，以便在drive()方法中能够调用car的move()方法，且驾驶员的drive()方法依赖车的move()方法，因此类Driver依赖类Car，如图所示。

在具体实现时：

1. 如果在一个类的方法中调用了另一个类的静态方法；或：
2. 在一个类的函数中定义了另一个类的对象作为其局部变量

也是依赖关系的表现形式，但是这个关系需要在实现阶段慢慢浮现出来，在分析设计阶段可以暂时不予考虑。

泛化关系

泛化关系（Generalization）也就是继承关系，也称为“is-a-kind-of”关系。

泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。

在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()，如图所示。

接口与实现关系

在很多面向对象语言中都引入了接口的概念，如Java、C#等。在接口中，一般没有属性，而且所有的操作都是抽象的，只有操作的声明，没有操作的实现。

UML中用与类的表示法类似的方式表示接口，如图所示。

接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系（Realization）。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。

在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。例如，定义了一个交通工具接口Vehicle，其中有一个抽象操作move()，在类Ship和类Car中都实现了该move()操作，不过具体的实现细节将会不一样，如图所示。

实现关系在用代码实现时，不同的面向对象语言也提供了不同的语法，如在Java语言中使用implements关键字，在C++/C#中使用冒号:来实现。

参考文献

1

[1] 刘伟. 设计模式.

内容

1. 引述
2. 建造者模式概述
3. 引入抽象工厂
4. 抽象工厂模式概述
5. 解决方案

引述

没有人买车会只买一个轮胎或者方向盘，大家买的都是一辆包含轮胎、方向盘和发动机等多个部件的完整汽车。如何将这些部件组装成一辆完整的汽车并返回给用户，这是建造者模式需要解决的问题。建造者模式又称为生成器模式，它是一种较为复杂、使用频率也相对较低的创建型模式。建造者模式为客户端返回的不是一个简单的产品，而是一个由多个部件组成的复杂产品。

案例-游戏角色设计

该软件公司游戏开发小组决定开发一款名为《仙魔群侠传》的网络游戏，该游戏采用主流的RPG(Role Playing Game,角色扮演游戏)模式，玩家可以在游戏中扮演虚拟世界中的一个特定角色，角色根据不同的游戏情节和统计数据（如力量、魔法、技能等）具有不同的能力，角色也会随着不断升级而拥有更加强大的能力。

作为RPG游戏的一个重要组成部分，需要对游戏角色进行设计，而且随着该游戏的升级将不断增加新的角色。不同类型的游戏角色，其性别、脸型、服装、发型等外部特性都有所差异，例如“天使”拥有美丽的面容和披肩的长发，并身穿一袭白裙；而“恶魔”极其丑陋，留着光头并穿一件刺眼的黑衣。

该公司决定开发一个小工具来创建游戏角色，可以创建不同类型的角色并可以灵活增加新的角色。

该司的开发人员通过分析发现，游戏角色是一个复杂对象，它包含性别、脸型等多个组成部分，不同的游戏角色其组成部分有所差异，如图所示：

无论是何种造型的游戏角色，它的创建步骤都大同小异，都需要逐步创建其组成部分，再将各组成部分装配成一个完整的游戏角色。如何一步步创建一个包含多个组成部分的复杂对象，建造者模式为解决此类问题而诞生。

建造者模式概述

建造者模式是较为复杂的创建型模式，它将客户端与包含多个组成部分（或部件）的复杂对象的创建过程分离，客户端无须知道复杂对象的内部组成部分与装配方式，只需要知道所需建造者的类型即可。它关注如何一步一步创建一个的复杂对象，不同的具体建造者定义了不同的创建过程，且具体建造者相互独立，增加新的建造者非常方便，无须修改已有代码，系统具有较好的扩展性。

定义

建造者模式(Builder Pattern)：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一种对象创建型模式。

结构

建造者模式一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。建造者模式结构如图所示：

角色

在建造者模式结构图中包含如下几个角色：

• Builder（抽象建造者）：Builder既可以是抽象类，也可以是接口。它为创建一个产品Product对象的各个部件指定抽象接口。在该接口中一般声明两类方法。
  • 一类方法是buildPartX()，它们用于创建复杂对象的各个部件
  • 另一类方法是getResult()，它们用于返回复杂对象。
• ConcreteBuilder（具体建造者）
  • 它实现了Builder接口，实现各个部件的具体构造和装配方法，定义并明确它所创建的复杂对象，也可以提供一个方法返回创建好的复杂产品对象。
• Product（产品角色）
  • 它是被构建的复杂对象，包含多个组成部件，具体建造者创建该产品的内部表示并定义它的装配过程。
• Director（指挥者）：指挥者又称为导演类，它负责安排复杂对象的建造次序。
  • 指挥者与抽象建造者之间存在关联关系，可以在其construct()建造方法中调用建造者对象的部件构造与装配方法，完成复杂对象的建造。
  • 客户端一般只需要与指挥者进行交互，在客户端确定具体建造者的类型，并实例化具体建造者对象（也可以通过配置文件和反射机制），然后通过指挥者类的构造函数或者Setter方法将该对象传入指挥者类中。

代码

• 产品类

在建造者模式的定义中提到了复杂对象，那么什么是复杂对象？简单来说，复杂对象是指那些包含多个成员属性的对象，这些成员属性也称为部件或零件，如汽车包括方向盘、发动机、轮胎等部件，电子邮件包括发件人、收件人、主题、内容、附件等部件，一个典型的复杂对象类代码示例如下：

1
2
3
4
5
6
7
8
9
10

class Product  
{
private:
    String partA; //定义部件，部件可以是任意类型，包括值类型和引用类型
    String partB;
    String partC;
    //partA的Getter方法和Setter方法省略
    //partB的Getter方法和Setter方法省略
    //partC的Getter方法和Setter方法省略
};

• 抽象建造者类

在抽象建造者类中定义了产品的创建方法和返回方法，其典型代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class Builder
{
protected:
    //创建产品对象
    Product * product;//Product product=new Product();
public:
    void buildPartA() = 0;
    void buildPartB() = 0;
    void buildPartC() = 0;
    //返回产品对象
	Product* getResult()
    {
        return product;
    }
};

在抽象类Builder中声明了一系列抽象的buildPartX()方法用于创建复杂产品的各个部件，具体建造过程在ConcreteBuilder中实现，此外还提供了工厂方法getResult()，用于返回一个建造好的完整产品。

• 具体建造者类

在ConcreteBuilder中实现了buildPartX()方法，通过调用Product的setPartX()方法可以给产品对象的成员属性设值。不同的具体建造者在实现buildPartX()方法时将有所区别，如setPartX()方法的参数可能不一样，在有些具体建造者类中某些setPartX()方法无须实现（提供一个空实现）。而这些对于客户端来说都无须关心，客户端只需知道具体建造者类型即可。

• 指挥者类

在建造者模式的结构中还引入了一个指挥者类Director，该类主要有两个作用：一方面它隔离了客户与创建过程；另一方面它控制产品的创建过程，包括某个buildPartX()方法是否被调用以及多个buildPartX()方法调用的先后次序等。指挥者针对抽象建造者编程，客户端只需要知道具体建造者的类型，即可通过指挥者类调用建造者的相关方法，返回一个完整的产品对象。在实际生活中也存在类似指挥者一样的角色，如一个客户去购买电脑，电脑销售人员相当于指挥者，只要客户确定电脑的类型，电脑销售人员可以通知电脑组装人员给客户组装一台电脑。指挥者类的代码示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class Director
{
private:
    Builder * builder;
public:
    Director(Builder* builder)
    {
    	this.builder = builder;
    }
    void setBuilder(Builder* builder)
    {
    	this.builder = builer;
    }
    //产品构建与组装方法
    Product* construct()
    {
        builder->buildPartA();
        builder->buildPartB();
        builder->buildPartC();
        return builder->getResult();
    }
};

在指挥者类中可以注入一个抽象建造者类型的对象，其核心在于提供了一个建造方法construct()，在该方法中调用了builder对象的构造部件的方法，最后返回一个产品对象。

• 客户端

对于客户端而言，只需关心具体的建造者即可，一般情况下，客户端类代码片段如下所示：

1
2
3

Builder* builder = new ConcreteBuilder(); //可通过配置文件实现
Director* director = new Director(builder);
Product* product = director->construct();

可以通过配置文件来存储具体建造者类ConcreteBuilder的类名，使得更换新的建造者时无须修改源代码，系统扩展更为方便。在客户端代码中，无须关心产品对象的具体组装过程，只需指定具体建造者的类型即可。

与抽象工厂模式的对比

建造者模式与抽象工厂模式有点相似，但是

• 建造者模式返回一个完整的复杂产品，而抽象工厂模式返回一系列相关的产品；
• 在抽象工厂模式中，客户端通过选择具体工厂来生成所需对象，而在建造者模式中，客户端通过指定具体建造者类型并指导Director类如何去生成对象，侧重于一步步构造一个复杂对象，然后将结果返回。
• 如果将抽象工厂模式看成一个汽车配件生产厂，生成不同类型的汽车配件，那么建造者模式就是一个汽车组装厂，通过对配件进行组装返回一辆完整的汽车。

完整解决方案

该公司开发人员决定使用建造者模式来实现游戏角色的创建，其基本结构如图所示：

在图中，ActorController充当指挥者，ActorBuilder充当抽象建造者，HeroBuilder、AngelBuilder和DevilBuilder充当具体建造者，Actor充当复杂产品。

指挥者类ActorController需要定义construct()方法，该方法拥有一个抽象建造者ActorBuilder类型的参数，在该方法内部实现了游戏角色对象的逐步构建。

为了提高系统的灵活性和可扩展性，最好将具体建造者类的类名存储在配置文件中，并通过某个工具类Util来读取配置文件并反射生成对象。

总结

建造者模式的核心在于如何一步步构建一个包含多个组成部件的完整对象，使用相同的构建过程构建不同的产品，在软件开发中，如果我们需要创建复杂对象并希望系统具备很好的灵活性和可扩展性可以考虑使用建造者模式。

主要优点

• 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
• 每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。由于指挥者类针对抽象建造者编程，增加新的具体建造者无须修改原有类库的代码，系统扩展方便，符合“开闭原则”
• 可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。

主要缺点

• 建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，例如很多组成部分都不相同，不适合使用建造者模式，因此其使用范围受到一定的限制。
• 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大，增加系统的理解难度和运行成本。

适用场景

• 需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员属性。
• 需要生成的产品对象的属性相互依赖，需要指定其生成顺序。
• 对象的创建过程独立于创建该对象的类。在建造者模式中通过引入了指挥者类，将创建过程封装在指挥者类中，而不在建造者类和客户类中。
• 隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。

在建造者模式中，客户端只需实例化指挥者类，指挥者类针对抽象建造者编程，客户端根据需要传入具体的建造者类型，指挥者将指导具体建造者一步一步构造一个完整的产品（逐步调用具体建造者的buildX()方法），相同的构造过程可以创建完全不同的产品。

在游戏角色实例中，如果需要更换角色，只需要修改配置文件，更换具体角色建造者类即可；

如果需要增加新角色，可以增加一个新的具体角色建造者类作为抽象角色建造者的子类，再修改配置文件即可，原有代码无须修改，完全符合“开闭原则”。

参考文献

1

[1] 刘伟. 设计模式.