设计模式的那些东西_某系统需要实现对重要数据(如用户密码)的加密处理,在数据操作类(dataoperator)中

设计模式的那些东西

UML的结构

视图(View)

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

图(Diagram)

• 用例图(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)

模型元素(Model Element)

• 模型元素包括事物以及事物与事物之间的关系
• 事物是UML的重要组成部分，它代表任何可以定义的东西
• 事物之间的关系把事物联系在一起，组成有意义的结构模型
• 每一个模型元素都有一个与之相对应的图形元素
• 同一个模型元素可以在不同的UML图中使用
• 但无论在哪个图中，同一个模型元素都保持相同的意义和符号

通用机制(General Mechanism)

UML提供的通用机制为模型元素提供额外的注释、语义和其他信息，包括扩展机制，允许用户对UML进行扩展

类图

类与类图

• 类(Class)封装了数据和行为，是面向对象的重要组成部分
• 类是具有相同属性、操作、关系的对象集合的总称
• 在系统中，每个类具有一定的职责，职责指的是类所担任的任务，即类要完成什么样的功能，要承担什么样的义务。一个类可以有多种职责，设计得好的类一般只有一种职责
• 类的属性即类的数据职责，类的操作即类的行为职责
• 类图(Class Diagram)使用出现在系统中的不同类来描述系统的静态结构，它用来描述不同的类以及它们之间的关系

类的UML图示

在UML类图中，类一般由三部分组成：
第一部分是类名：每个类都必须有一个名字，类名是一个字符串
第二部分是类的属性(Attributes)：属性是指类的性质，即类的成员变量。一个类可以有任意多个属性，也可以没有属性
第三部分是类的操作(Operations)：操作是类的任意一个实例对象都拥有的行为，是类的成员方法

类之间的关系

关联关系

关联(Association)关系是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系
在UML类图中，用实线连接有关联关系的对象所对应的类，在使用Java、C++和C#等编程语言实现关联关系时，通常将一个类的对象作为另一个类的成员变量
在使用类图表示关联关系时可以在关联线上标注角色名

单向关联

public class Customer {
    private Address address;
    ……
}

public class Address {
    ……
}
1
2
3
4
5
6
7
8

双向关联

public class Customer {
    private Product[] products;
    ……
}

public class Product{
    private Customer customer;
    ……
}
1
2
3
4
5
6
7
8
9

自关联

public class Node {
    private Node subNode;
    ……
} 
1
2
3
4

多重性关联

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

public class Form {
    private Button[] buttons; //定义一个集合对象
    ……
} 
public class Button {
    …
}
1
2
3
4
5
6
7

聚合关联

• 聚合(Aggregation)关系表示整体与部分的关系
• 在聚合关系中，成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在
• 在UML中，聚合关系用带空心菱形的直线表示

public class Car {
    private Engine engine;
    public Car(Engine engine) {    //构造注入
        this.engine = engine;
    }
    
    public void setEngine(Engine engine) {    //设值注入
        this.engine = engine;
    }
    ……
}

