今天开始在卡码网学习设计模式，相关链接如下

单例模式

什么是单例设计模式

单例模式是一种创建型设计模式，它的核心思想是保证一个类只有一个实例，并提供一个全局访问点来访问这个实例。

只有一个实例的意思是，在整个应用程序中，只存在该类的一个实例对象，而不是创建多个相同类型的对象。
全局访问点的意思是，为了让其他类能够获取到这个唯一实例，该类提供了一个全局访问点（通常是一个静态方法），通过这个方法就能获得实例

为什么要使用单例设计模式呢

简易来说，单例设计模式有以下几个优点让我们考虑使用它：

全局控制：保证只有一个实例，这样就可以严格的控制客户怎样访问它以及何时访问它，简单的说就是对唯一实例的受控访问（引用自《大话设计模式》第21章）
节省资源：也正是因为只有一个实例存在，就避免多次创建了相同的对象，从而节省了系统资源，而且多个模块还可以通过单例实例共享数据。
懒加载：单例模式可以实现懒加载，只有在需要时才进行实例化，这无疑会提高程序的性能。

单例设计模式的基本要求

想要实现一个单例设计模式，必须遵循以下规则：

私有的构造函数：防止外部代码直接创建类的实例
私有的静态实例变量：保存该类的唯一实例
公有的静态方法：通过公有的静态方法来获取类的实例

什么时候使用单例设计模式

说了这么多，那在什么场景下应该考虑使用单例设计模式呢？可以结合单例设计模式的优点来看。

资源共享

多个模块共享某个资源的时候，可以使用单例模式，比如说应用程序需要一个全局的配置管理器来存储和管理配置信息、亦或是使用单例模式管理数据库连接池。

只有一个实例

当系统中某个类只需要一个实例来协调行为的时候，可以考虑使用单例模式，比如说管理应用程序中的缓存，确保只有一个缓存实例，避免重复的缓存创建和管理，或者使用单例模式来创建和管理线程池。

懒加载

如果对象创建本身就比较消耗资源，而且可能在整个程序中都不一定会使用，可以使用单例模式实现懒加载。

在许多流行的工具和库中，也都使用到了单例设计模式，比如Java中的Runtime类就是一个经典的单例，表示程序的运行时环境。此外 Spring 框架中的应用上下文 (ApplicationContext) 也被设计为单例，以提供对应用程序中所有 bean 的集中式访问点

工厂方法模式

简单工厂模式

简单工厂模式是一种创建型设计模式，但并不属于23种设计模式之一，更多的是一种编程习惯。

简单工厂模式的核心思想是将产品的创建过程封装在一个工厂类中，把创建对象的流程集中在这个工厂类里面。

简单工厂模式包括三个主要角色，工厂类、抽象产品、具体产品，下面的图示则展示了工厂类的基本结构

抽象产品，比如上图中的Shape 接口，描述产品的通用行为。
具体产品: 实现抽象产品接口或继承抽象产品类，比如上面的Circle类和Square类，具体产品通过简单工厂类的if-else逻辑来实例化。
工厂类：负责创建产品，根据传递的不同参数创建不同的产品示例

工厂方法模式

工厂方法模式也是一种创建型设计模式，简单工厂模式只有一个工厂类，负责创建所有产品，如果要添加新的产品，通常需要修改工厂类的代码。而工厂方法模式引入了抽象工厂和具体工厂的概念，每个具体工厂只负责创建一个具体产品，添加新的产品只需要添加新的工厂类而无需修改原来的代码，这样就使得产品的生产更加灵活，支持扩展，符合开闭原则。

抽象工厂：一个接口，包含一个抽象的工厂方法（用于创建产品对象）。
具体工厂：实现抽象工厂接口，创建具体的产品。
抽象产品：定义产品的接口。
具体产品：实现抽象产品接口，是工厂创建的对象

工厂方法模式使得每个工厂类的职责单一，每个工厂只负责创建一种产品，当创建对象涉及一系列复杂的初始化逻辑，而这些逻辑在不同的子类中可能有所不同时，可以使用工厂方法模式将这些初始化逻辑封装在子类的工厂中。在现有的工具、库中，工厂方法模式也有广泛的应用，比如：

