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

2.1概述

1．UML特性

（1）UML融合了多种优秀的面向对象建模方法以及多种得到认可的软件工程方法，消除了因方法林立且相互独立而带来的种种不便，集百家之所长，故名“统一（Unified）”。UML通过统一的表示方法，让不同知识背景的领域专家、系统分析设计人员和开发人员以及用户可以方便地交流。
（2）UML是一种通用的可视化建模（Modeling）语言，不同于编程语言，它通过一些标准的图形符号和文字来对系统进行建模，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，UML是一种总结了以往建模技术的经验并吸收了当今最优秀成果的标准建模方法。
（3）UML是一种语言（Language），也就意味着它有属于自己的标准表达规则，它不是一种类似Java、C++、C＃的编程语言，而是一种分析设计语言，也就是一种建模语言。

2．UML结构

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

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

（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图示

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

类

类（Class）封装了数据和行为，是面向对象的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称。在系统中，每个类都具有一定的职责。职责指的是类要完成什么样的功能，要承担什么样的义务。一个类可以有多种职责，设计得好的类一般只有一种职责。在定义类的时候，将类的职责分解成为类的属性和操作（即方法）。类的属性即类的数据职责，类的操作即类的行为职责。设计类是面向对象设计中最重要的组成部分，也是最复杂和最耗时的部分。
类图（Class Diagram）是用出现在系统中的不同类来描述系统的静态结构，主要用来描述不同的类以及它们之间的关系。
类一般由三部分组成。
（1）类名：每个类都必须有一个名字，类名是一个字符串。
（2）类的属性（Attributes）：属性是指类的性质，即类的成员变量。一个类可以有任意多个属性，也可以没有属性。可见性 名称:类型[=默认值]
（3）类的操作（Operations）：操作是类的任意一个实例对象都可以使用的行为，是类的成员方法。
可见性 名称([参数列表])[:返回类型]

2.3　类之间的关系

1.关联关系

一个类的对象作为另一个类的成员变量

1)双向关联

2)单向关联

3）自关联

4）多重性关联

5）聚合关系

聚合（Aggregation）关系表示整体与部分的关系。在聚合关系中，成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在
聚合关系用带空心菱形的直线表示,在代码实现聚合关系时，成员对象通常作为构造方法、Setter方法或业务方法的参数注入整体对象中

6）组合关系

组合（Composition）关系也表示类之间整体和部分的关系，但是在组合关系中整体对象可以控制成员对象的生命周期
一旦整体对象不存在，成员对象也将不存在，成员对象与整体对象之间具有同生共死的关系。
在UML中，组合关系用带实心菱形的直线表示

2.依赖关系

依赖（Dependency）关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。
大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方

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

3．泛化关系

泛化（Generalization）关系也就是继承关系，用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。
在UML中，泛化关系用带空心三角形的直线来表示

4．接口与实现关系

接口之间也可以有与类之间关系类似的继承关系和依赖关系
接口和类之间还存在一种实现（Realization）关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。
在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示

2.4 面向对象设计原则概述

单一职责原则

一个类只负责一个功能领域中的相应职责。或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

开闭原则Open-Closed Principle，OCP

一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展

里氏代换原则Open-Closed Principle，OCP

所有引用基类（父类）的地方必须能透明地使用其子类的对象。

依赖倒转原则Dependency Inversion Principle，DIP

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

开闭原则是目标，里氏代换原则是基础，依赖倒转原则是手段，它们相互补充，相辅相成，目标一致，只是分析问题时所站角度不同而已。

接口隔离原则Interface Segregation Principle，ISP

使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

合成复用原则Composite Reuse Principle，CRP

尽量使用对象组合和聚合，而不是继承来达到复用的目的。
一般而言，如果两个类之间是“Has-A”的关系，应使用组合或聚合；如果是“Is-A”关系，可使用继承

迪米特法则Law of Demeter，LoD

一个软件实体应当尽可能少地与其他实体发生相互作用。