设计模式

一、基础知识

1、设计模式概述

1.1、设计模式是什么

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

设计模式一般包含模式名称、问题、目的、解决方案、效果等组成要素，其中关键要素是模式名称、问题、解决方案和效果。模式名称（Pattern Name）通过一两个词来为模式命名，以便我们更好地理解模式并方便开发人员之间的交流，绝大多数模式都是根据其功能或模式结构来命名的（GoF设计模式中没有一个模式用人名命名）；问题（Problem）描述了应该在何时使用模式，它包含了设计中存在的问题以及问题存在的原因；解决方案（Solution）描述了一个设计模式的组成部分，以及这些组成部分之间的相互关系、各自的职责和协作方式，通常解决方案通过UML类图和核心代码进行描述；效果（Consequence）描述了模式的优缺点以及在使用模式时应权衡的问题。

1.2、设计模式作用

1. 设计模式来源于众多专家的经验和智慧，它们是从许多优秀的软件系统中总结出的成功的、能够实现可维护性复用的设计方案，使用这些方案可以避免做一些重复性的工作，有助于提高设计和开发效率。
2. 设计模式提供了一套通用的设计词汇和一种通用的形式来方便开发人员之间进行沟通和交流，使得设计方案更加通俗易懂。交流通常很耗时，任何有助于提高交流效率的东西都可以为开发人员节省不少时间。无论使用哪种编程语言，做什么类型的项目，甚至一个国际化的开发团队，当面对同一个设计模式时，大家的理解并无歧义，因为设计模式是跨语言、跨平台、跨应用、跨国界的。
3. 大部分设计模式都兼顾了系统的可重用性和可扩展性，这使得开发人员可以更好地重用一些已有的设计方案、功能模块甚至一个完整的软件系统，避免经常做一些重复的设计、编写一些重复的代码。此外，随着软件规模的日益增大，软件寿命的日益变长，系统的可维护性和可扩展性也越来越重要，许多设计模式将有助于提高系统的灵活性和可扩展性，在不修改或者少修改现有系统的基础上增加、删除或者替换功能模块，如果一点设计模式都不懂，要做到这一点还是很困难的。
4. 合理使用设计模式并对设计模式的使用情况进行文档化，将有助于别人更快地理解系统。对于离职人员的项目，只要接手人员也懂设计模式，就能够很快理解该项目的设计思路和实现方案，使得后续工作顺利进行。
5. 最后一点对初学者很重要，学习设计模式将有助于初学者更加深入地理解面向对象思想。例如，如何将代码分散在几个不同的类中？为什么要有“接口”？何谓针对抽象编程？何时不应该使用继承？如何不修改源代码增加新功能？同时还能够更好地阅读和理解现有类库（如JDK）与其他系统中的源代码，早点脱离面向对象编程的“菜鸟期”。

2、面向对象设计原则与UML类图

2.1、UML类图

UML类图可用于描述每一个设计模式的结构以及对模式实例进行说明，而模式结构又是设计模式解法的核心组成部分。

UML特性：

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

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）**是用出现在系统中的不同类来描述系统的静态结构，主要用来描述不同的类以及它们之间的关系。

对应的Java代码片段如下：

/**
 * @Description:
 * @Author: yangyongbing
 * @CreateTime: 2023/07/05  15:40
 * @Version: 1.0
 */
public class ResponseResult<T>{
    private Integer code;
    private String message;
    private T data ;

    public ResponseResult(Integer code, String message, T data) {
        this.code = code;
        this.message = message;
        this.data = data;
    }

    public Integer getCode() {
        return code;
    }

    public void setCode(Integer code) {
        this.code = code;
    }

    public String getMessage() {
        return message;
    }

    public void setMessage(String message) {
        this.message = message;
    }

    public T getData() {
        return data;
    }

    public void setData(T data) {
        this.data = data;
    }
}

在UML类图中，类一般由三部分组成。
（1）类名：每个类都必须有一个名字，类名是一个字符串。
（2）类的属性（Attributes）：属性是指类的性质，即类的成员变量。一个类可以有任意多个属性，也可以没有属性。UML规定属性的表示方式为：
3）类的操作（Operations）：操作是类的任意一个实例对象都可以使用的行为，是类的成员方法。UML规定操作的表示方式为：

2.3、类之间的关系

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

1、关联关系

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

public class LoginForm {
   private JButton loginButton;// 定义为成员变量
   .......
}