Spring 框架中的 Bean 工厂：通过配置文件或注解，Spring 可以根据配置信息动态地创建和管理对象。
JDBC 中的 Connection 工厂：在 Java 数据库连接中，DriverManager 使用工厂方法模式来创建数据库连接。不同的数据库驱动（如 MySQL、PostgreSQL 等）都有对应的工厂来创建连接

抽象工厂模式

抽象工厂模式也是一种创建型设计模式，提供了一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类

基本结构

抽象工厂模式包含多个抽象产品接口，多个具体产品类，一个抽象工厂接口和多个具体工厂，每个具体工厂负责创建一组相关的产品。

抽象产品接口AbstractProduct: 定义产品的接口，可以定义多个抽象产品接口，比如说沙发、椅子、茶几都是抽象产品。
具体产品类ConcreteProduct: 实现抽象产品接口，产品的具体实现，古典风格和沙发和现代风格的沙发都是具体产品。
抽象工厂接口AbstractFactory: 声明一组用于创建产品的方法，每个方法对应一个产品。
具体工厂类ConcreteFactory：实现抽象工厂接口，负责创建一组具体产品的对象，在本例中，生产古典风格的工厂和生产现代风格的工厂都是具体实例。

基本实现

想要实现抽象工厂模式，需要遵循以下步骤：

定义抽象产品接口（可以有多个），接口中声明产品的公共方法。
实现具体产品类，在类中实现抽象产品接口中的方法。
定义抽象工厂接口，声明一组用于创建产品的方法。
实现具体工厂类，分别实现抽象工厂接口中的方法，每个方法负责创建一组相关的产品。
在客户端中使用抽象工厂和抽象产品，而不直接使用具体产品的类名

应用场景

抽象工厂模式能够保证一系列相关的产品一起使用，并且在不修改客户端代码的情况下，可以方便地替换整个产品系列。但是当需要增加新的产品类时，除了要增加新的具体产品类，还需要修改抽象工厂接口及其所有的具体工厂类，扩展性相对较差。因此抽象工厂模式特别适用于一系列相关或相互依赖的产品被一起创建的情况，典型的应用场景是使用抽象工厂模式来创建与不同数据库的连接对象。

简单工厂、工厂方法、抽象工厂的区别

简单工厂模式：一个工厂方法创建所有具体产品
工厂方法模式：一个工厂方法创建一个具体产品
抽象工厂模式：一个工厂方法可以创建一类具体产品

建造者模式

什么是建造者模式

建造者模式（也被成为生成器模式），是一种创建型设计模式，软件开发过程中有的时候需要创建很复杂的对象，而建造者模式的主要思想是**将对象的构建过程分为多个步骤，并为每个步骤定义一个抽象的接口。具体的构建过程由实现了这些接口的具体建造者类来完成。**同时有一个指导者类负责协调建造者的工作，按照一定的顺序或逻辑来执行构建步骤，最终生成产品

举个例子，假如我们要创建一个计算机对象，计算机由很多组件组成，例如 CPU、内存、硬盘、显卡等。每个组件可能有不同的型号、配置和制造，这个时候计算机就可以被视为一个复杂对象，构建过程相对复杂，而我们使用建造者模式将计算机的构建过程封装在一个具体的建造者类中，而指导者类则负责指导构建的步骤和顺序。每个具体的建造者类可以负责构建不同型号或配置的计算机，客户端代码可以通过选择不同的建造者来创建不同类型的计算机，这样就可以根据需要构建不同表示的复杂对象，更加灵活。

基本结构

建造者模式有下面几个关键角色：

产品Product：被构建的复杂对象, 包含多个组成部分。
抽象建造者Builder: 定义构建产品各个部分的抽象接口和一个返回复杂产品的方法getResult
具体建造者Concrete Builder：实现抽象建造者接口，构建产品的各个组成部分，并提供一个方法返回最终的产品。
指导者Director：调用具体建造者的方法，按照一定的顺序或逻辑来构建产品。