public class Engine {
    ……
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

组合关联

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

public class Head {
    private Mouth mouth;
    public Head() {
        mouth = new Mouth();  //实例化成员类
    }
    ……
}

public class Mouth {
    ……
}
1
2
3
4
5
6
7
8
9
10
11

依赖关系

• 依赖(Dependency)关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系
• 大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数
• 在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方
• 在系统实现阶段，依赖关系通常通过三种方式来实现：
  1. 将一个类的对象作为另一个类中方法的参数
  2. 在一个类的方法中将另一个类的对象作为其局部变量
  3. 在一个类的方法中调用另一个类的静态方法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5FPtRhEH-1610718893316)(http://img.mini.hutang.site/mweb/15771511465403.jpg)]

public class Driver {
    public void drive(Car car)
    {
        car.move();
    }
    ……
}
public class Car {
    public void move() {
        ......
    }
    ……
}
1
2
3
4
5
6
7
8
9
10
11
12
13

泛化关系

• 泛化(Generalization)关系也就是继承关系，用于描述父类与子类之间的关系，父类又称为基类或超类，子类又称为派生类
• 在UML中，泛化关系用带空心三角形的直线来表示
• 在代码实现时，使用面向对象的继承机制来实现泛化关系，**在Java语言中使用extends关键字、在C++/C#中使用冒号“：”**来实现

//父类
public class Person {
    protected String name;
    protected int age;
    public void move()  {
        ……
    }
    public void say() {
        ……
    }
}

//子类
public class Student extends Person  {
    private String studentNo;
    public void study()  {
        ……
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

接口与实现关系

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

public interface Vehicle {
    public void move();
}

public class Ship implements Vehicle {
    public void move() {
        ……
    }
}

public class Car implements Vehicle {
    public void move() {
        ……
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

面向对象设计原则

• 可维护性(Maintainability)：指软件能够被理解、改正、适应及扩展的难易程度
• 可复用性(Reusability)：指软件能够被重复使用的难易程度
• 面向对象设计的目标之一在于支持可维护性复用，一方面需要实现设计方案或者源代码的复用，另一方面要确保系统能够易于扩展和修改，具有良好的可维护性
• 面向对象设计原则为支持可维护性复用而诞生
• 指导性原则，非强制性原则
• 每一个设计模式都符合一个或多个面向对象设计原则，面向对象设计原则是用于评价一个设计模式的使用效果的重要指标之一

单一职责原则

定义

• 单一职责原则是最简单的面向对象设计原则，用于控制类的粒度大小
• 就一个类而言，应该仅有一个引起它变化的原因
• There should never be more than one reason for a class to change.

单一职责原则：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
Single Responsibility Principle (SRP): Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.

分析

• 一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小
• 当一个职责变化时，可能会影响其他职责的运作
• 将这些职责进行分离，将不同的职责封装在不同的类中
• 将不同的变化原因封装在不同的类中
• 单一职责原则是实现高内聚、低耦合的指导方针

实例

• 某基于Java的C/S系统的“登录功能”通过如下登录类(Login)实现：

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

开闭原则

定义

开闭原则是面向对象的可复用设计的第一块基石，是最重要的面向对象设计原则

开闭原则：软件实体应当对扩展开放，对修改关闭。
Open-Closed Principle (OCP): Software entities should be open for extension, but closed for modification.

分析

• 在开闭原则的定义中，软件实体可以是一个软件模块、一个由多个类组成的局部结构或一个独立的类
• 开闭原则是指软件实体应尽量在不修改原有代码的情况下进行扩展
• 抽象化是开闭原则的关键
• 相对稳定的抽象层 + 灵活的具体层
• 对可变性封装原则(Principle of Encapsulation of Variation, EVP)：找到系统的可变因素并将其封装起来

实例

• 某图形界面系统提供了各种不同形状的按钮，客户端代码可针对这些按钮进行编程，用户可能会改变需求要求使用不同的按钮，原始设计方案如图所示：

• 现对该系统进行重构，使之满足开闭原则的要求。

里氏代换原则

定义

里氏代换原则：所有引用基类的地方必须能透明地使用其子类的对象。
Liskov Substitution Principle (LSP): Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

分析

• 在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常
• 反过来则不一定成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象
• 在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型

实例

某系统需要实现对重要数据（如用户密码）的加密处理，在数据操作类(DataOperator)中需要调用加密类中定义的加密算法，系统提供了两个不同的加密类，CipherA和CipherB，它们实现不同的加密方法，在DataOperator中可以选择其中的一个实现加密操作。如图所示：

如果需要更换一个加密算法类或者增加并使用一个新的加密算法类，如将CipherA改为CipherB，则需要修改客户类Client和数据操作类DataOperator的源代码，违背了开闭原则。
现使用里氏代换原则对其进行重构，使得系统可以灵活扩展，符合开闭原则。

依赖倒转原则

定义

依赖倒转原则：高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
Dependency Inversion Principle (DIP): High level modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.

要针对接口编程，不要针对实现编程
Program to an interface, not an implementation.

分析

• 在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等
• 在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中
• 针对抽象层编程，将具体类的对象通过**依赖注入(Dependency Injection, DI)**的方式注入到其他对象
  • 构造注入
  • 设值注入（Setter注入）
  • 接口注入

实例

某系统提供一个数据转换模块，可以将来自不同数据源的数据转换成多种格式，如可以转换来自数据库的数据(DatabaseSource)、也可以转换来自文本文件的数据(TextSource)，转换后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。

由于需求的变化，该系统可能需要增加新的数据源或者新的文件格式，每增加一个新的类型的数据源或者新的类型的文件格式，客户类MainClass都需要修改源代码，以便使用新的类，但违背了开闭原则。现使用依赖倒转原则对其进行重构。

接口隔离原则

定义

接口隔离原则：客户端不应该依赖那些它不需要的接口。
Interface Segregation Principle (ISP): Clients should not be forced to depend upon interfaces that they do not use.

分析

• 当一个接口太大时，需要将它分割成一些更细小的接口
• 使用该接口的客户端仅需知道与之相关的方法即可
• 每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干
• “接口”定义(1)：一个类型所提供的所有方法特征的集合。一个接口代表一个角色，每个角色都有它特定的一个接口，“角色隔离原则”
• “接口”定义(2)：狭义的特定语言的接口。接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口，每个接口中只包含一个客户端所需的方法，“定制服务”

实例

下图展示了一个拥有多个客户类的系统，在系统中定义了一个巨大的接口（胖接口）AbstractService来服务所有的客户类。可以使用接口隔离原则对其进行重构

合成复用原则

定义

合成复用原则又称为组合/聚合复用原则(Composition/ Aggregate Reuse Principle, CARP)

合成复用原则：优先使用对象组合，而不是继承来达到复用的目的。
Composite Reuse Principle (CRP)：Favor composition of objects over inheritance as a reuse mechanism.

分析

• 合成复用原则就是在一个新的对象里通过**关联关系（包括组合关系和聚合关系）**来使用一些已有的对象，使之成为新对象的一部分
• 新对象通过委派调用已有对象的方法达到复用功能的目的
• 复用时要尽量使用组合/聚合关系（关联关系），少用继承
• 继承复用：实现简单，易于扩展。破坏系统的封装性；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；只能在有限的环境中使用。（“白箱”复用）
• 组合/聚合复用：耦合度相对较低，有选择性地调用成员对象的操作；可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。（“黑箱”复用）

实例

某教学管理系统部分数据库访问类设计如图所示:

如果需要更换数据库连接方式，如原来采用JDBC连接数据库，现在采用数据库连接池连接，则需要修改DBUtil类源代码。如果StudentDAO采用JDBC连接，但是TeacherDAO采用连接池连接，则需要增加一个新的DBUtil类，并修改StudentDAO或TeacherDAO的源代码，使之继承新的数据库连接类，这将违背开闭原则，系统扩展性较差。
现使用合成复用原则对其进行重构。

迪米特法则

定义

迪米特法则又称为最少知识原则(Least Knowledge Principle, LKP)

迪米特法则：每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
Law of Demeter (LoD): Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.

分析

• 迪米特法则要求一个软件实体应当尽可能少地与其他实体发生相互作用
• 应用迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系
• 迪米特法则要求在设计系统时，应该尽量减少对象之间的交互
• 如果两个对象之间不必彼此直接通信，那么这两个对象就不应该发生任何直接的相互作用
• 如果其中一个对象需要调用另一个对象的方法，可以通过“第三者”转发这个调用
• 通过引入一个合理的“第三者”（中间类）来降低现有对象之间的耦合度

实例

某系统界面类(如Form1、Form2等类)与数据访问类(如DAO1、DAO2等类)之间的调用关系较为复杂，如图所示：

设计模式概述

模式

• 模式(Pattern)起源于建筑业而非软件业
• 模式
  • Context（模式可适用的前提条件）
  • Theme或Problem（在特定条件下要解决的目标问题）
  • Solution（对目标问题求解过程中各种物理关系的记述）
• 每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，人们可以无数次地重用那些已有的解决方案，无需再重复相同的工作
• 模式是在特定环境中解决问题的一种方案 (A pattern is a solution to a problem in a context)

软件模式

软件模式：在一定条件下的软件开发问题及其解法

• 问题描述
• 前提条件（环境或约束条件）
• 解法
• 效果
  

定义

设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结
使用设计模式是为了可重用代码、让代码更容易被他人理解、提高代码的可靠性

基本要素

设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式，其中的关键元素包括以下四个方面：

• 模式名称 (Pattern name)
• 问题 (Problem)
• 解决方案 (Solution)
• 效果 (Consequences)

分类

• 根据目的（模式是用来做什么的）可分为创建型(Creational)，**结构型(Structural)和行为型(Behavioral)**三类：
  1. 创建型模式主要用于创建对象
  2. 结构型模式主要用于处理类或对象的组合
  3. 行为型模式主要用于描述类或对象如何交互和怎样分配职责
• 根据范围，即模式主要是处理类之间的关系还是处理对象之间的关系，可分为类模式和对象模式两种：
  1. 类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是一种静态关系