public class JButton {
   .......
}

在UML中，关联关系通常又包含如下几种形式。
1）双向关联
默认情况下，关联是双向的。例如，顾客（Customer）购买商品（Product）并拥有商品，反之，卖出的商品总有某个顾客与之相关联。因此，Customer类和Product类之间具有双向关联关系：

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

public class Product{
   private Customer customer;
   .....
}

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

public class Customer {
  
  private Address address;
  ...
}

public class Address {
   ...
}

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

public class Node {
    private Node subNode;
}

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

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

public class Form {
   private Button[] buttons;
   ...
}

public class Button {
   ...
}

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

在代码实现聚合关系时，成员对象通常作为构造方法、Setter方法或业务方法的参数注入整体对象中:

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

public class Engine{
    .......
}

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

public class Head{
   private Mouth mouth;

   public Head(){
       mouth=new Mouth();
    }
}

public class Mouth{
   ...
}

2、依赖关系

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

public class Driver{
   public void drive(Car car){
        car.move();
   }
   ...
}

public class Car{
    public void move(){
        ...
    }
    ...
}

在系统实施阶段，依赖关系通常通过3种方式来实现：

• 将一个类的对象作为另一个类中方法的参数；
• 在一个类的方法中将另一个类的对象作为其局部变量；
• 在一个类的方法中调用另一个类的静态方法；

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（）。

// 父类
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(){
      ...
   }
}

// 子类
public class Student extends Person{
   private String teacherNo;

   public void teach(){
      ...
   }
}

4、接口与实现关系

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

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

public interface Vehicle{
  public void move();
}

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

public class Car implements Vehicle{
   public void move(){
      ...
   }
}

3、面向对象设计原则

面向对象设计的目标之一在于支持可维护性复用，一方面需要实现设计方案或者源代码的重用，另一方面要确保系统能够易于扩展和修改，具有较好的灵活性。面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则。面向对象设计原则也是用于评价一个设计模式的使用效果的重要指标之一。

7种常用的面向对象设计原则：

3.1、单一职责原则

单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。单一职责原则定义如下：
单一职责原则（Single Responsibility Principle，SRP）：一个类只负责一个功能领域中的相应职责。或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

单一职责原则是实现高内聚、低耦合的指导方针。

3.2、开闭原则

开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则。
开闭原则（Open-Closed Principle，OCP）：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
在开闭原则的定义中，软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。
任何软件都需要面临一个很重要的问题，即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时，应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行扩展，而且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大，软件寿命越来越长，软件维护成本越来越高，设计满足开闭原则的软件系统也变得越来越重要。
为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。在Java、C＃等编程语言中，可以为系统定义一个相对稳定的抽象层，而将不同的实现行为移至具体的实现层中完成。在很多面向对象编程语言中都提供了接口、抽象类等机制，可以通过它们定义系统的抽象层，再通过具体类来进行扩展。如果需要修改系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

3.3、里氏代换原则

如果对每个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。这个定义比较拗口且难以理解，因此一般使用它的另一个通俗版定义：
里氏代换原则（Liskov Substitution Principle，LSP）：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
里氏代换原则表明，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。如果一个软件实体使用的是一个子类对象，那么它不一定能够使用基类对象。例如，我喜欢动物，那我一定喜欢狗，因为狗是动物的子类；但是我喜欢狗，不能据此断定我喜欢动物，因为我并不喜欢老鼠，虽然它也是动物。
里氏代换原则是实现开闭原则的重要方式之一。由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。
在运用里氏代换原则时，应该将父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法。程序运行时，子类实例替换父类实例，可以很方便地扩展系统的功能，无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。

3.4、依赖倒转原则

如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要实现机制之一，它是系统抽象化的具体实现。
依赖倒转原则（Dependency Inversion Principle，DIP）：抽象不应该依赖于细节，细节应该依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
依赖倒转原则要求在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。
在引入抽象层后，系统将具有很好的灵活性。在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中。这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，就能扩展系统的功能，满足开闭原则的要求。
在实现依赖倒转原则时，需要针对抽象层编程，而将具体类的对象通过依赖注入（Dependency Injection，DI）的方式注入其他对象中。
依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有3种：构造注入、设值注入（Setter注入）和接口注入。

• 构造注入是指通过构造函数来传入具体类的对象
• 设值注入是指通过Setter方法来传入具体类的对象
• 而接口注入是指通过实现在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象来覆盖父类对象。

3.5、接口隔离原则