在客户端中，通过指导者来构建产品，而并不和具体建造者进行直接的交互。

使用场景

使用建造者模式有下面几处优点：

使用建造者模式可以**将一个复杂对象的构建与其表示分离，**通过将构建复杂对象的过程抽象出来，可以使客户端代码与具体的构建过程解耦
同样的构建过程可以创建不同的表示，可以有多个具体的建造者(相互独立），可以更加灵活地创建不同组合的对象。

对应的，建造者模式适用于复杂对象的创建，当对象构建过程相对复杂时可以考虑使用建造者模式，但是当产品的构建过程发生变化时，可能需要同时修改指导类和建造者类，这就使得重构变得相对困难。

建造者模式在现有的工具和库中也有着广泛的应用，比如JUnit 中的测试构建器TestBuilder就采用了建造者模式，用于构建测试对象。

原型模式

什么是原型模式

原型模式一种创建型设计模式，该模式的核心思想是基于现有的对象创建新的对象，而不是从头开始创建。

在原型模式中，通常有一个原型对象，它被用作创建新对象的模板。新对象通过复制原型对象的属性和状态来创建，而无需知道具体的创建细节。

为什么要使用原型模式

如果一个对象的创建过程比较复杂时（比如需要经过一系列的计算和资源消耗），那每次创建该对象都需要消耗资源，而通过原型模式就可以复制现有的一个对象来迅速创建/克隆一个新对象，不必关心具体的创建细节，可以降低对象创建的成本。

原型模式的基本结构

实现原型模式需要给【原型对象】声明一个克隆方法，执行该方法会创建一个当前类的新对象，并将原始对象中的成员变量复制到新生成的对象中，而不必实例化。并且在这个过程中只需要调用原型对象的克隆方法，而无需知道原型对象的具体类型。

原型模式包含两个重点模块：

抽象原型接口prototype: 声明一个克隆自身的方法clone
具体原型类ConcretePrototype: 实现clone方法，复制当前对象并返回一个新对象。

在客户端代码中，可以声明一个具体原型类的对象，然后调用clone()方法复制原对象生成一个新的对象。

原型模式的基本实现

原型模式的实现过程即上面描述模块的实现过程：

创建一个抽象类或接口，声明一个克隆方法clone
实现具体原型类，重写克隆方法
客户端中实例化具体原型类的对象，并调用其克隆方法来创建新的对象

适配器模式

什么是适配器

适配器模式Adapter是一种结构型设计模式，它可以将一个类的接口转换成客户希望的另一个接口，主要目的是充当两个不同接口之间的桥梁，使得原本接口不兼容的类能够一起工作。

结构

目标接口Target: 客户端希望使用的接口
适配器类Adapter: 实现客户端使用的目标接口，持有一个需要适配的类实例。
被适配者Adaptee: 需要被适配的类

这样，客户端就可以使用目标接口，而不需要对原来的Adaptee进行修改，Adapter起到一个转接扩展的作用。

应用场景

在开发过程中，适配器模式往往扮演者“补救”和“扩展”的角色：

当使用一个已经存在的类，但是它的接口与你的代码不兼容时，可以使用适配器模式。
在系统扩展阶段需要增加新的类时，并且类的接口和系统现有的类不一致时，可以使用适配器模式。

使用适配器模式可以将客户端代码与具体的类解耦，客户端不需要知道被适配者的细节，客户端代码也不需要修改，这使得它具有良好的扩展性，但是这也势必导致系统变得更加复杂

代理模式

基本概念

代理模式Proxy Pattern是一种结构型设计模式，用于控制对其他对象的访问。

在代理模式中，允许一个对象（代理）充当另一个对象（真实对象）的接口，以控制对这个对象的访问。通常用于在访问某个对象时引入一些间接层(中介的作用)，这样可以在访问对象时添加额外的控制逻辑，比如限制访问权限，延迟加载。

比如说有一个文件加载的场景，为了避免直接访问“文件”对象，我们可以新增一个代理对象，代理对象中有一个对“文件对象”的引用，在代理对象的 load 方法中，可以在访问真实的文件对象之前进行一些操作，比如权限检查，然后调用真实文件对象的 load 方法，最后在访问真实对象后进行其他操作，比如记录访问日志。

基本结构

Subject（抽象主题）：抽象类，通过接口或抽象类声明真实主题和代理对象实现的业务方法。
RealSubject（真实主题）：定义了Proxy所代表的真实对象，是客户端最终要访问的对象。
Proxy（代理）：包含一个引用，该引用可以是RealSubject的实例，控制对RealSubject的访问，并可能负责创建和删除RealSubject的实例

使用场景

代理模式可以控制客户端对真实对象的访问，从而限制某些客户端的访问权限，此外代理模式还常用在访问真实对象之前或之后执行一些额外的操作（比如记录日志），对功能进行扩展。

以上特性决定了代理模式在以下几个场景中有着广泛的应用：

虚拟代理：当一个对象的创建和初始化比较昂贵时，可以使用虚拟代理，虚拟代理可以延迟对象的实际创建和初始化，只有在需要时才真正创建并初始化对象。
安全代理：安全代理可以根据访问者的权限决定是否允许访问真实对象的方法。

但是代理模式涉及到多个对象之间的交互，引入代理模式会增加系统的复杂性，在需要频繁访问真实对象时，还可能会有一些性能问题。

代理模式在许多工具和库中也有应用：

Spring 框架的 AOP 模块使用了代理模式来实现切面编程。通过代理，Spring 能够在目标对象的方法执行前、执行后或抛出异常时插入切面逻辑，而不需要修改原始代码。
Java 提供了动态代理机制，允许在运行时生成代理类。
Android中的Glide框架使用了代理模式来实现图片的延迟加载。

装饰模式

基本概念

通常情况下，扩展类的功能可以通过继承实现，但是扩展越多，子类越多，装饰模式（Decorator Pattern, 结构型设计模式）可以在**不定义子类的情况下动态的给对象添加一些额外的功能。**具体的做法是将原始对象放入包含行为的特殊封装类(装饰类)，从而为原始对象动态添加新的行为，而无需修改其代码。

举个简单的例子，假设你有一个基础的图形类，你想要为图形类添加颜色、边框、阴影等功能，如果每个功能都实现一个子类，就会导致产生大量的类，这时就可以考虑使用装饰模式来动态地添加，而不需要修改图形类本身的代码，这样可以使得代码更加灵活、更容易维护和扩展。

基本结构

组件Component：通常是抽象类或者接口，是具体组件和装饰者的父类，定义了具体组件需要实现的方法，比如说我们定义Coffee为组件。
具体组件ConcreteComponent: 实现了Component接口的具体类，是被装饰的对象。
装饰类Decorator: 一个抽象类，给具体组件添加功能，但是具体的功能由其子类具体装饰者完成，持有一个指向Component对象的引用。
具体装饰类ConcreteDecorator: 扩展Decorator类，负责向Component对象添加新的行为，加牛奶的咖啡是一个具体装饰类，加糖的咖啡也是一个具体装饰类。

应用场景

装饰模式通常在以下几种情况使用：

当需要给一个现有类添加附加功能，但由于某些原因不能使用继承来生成子类进行扩充时，可以使用装饰模式。
动态的添加和覆盖功能：当对象的功能要求可以动态地添加，也可以再动态地撤销时可以使用装饰模式。

在Java的I/O库中，装饰者模式被广泛用于增强I/O流的功能。例如，BufferedInputStream和BufferedOutputStream这两个类提供了缓冲区的支持，通过在底层的输入流和输出流上添加缓冲区，提高了读写的效率，它们都是InputStream和OutputStream的装饰器。BufferedReader和BufferedWriter这两个类与BufferedInputStream和BufferedOutputStream类似，提供了字符流的缓冲功能，是Reader和Writer的装饰者

外观模式

基本概念

外观模式Facade Pattern, 也被称为“门面模式”，是一种结构型设计模式，外观模式定义了一个高层接口，这个接口使得子系统更容易使用，同时也隐藏了子系统的复杂性。

门面模式可以将子系统关在“门里”隐藏起来，客户端只需要通过外观接口与外观对象进行交互，而不需要直接和多个子系统交互，无论子系统多么复杂，对于外部来说是隐藏的，这样可以降低系统的耦合度。

举个例子，假设你正在编写的一个模块用来处理文件读取、解析、存储，我们可以将这个过程拆成三部分，然后创建一个外观类，将文件系统操作、数据解析和存储操作封装在外观类中，为客户端提供一个简化的接口，如果后续需要修改文件处理的流程或替换底层子系统，也只需在外观类中进行调整，不会影响客户端代码。

基本结构

外观类：对外提供一个统一的高层次接口，使复杂的子系统变得更易使用。
子系统类：实现子系统的功能，处理外观类指派的任务。

优缺点和使用场景

外观模式通过提供一个简化的接口，隐藏了系统的复杂性，降低了客户端和子系统之间的耦合度，客户端不需要了解系统的内部实现细节，也不需要直接和多个子系统交互，只需要通过外观接口与外观对象进行交互。

但是如果需要添加新的子系统或修改子系统的行为，就可能需要修改外观类，这违背了“开闭原则”。

外观模式的应用也十分普遍，下面几种情况都使用了外观模式来进行简化。

桥接模式

基本概念

桥接模式（Bridge Pattern）是一种结构型设计模式，它的UML图很像一座桥，它通过将【抽象部分】与【实现部分】分离，使它们可以独立变化，从而达到降低系统耦合度的目的。桥接模式的主要目的是通过组合建立两个类之间的联系，而不是继承的方式。

举个简单的例子，图形编辑器中，每一种图形都需要蓝色、红色、黄色不同的颜色，如果不使用桥接模式，可能需要为每一种图形类型和每一种颜色都创建一个具体的子类，而使用桥接模式可以将图形和颜色两个维度分离，两个维度都可以独立进行变化和扩展，如果要新增其他颜色，只需添加新的 Color 子类，不影响图形类；反之亦然

基本结构

桥接模式的基本结构分为以下几个角色：

抽象Abstraction：一般是抽象类，定义抽象部分的接口，维护一个对【实现】的引用。
修正抽象RefinedAbstaction：对抽象接口进行扩展，通常对抽象化的不同维度进行变化或定制。
实现Implementor：定义实现部分的接口，提供具体的实现。这个接口通常是抽象化接口的实现。
具体实现ConcreteImplementor：实现实现化接口的具体类。这些类负责实现实现化接口定义的具体操作

使用场景

桥接模式在日常开发中使用的并不是特别多，通常在以下情况下使用：

当一个类存在两个独立变化的维度，而且这两个维度都需要进行扩展时，使用桥接模式可以使它们独立变化，减少耦合。
不希望使用继承，或继承导致类爆炸性增长

总体而言，桥接模式适用于那些有多个独立变化维度、需要灵活扩展的系统。

组合模式

基本概念

组合模式是一种结构型设计模式，它将对象组合成树状结构来表示“部分-整体”的层次关系。组合模式使得客户端可以统一处理单个对象和对象的组合，而无需区分它们的具体类型。

基本结构

理解起来比较抽象，我们用“省份-城市”举个例子，省份中包含了多个城市，如果将之比喻成一个树形结构，城市就是叶子节点，它是省份的组成部分，而“省份”就是合成节点，可以包含其他城市，形成一个整体，省份和城市都是组件，它们都有一个共同的操作，比如获取信息。

Component组件：组合模式的“根节点”，定义组合中所有对象的通用接口，可以是抽象类或接口。该类中定义了子类的共性内容。
Leaf叶子：实现了Component接口的叶子节点，表示组合中的叶子对象，叶子节点没有子节点。
Composite合成：作用是存储子部件，并且在Composite中实现了对子部件的相关操作，比如添加、删除、获取子组件等。

通过组合模式，整个省份的获取信息操作可以一次性地执行，而无需关心省份中的具体城市。这样就实现了对国家省份和城市的管理和操作。

使用场景

组合模式可以使得客户端可以统一处理单个对象和组合对象，无需区分它们之间的差异，比如在图形编辑器中，图形对象可以是简单的线、圆形，也可以是复杂的组合图形，这个时候可以对组合节点添加统一的操作。

总的来说，组合模式适用于任何需要构建具有部分-整体层次结构的场景，比如组织架构管理、文件系统的文件和文件夹组织等。

享元模式

基础概念

享元模式是一种结构型设计模式，在享元模式中，对象被设计为可共享的，可以被多个上下文使用，而不必在每个上下文中都创建新的对象。

想要了解享元模式，就必须要区分什么是内部状态，什么是外部状态。

内部状态是指那些可以被多个对象共享的状态，它存储在享元对象内部，并且对于所有享元对象都是相同的，这部分状态通常是不变的。
而外部状态是享元对象依赖的、可能变化的部分。这部分状态不存储在享元对象内部，而是在使用享元对象时通过参数传递给对象。

举个例子，图书馆中有很多相同的书籍，但每本书都可以被多个人借阅，图书馆里的书就是内部状态，人就是外部状态。

再举个开发中的例子，假设我们在构建一个简单的图形编辑器，用户可以在画布上绘制不同类型的图形，而图形就是所有图形对象的内部状态（不变的），而图形的坐标位置就是图形对象的外部状态（变化的）。

如果图形编辑器中有成千上万的图形对象，每个图形对象都独立创建并存储其内部状态，那么系统的内存占用可能会很大，在这种情况下，享元模式共享相同类型的图形对象，每种类型的图形对象只需创建一个共享实例，然后通过设置不同的坐标位置个性化每个对象，通过共享相同的内部状态，降低了对象的创建和内存占用成本

基本结构

享元接口Flyweight: 所有具体享元类的共享接口，通常包含对外部状态的操作。
具体享元类ConcreteFlyweight: 继承Flyweight类或实现享元接口，包含内部状态。
享元工厂类FlyweightFactory: 创建并管理享元对象，当用户请求时，提供已创建的实例或者创建一个。
客户端Client: 维护外部状态，在使用享元对象时，将外部状态传递给享元对象。

使用场景

使用享元模式的关键在于包含大量相似对象，并且这些对象的内部状态可以共享。具体的应用场景包括文本编辑器，图形编辑器，游戏中的角色创建，这些对象的内部状态比较固定(外观，技能，形状)，但是外部状态变化比较大时，可以使用。

观察者模式

什么是观察者模式

观察者模式（发布-订阅模式）属于行为型模式，定义了一种一对多的依赖关系，让多个观察者对象同时监听一个主题对象，当主题对象的状态发生变化时，所有依赖于它的观察者都得到通知并被自动更新

观察者模式依赖两个模块：

Subject(主题)：也就是被观察的对象，它可以维护一组观察者，当主题本身发生改变时就会通知观察者。
Observer(观察者)：观察主题的对象，当“被观察”的主题发生变化时，观察者就会得到通知并执行相应的处理

结构

主题Subject，一般会定义成一个接口，提供方法用于注册、删除和通知观察者，通常也包含一个状态，当状态发生改变时，通知所有的观察者。
观察者Observer: 观察者也需要实现一个接口，包含一个更新方法，在接收主题通知时执行对应的操作。
具体主题ConcreteSubject: 主题的具体实现, 维护一个观察者列表，包含了观察者的注册、删除和通知方法。
具体观察者ConcreteObserver: 观察者接口的具体实现，每个具体观察者都注册到具体主题中，当主题状态变化并通知到具体观察者，具体观察者进行处理。

什么时候使用观察者模式

观察者模式特别适用于一个对象的状态变化会影响到其他对象，并且希望这些对象在状态变化时能够自动更新的情况。 比如说在图形用户界面中，按钮、滑动条等组件的状态变化可能需要通知其他组件更新，这使得观察者模式被广泛应用于GUI框架，比如Java的Swing框架