接口隔离原则（Interface Segregation Principle，ISP）：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
根据接口隔离原则，当一个接口太大时，需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每个接口应该承担一种相对独立的角色。

3.6、合成复用原则

合成复用原则又称为组合／聚合复用原则（Composition/Aggregate Reuse Principle，CARP），其定义如下：合成复用原则（Composite Reuse Principle，CRP）：尽量使用对象组合，而不是继承来达到复用的目的。
合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能的目的。简言之：复用时要尽量使用组合／聚合关系（关联关系），少用继承。
在面向对象设计中，可以通过两种方法在不同的环境中复用已有的设计和实现，即通过组合／聚合关系或通过继承，但首先应该考虑使用组合／聚合，组合／聚合可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白箱”复用。如果基类发生改变，那么子类的实现也不得不发生改变。从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性。而且继承只能在有限的环境中使用（如类没有声明为不能被继承）。
由于组合或聚合关系可以将已有的对象（也可称为成员对象）纳入新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现细节对于新对象不可见，所以这种复用又称为“黑箱”复用。相对继承关系而言，“黑箱”复用的耦合度相对较低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作。合成复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。
一般而言，如果两个类之间是“Has-A”的关系，应使用组合或聚合；如果是“Is-A”关系，可使用继承。“Is-A”是严格的分类学意义上的定义，意思是一个类是另一个类的“一种”；而“Has-A”则不同，它表示某一个角色具有某一项责任。

3.7、迪米特法则

迪米特法则又称为最少知识原则（Least Knowledge Principle，LKP），其定义如下：迪米特法则（Law of Demeter，LoD）：一个软件实体应当尽可能少地与其他实体发生相互作用。
如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易。这是对软件实体之间通信的限制。迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。
迪米特法则还有几种定义形式：不要和“陌生人”说话，只与你的直接朋友通信等。在迪米特法则中，对于一个对象，其“朋友”包括以下几类：
（1）当前对象本身（this）。
（2）以参数形式传入到当前对象方法中的对象。
（3）当前对象的成员对象。
（4）如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友。
（5）当前对象所创建的对象。

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

4、设计模式的类型

4.1、创建型——创建的艺术

创建型模式（Creational Pattern）关注对象的创建过程，是一类最常用的设计模式，在软件开发中应用非常广泛。创建型模式将对象的创建和使用分离，在使用对象时无须关心对象的创建细节，从而降低系统的耦合度，让设计方案更易于修改和扩展。每个创建型模式都通过采用不同的解决方案来回答3个问题：创建什么（What），由谁创建（Who）和何时创建（When）。

GoF设计模式中包含5种创建型模式。通常将一种非GoF模式——简单工厂模式作为学习其他工厂模式的基础。本部分一共介绍6种创建型模式，其名称、定义、学习难度和使用频率如下表所示。

4.2、结构型——组合的艺术

在面向对象软件系统中，每个类／对象都承担着一定的职责，它们相互协作，可以实现一些复杂的功能。结构型模式（Structural Pattern）关注如何将现有类或对象组织在一起形成更加强大的结构。不同的结构型模式从不同的角度来组合类或对象，在尽可能满足各种面向对象设计原则的同时，为类或对象的组合提供一系列巧妙的解决方案。

4.3、行为型——交互的艺术

在软件系统运行时，对象并不是孤立存在的，它们可以通过相互通信协作完成某些功能，一个对象在运行时也将影响到其他对象的运行。行为型模式（Behavioral Pattern）关注系统中对象之间的交互，研究系统在运行时对象之间的相互通信与协作，进一步明确对象的职责。行为型模式不仅仅关注类和对象本身，还重点关注它们之间的相互作用和职责划分。

GoF设计模式中的11种行为型模式，其名称、定义、学习难度和使用频率如下表所示。

二、24种设计模式详解

1、六种创建型

1. 单例模式
2. 简单工厂模式
3. 工厂方法模式
4. 抽象工厂模式
5. 原型模式
6. 建造者模式

2、七种组合型

1. 适配器模式
2. 桥接模式
3. 组合模式
4. 装饰模式
5. 外观模式
6. 享元模式
7. 代理模式

3、十一种行为性

1. 职责链模式
2. 命令模式
3. 解释器模式
4. 迭代器模式
5. 中介者模式
6. 备忘录模式
7. 观察者模式
8. 状态模式
9. 策略模式
10. 模板方法模式
11. 访问者模式