前言: Java 中,常见的设计模式包含 23 种,这些设计模式分为三种类型:创建型模式、结构型模式和行为型模式。每种设计模式都解决了特定类型的问题,并具有各自的优缺点和适用场景。

创建型模式(5种)

  1. 单例模式(Singleton Pattern):确保类只有一个实例,并提供全局访问点。
  2. 工厂模式(Factory Pattern):定义一个用于创建对象的接口,让子类决定实例化哪个类。
  3. 抽象工厂模式(Abstract Factory Pattern):提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们的具体类。
  4. 建造者模式(Builder Pattern):将一个复杂对象的构建与其表示分离,使得同样的构建过程可以创建不同的表示。
  5. 原型模式(Prototype Pattern):通过复制现有对象来创建新对象,而不是通过实例化类。

结构型模式(7种)

  1. 适配器模式(Adapter Pattern):将一个类的接口转换成客户端所期待的另一个接口,使得原本不兼容的接口能够一起工作。
  2. 桥接模式(Bridge Pattern):将抽象部分与它的实现部分分离,使它们可以独立变化。
  3. 组合模式(Composite Pattern):将对象组合成树形结构以表示”部分-整体”的层次结构,使得客户端统一对待单个对象和组合对象。
  4. 装饰者模式(Decorator Pattern):动态地将责任附加到对象上,若要扩展功能,装饰者提供了比继承更有弹性的替代方案。
  5. 外观模式(Facade Pattern):为子系统中的一组接口提供一个统一的接口,以简化子系统的使用。
  6. 享元模式(Flyweight Pattern):通过共享技术实现相同或相似对象的重用,以减少内存使用和提高性能。
  7. 代理模式(Proxy Pattern):为其他对象提供一种代理以控制对这个对象的访问。

行为型模式(11种)

  1. 责任链模式(Chain of Responsibility Pattern):为解除请求的发送者和接收者之间的耦合,而使多个对象都有机会处理请求。
  2. 命令模式(Command Pattern):将请求封装成对象,以便参数化客户端调用的行为。
  3. 解释器模式(Interpreter Pattern):给定一个语言,定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子。
  4. 迭代器模式(Iterator Pattern):提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露其内部表示。
  5. 中介者模式(Mediator Pattern):用一个中介对象封装一系列对象的交互,从而使对象间的交互松耦合。
  6. 备忘录模式(Memento Pattern):在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。
  7. 观察者模式(Observer Pattern):定义对象间的一种一对多的依赖关系,使得当一个对象状态发生改变时,所有依赖于它的对象都会得到通知并自动更新。
  8. 状态模式(State Pattern):允许对象在其内部状态改变时改变它的行为。
  9. 策略模式(Strategy Pattern):定义一系列算法,将每个算法封装起来,并使它们可以互换。
  10. 模板方法模式(Template Method Pattern):定义一个算法的骨架,而将一些步骤延迟到子类中。
  11. 访问者模式(Visitor Pattern):在不改变已有类的情况下,定义对这些类新的操作。

创建型模式

单列模式

单例模式(Singleton Pattern)是一种创建型设计模式,确保一个类只有一个实例,并提供一个全局访问点来访问这个实例。单例模式通常用于需要全局唯一对象的场景,例如配置管理类、日志类、线程池等。

实现单例模式的几种方式

1. 饿汉式(Eager Initialization)

在类加载时就创建实例,这种方式简单但在类加载时就完成实例化,可能会造成资源浪费。

示例代码
1
2
3
4
5
6
7
8
9
10
11
public class EagerSingleton {
private static final EagerSingleton INSTANCE = new EagerSingleton();

private EagerSingleton() {
// 私有构造函数,防止外部实例化
}

public static EagerSingleton getInstance() {
return INSTANCE;
}
}

2. 懒汉式(Lazy Initialization)

在需要时才创建实例,线程不安全,需要额外的同步控制。

示例代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class LazySingleton {
private static LazySingleton instance;

private LazySingleton() {
// 私有构造函数,防止外部实例化
}

public static LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
}

3. 线程安全的懒汉式(Synchronized Method)

通过同步来保证线程安全,但会影响性能。

示例代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class SynchronizedSingleton {
private static SynchronizedSingleton instance;

private SynchronizedSingleton() {
// 私有构造函数,防止外部实例化
}

public static synchronized SynchronizedSingleton getInstance() {
if (instance == null) {
instance = new SynchronizedSingleton();
}
return instance;
}
}

4. 双重检查锁(Double-Checked Locking)

结合懒汉式和同步的优点,减少同步带来的性能开销。

示例代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class DoubleCheckedLockingSingleton {
private static volatile DoubleCheckedLockingSingleton instance;

private DoubleCheckedLockingSingleton() {
// 私有构造函数,防止外部实例化
}

public static DoubleCheckedLockingSingleton getInstance() {
if (instance == null) {
synchronized (DoubleCheckedLockingSingleton.class) {
if (instance == null) {
instance = new DoubleCheckedLockingSingleton();
}
}
}
return instance;
}
}

5. 静态内部类(Bill Pugh Singleton)

利用静态内部类特性,既实现了延迟加载,又保证了线程安全。

示例代码
1
2
3
4
5
6
7
8
9
10
11
12
13
public class StaticInnerClassSingleton {
private StaticInnerClassSingleton() {
// 私有构造函数,防止外部实例化
}

private static class SingletonHelper {
private static final StaticInnerClassSingleton INSTANCE = new StaticInnerClassSingleton();
}

public static StaticInnerClassSingleton getInstance() {
return SingletonHelper.INSTANCE;
}
}

6. 枚举(Enum Singleton)

枚举类型的单例模式实现最简单,并且天生是线程安全的,防止反序列化创建新的对象。

示例代码
1
2
3
4
5
6
7
public enum EnumSingleton {
INSTANCE;

public void doSomething() {
// 单例实例方法
}
}

优点

  1. 唯一实例:确保系统中只有一个实例,减少资源开销。
  2. 全局访问:提供一个全局访问点,方便控制和管理实例。
  3. 延迟加载:部分实现方式可以实现延迟加载(如懒汉式、静态内部类)。

缺点

  1. 单例类的职责过重:可能导致“上帝对象”问题,使类变得臃肿。
  2. 隐藏依赖关系:不利于依赖注入,可能会使代码难以测试。
  3. 多线程问题:某些实现方式在多线程环境下需要注意线程安全问题。

使用场景

  1. 需要唯一实例:如配置管理类、日志记录器、线程池、缓存等。
  2. 控制资源使用:如需要频繁访问数据库或文件系统的场景,通过单例模式来控制资源访问。

单例模式是设计模式中最常见的一种,适用于需要全局唯一实例的场景。选择合适的实现方式,可以有效提高程序的性能和稳定性。

工厂模式

工厂模式(Factory Pattern)是一种创建型设计模式,它提供了一种创建对象的最佳方式,而无需向客户端暴露创建逻辑。工厂模式定义了一个用于创建对象的接口,但是让子类决定实例化哪个类。这样,工厂模式允许类将实例化延迟到子类。

主要组成部分

  1. 工厂接口(Factory):声明了一个用于创建对象的工厂方法,可以是接口、抽象类或具体类。
  2. 具体工厂(Concrete Factory):实现了工厂接口,负责实际创建对象的工厂类。
  3. 产品接口(Product):定义了工厂创建的对象的接口,可以是接口或抽象类。
  4. 具体产品(Concrete Product):实现了产品接口,是工厂创建的具体对象。

示例代码

产品接口

1
2
3
4
// 产品接口
public interface Product {
void doSomething(); // 定义产品的行为接口
}

具体产品 - ProductA

1
2
3
4
5
6
7
// 具体产品 - ProductA
public class ProductA implements Product {
@Override
public void doSomething() {
System.out.println("ProductA is doing something."); // 具体产品A的行为实现
}
}

具体产品 - ProductB

1
2
3
4
5
6
7
// 具体产品 - ProductB
public class ProductB implements Product {
@Override
public void doSomething() {
System.out.println("ProductB is doing something."); // 具体产品B的行为实现
}
}

工厂接口

1
2
3
4
// 工厂接口
public interface Factory {
Product createProduct(); // 工厂方法,用于创建产品
}

具体工厂 - FactoryA

1
2
3
4
5
6
7
// 具体工厂 - FactoryA
public class FactoryA implements Factory {
@Override
public Product createProduct() {
return new ProductA(); // 创建具体产品A的工厂方法实现
}
}

具体工厂 - FactoryB

1
2
3
4
5
6
7
// 具体工厂 - FactoryB
public class FactoryB implements Factory {
@Override
public Product createProduct() {
return new ProductB(); // 创建具体产品B的工厂方法实现
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
public class FactoryPatternDemo {
public static void main(String[] args) {
Factory factoryA = new FactoryA(); // 创建工厂A实例
Product productA = factoryA.createProduct(); // 使用工厂A创建产品A
productA.doSomething(); // 调用产品A的方法,输出: ProductA is doing something.

Factory factoryB = new FactoryB(); // 创建工厂B实例
Product productB = factoryB.createProduct(); // 使用工厂B创建产品B
productB.doSomething(); // 调用产品B的方法,输出: ProductB is doing something.
}
}

优点

  1. 封装性:工厂模式将对象的创建过程封装在工厂类中,客户端无需了解具体的创建细节。
  2. 解耦性:工厂模式将客户端代码与具体的产品类解耦,客户端只需要知道产品的接口即可。
  3. 可扩展性:增加新的具体产品和具体工厂很容易,符合开闭原则。

缺点

  1. 增加了系统复杂度:引入了多个工厂类和产品类,增加了系统的复杂度。

使用场景

  1. 对象的创建过程复杂,需要隐藏创建逻辑:当对象的创建过程比较复杂,需要隐藏创建逻辑时,可以使用工厂模式。
  2. 需要根据不同的条件创建不同的对象:当需要根据不同的条件创建不同的对象时,可以使用工厂模式。

工厂模式通过封装对象的创建过程,使得客户端无需了解具体的创建细节,从而实现了对象的创建和使用的分离。它适用于对象的创建过程比较复杂,或者需要根据不同的条件创建不同的对象的场景。

抽象工厂模式

抽象工厂模式(Abstract Factory Pattern)是一种创建型设计模式,它提供了一种创建一系列相关或相互依赖对象的最佳方式,而无需指定它们的具体类。抽象工厂模式通过引入抽象工厂接口和抽象产品接口,实现了工厂方法模式的扩展,使得一族相关或相互依赖的对象可以被一起创建。

主要组成部分

  1. 抽象工厂接口(Abstract Factory):声明了一组用于创建一族产品的抽象方法,每个方法对应一种产品。
  2. 具体工厂(Concrete Factory):实现了抽象工厂接口,负责创建一族具体产品。
  3. 抽象产品接口(Abstract Product):声明了一组产品的抽象方法,每个方法对应产品的一个属性或行为。
  4. 具体产品(Concrete Product):实现了抽象产品接口,是抽象工厂创建的具体对象。

示例代码

抽象产品接口

1
2
3
4
// 抽象产品接口
public interface AbstractProductA {
void doSomething(); // 定义产品A的行为接口
}
1
2
3
4
// 抽象产品接口
public interface AbstractProductB {
void doSomething(); // 定义产品B的行为接口
}

具体产品 - ProductA1

1
2
3
4
5
6
7
// 具体产品 - ProductA1
public class ProductA1 implements AbstractProductA {
@Override
public void doSomething() {
System.out.println("ProductA1 is doing something."); // 具体产品A1的行为实现
}
}

具体产品 - ProductA2

1
2
3
4
5
6
7
// 具体产品 - ProductA2
public class ProductA2 implements AbstractProductA {
@Override
public void doSomething() {
System.out.println("ProductA2 is doing something."); // 具体产品A2的行为实现
}
}

具体产品 - ProductB1

1
2
3
4
5
6
7
// 具体产品 - ProductB1
public class ProductB1 implements AbstractProductB {
@Override
public void doSomething() {
System.out.println("ProductB1 is doing something."); // 具体产品B1的行为实现
}
}

具体产品 - ProductB2

1
2
3
4
5
6
7
// 具体产品 - ProductB2
public class ProductB2 implements AbstractProductB {
@Override
public void doSomething() {
System.out.println("ProductB2 is doing something."); // 具体产品B2的行为实现
}
}

抽象工厂接口

1
2
3
4
5
// 抽象工厂接口
public interface AbstractFactory {
AbstractProductA createProductA(); // 创建产品A的抽象方法
AbstractProductB createProductB(); // 创建产品B的抽象方法
}

具体工厂 - Factory1

1
2
3
4
5
6
7
8
9
10
11
12
// 具体工厂 - Factory1
public class Factory1 implements AbstractFactory {
@Override
public AbstractProductA createProductA() {
return new ProductA1(); // 创建具体产品A1的工厂方法实现
}

@Override
public AbstractProductB createProductB() {
return new ProductB1(); // 创建具体产品B1的工厂方法实现
}
}

具体工厂 - Factory2

1
2
3
4
5
6
7
8
9
10
11
12
// 具体工厂 - Factory2
public class Factory2 implements AbstractFactory {
@Override
public AbstractProductA createProductA() {
return new ProductA2(); // 创建具体产品A2的工厂方法实现
}

@Override
public AbstractProductB createProductB() {
return new ProductB2(); // 创建具体产品B2的工厂方法实现
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class AbstractFactoryPatternDemo {
public static void main(String[] args) {
AbstractFactory factory1 = new Factory1(); // 创建工厂1实例
AbstractProductA productA1 = factory1.createProductA(); // 使用工厂1创建产品A1
AbstractProductB productB1 = factory1.createProductB(); // 使用工厂1创建产品B1

productA1.doSomething(); // 调用产品A1的方法,输出: ProductA1 is doing something.
productB1.doSomething(); // 调用产品B1的方法,输出: ProductB1 is doing something.

AbstractFactory factory2 = new Factory2(); // 创建工厂2实例
AbstractProductA productA2 = factory2.createProductA(); // 使用工厂2创建产品A2
AbstractProductB productB2 = factory2.createProductB(); // 使用工厂2创建产品B2

productA2.doSomething(); // 调用产品A2的方法,输出: ProductA2 is doing something.
productB2.doSomething(); // 调用产品B2的方法,输出: ProductB2 is doing something.
}
}

优点

  1. 封装性:抽象工厂模式将具体类的创建逻辑封装在具体工厂中,客户端无需了解具体创建细节。
  2. 解耦性:抽象工厂模式将客户端与具体类解耦,客户端只需要知道产品的抽象接口即可。
  3. 产品族一致性:抽象工厂模式可以确保一族产品之间的兼容性,因为同一个工厂创建的产品属于同一族。

缺点

  1. 扩展性差:抽象工厂模式中增加新的产品族比较困难,因为需要修改抽象工厂接口和所有的具体工厂类。

使用场景

  1. 需要创建一系列相关或相互依赖的对象:当需要创建一系列相关或相互依赖的对象时,可以使用抽象工厂模式。
  2. 系统中有多个产品族,但是每次只使用其中一个产品族:当系统中有多个产品族,但是每次只使用其中一个产品族时,可以使用抽象工厂模式。

抽象工厂模式通过引入抽象工厂接口和抽象产品接口,实现了工厂方法模式的扩展,使得一族相关或相互依赖的对象可以被一起创建。它适用于需要创建一系列相关或相互依赖的对象的场景。

建造者模式

建造者模式(Builder Pattern)是一种创建型设计模式,它用于构建复杂对象的步骤逐步执行,并允许通过不同的配置创建不同类型的对象。建造者模式将一个复杂对象的构建过程与其表示分离,使得同样的构建过程可以创建不同的表示。

主要组成部分

  1. Builder(建造者):定义创建产品各个部件的接口。
  2. ConcreteBuilder(具体建造者):实现Builder接口,构建并装配各个部件。
  3. Product(产品):具体要创建的复杂对象。
  4. Director(指挥者):负责安排已有的Builder对象的建造步骤。它知道如何使用Builder来构建产品。

示例代码

假设我们要建造一个复杂的电脑对象,包含CPU、内存和存储等部件。

产品类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 产品类
public class Computer {
private String CPU;
private String RAM;
private String storage;

public void setCPU(String CPU) {
this.CPU = CPU;
}

public void setRAM(String RAM) {
this.RAM = RAM;
}

public void setStorage(String storage) {
this.storage = storage;
}

@Override
public String toString() {
return "Computer [CPU=" + CPU + ", RAM=" + RAM + ", storage=" + storage + "]";
}
}

建造者接口

1
2
3
4
5
6
7
// 建造者接口
public interface ComputerBuilder {
void buildCPU(); // 建造CPU的方法
void buildRAM(); // 建造RAM的方法
void buildStorage(); // 建造存储的方法
Computer getComputer(); // 获取构建好的电脑对象
}

具体建造者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// 具体建造者 - GamingComputerBuilder
public class GamingComputerBuilder implements ComputerBuilder {
private Computer computer;

public GamingComputerBuilder() {
this.computer = new Computer();
}

@Override
public void buildCPU() {
computer.setCPU("High-end CPU"); // 设置高端CPU
}

@Override
public void buildRAM() {
computer.setRAM("16GB RAM"); // 设置16GB RAM
}

@Override
public void buildStorage() {
computer.setStorage("1TB SSD"); // 设置1TB SSD
}

@Override
public Computer getComputer() {
return this.computer; // 返回构建好的电脑对象
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// 具体建造者 - OfficeComputerBuilder
public class OfficeComputerBuilder implements ComputerBuilder {
private Computer computer;

public OfficeComputerBuilder() {
this.computer = new Computer();
}

@Override
public void buildCPU() {
computer.setCPU("Mid-range CPU"); // 设置中端CPU
}

@Override
public void buildRAM() {
computer.setRAM("8GB RAM"); // 设置8GB RAM
}

@Override
public void buildStorage() {
computer.setStorage("512GB SSD"); // 设置512GB SSD
}

@Override
public Computer getComputer() {
return this.computer; // 返回构建好的电脑对象
}
}

指挥者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 指挥者
public class Director {
private ComputerBuilder builder;

public Director(ComputerBuilder builder) {
this.builder = builder;
}

public void constructComputer() {
builder.buildCPU(); // 建造CPU
builder.buildRAM(); // 建造RAM
builder.buildStorage(); // 建造存储
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Client {
public static void main(String[] args) {
// 创建游戏电脑
ComputerBuilder gamingBuilder = new GamingComputerBuilder(); // 使用游戏电脑建造者
Director director = new Director(gamingBuilder); // 创建指挥者
director.constructComputer(); // 构建电脑
Computer gamingComputer = gamingBuilder.getComputer(); // 获取构建好的游戏电脑对象
System.out.println(gamingComputer); // 输出游戏电脑信息

// 创建办公电脑
ComputerBuilder officeBuilder = new OfficeComputerBuilder(); // 使用办公电脑建造者
director = new Director(officeBuilder); // 创建指挥者
director.constructComputer(); // 构建电脑
Computer officeComputer = officeBuilder.getComputer(); // 获取构建好的办公电脑对象
System.out.println(officeComputer); // 输出办公电脑信息
}
}

优点

  1. 分离复杂对象的创建过程和表示:可以通过不同的建造者构造出不同的表示。
  2. 更好的控制细节:建造者模式允许对构建过程进行更精细的控制。
  3. 易于扩展:添加新的具体建造者无需修改现有代码,只需实现新的建造者类。

缺点

  1. 生成过程较为复杂:如果构造步骤或者部件非常多,代码可能会变得复杂。
  2. 不适用于简单对象:对于只需要简单构造的对象,引入建造者模式反而会增加代码的复杂性。

建造者模式非常适合那些构建步骤复杂或者部件繁多的对象,能很好地将构建过程与对象表示分离,提供灵活的对象创建机制。

原型模式

原型模式(Prototype Pattern)是一种创建型设计模式,通过复制现有对象来创建新对象,而不是通过实例化一个类来创建对象。这样可以简化对象的创建过程,特别是对于创建成本较高的对象。原型模式使用的是对象的克隆方法,通常需要实现一个克隆接口。

主要组成部分

  1. Prototype(原型接口):定义一个克隆自身的接口。
  2. ConcretePrototype(具体原型类):实现克隆方法,以创建自身的一个副本。
  3. Client(客户端):通过调用原型对象的克隆方法来创建新的对象。

示例代码

假设我们有一个需要大量复制的复杂对象,可以使用原型模式来创建这些对象。

原型接口

1
2
3
4
// 原型接口
public interface Prototype extends Cloneable {
Prototype clone(); // 定义克隆自身的接口
}

具体原型类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// 具体原型类
public class ConcretePrototype implements Prototype {
private String name;
private int value;

public ConcretePrototype(String name, int value) {
this.name = name;
this.value = value;
}

public void setName(String name) {
this.name = name;
}

public void setValue(int value) {
this.value = value;
}

@Override
public Prototype clone() {
try {
return (Prototype) super.clone(); // 调用父类的克隆方法
} catch (CloneNotSupportedException e) {
e.printStackTrace();
return null;
}
}

@Override
public String toString() {
return "ConcretePrototype [name=" + name + ", value=" + value + "]";
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Client {
public static void main(String[] args) {
// 创建一个具体原型对象
ConcretePrototype prototype1 = new ConcretePrototype("Prototype1", 100);

// 通过克隆方法创建新对象
ConcretePrototype prototype2 = (ConcretePrototype) prototype1.clone();

// 修改克隆对象的属性
prototype2.setName("Prototype2");
prototype2.setValue(200);

// 输出原型对象和克隆对象
System.out.println(prototype1);
System.out.println(prototype2);
}
}

优点

  1. 性能优化:通过克隆对象创建新对象,可以避免复杂对象的重复创建,节省时间和资源。
  2. 简化对象创建:可以简化创建复杂对象的过程,特别是那些包含多个配置或初始化步骤的对象。
  3. 动态调整:可以在运行时动态调整克隆的对象,而不需要修改代码。

缺点

  1. 深拷贝与浅拷贝:需要注意浅拷贝和深拷贝的问题,浅拷贝可能导致克隆对象与原对象共享相同的引用数据。
  2. 复杂性:对于包含复杂引用关系的对象,深拷贝的实现可能会比较复杂。
  3. 克隆方法的实现:有些对象可能不支持或者不适合克隆,克隆方法的实现需要谨慎。

适用场景

  1. 创建成本高的对象:需要频繁创建的对象,其创建成本较高,可以通过克隆来减少开销。
  2. 对象初始化复杂:对象的初始化过程复杂,可以通过克隆一个已经初始化好的对象来简化过程。
  3. 需要大量相似对象:需要创建大量相似对象,且这些对象之间只有部分属性不同,可以通过原型模式快速创建。

原型模式通过克隆现有对象来创建新对象,适用于创建成本高、初始化复杂或需要大量相似对象的场景。使用原型模式可以显著提高对象创建的效率和灵活性。

结构型模式

适配器模式

适配器模式(Adapter Pattern)是一种结构型设计模式,它允许接口不兼容的类能够一起工作。适配器模式通过将一个类的接口转换成客户端期望的另一个接口,使得原本由于接口不兼容而不能一起工作的类可以协同工作。适配器模式有两种主要形式:类适配器模式和对象适配器模式。

主要组成部分

  1. 目标接口(Target):客户端期望的接口。
  2. 需要适配的类(Adaptee):现有的接口,需要进行适配的类。
  3. 适配器(Adapter):将Adaptee的接口转换为Target接口的适配器类。
  4. 客户端(Client):使用Target接口进行编程。

类适配器模式

类适配器模式通过多重继承(在Java中通过实现接口和继承类的方式)来适配接口。

示例代码

假设我们有一个旧的音频播放器,它只能播放MP3格式的音频文件,现在我们需要让它也能够播放MP4格式的音频文件。

目标接口
1
2
3
4
// 目标接口
public interface MediaPlayer {
void play(String audioType, String fileName); // 播放方法
}
需要适配的类
1
2
3
4
5
6
7
8
9
10
11
// 需要适配的类
public class Mp3Player implements MediaPlayer {
@Override
public void play(String audioType, String fileName) {
if (audioType.equalsIgnoreCase("mp3")) {
System.out.println("Playing mp3 file. Name: " + fileName); // 播放mp3文件
} else {
System.out.println("Invalid media. " + audioType + " format not supported"); // 不支持的格式
}
}
}
适配者类
1
2
3
4
5
6
// 适配者类
public class Mp4Player {
public void playMp4(String fileName) {
System.out.println("Playing mp4 file. Name: " + fileName); // 播放mp4文件
}
}
适配器类
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 适配器类
public class MediaAdapter implements MediaPlayer {
Mp4Player mp4Player;

public MediaAdapter(String audioType) {
if (audioType.equalsIgnoreCase("mp4")) {
mp4Player = new Mp4Player(); // 创建mp4播放器
}
}

@Override
public void play(String audioType, String fileName) {
if (audioType.equalsIgnoreCase("mp4")) {
mp4Player.playMp4(fileName); // 使用mp4播放器播放mp4文件
}
}
}
客户端代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class AudioPlayer implements MediaPlayer {

MediaAdapter mediaAdapter;

@Override
public void play(String audioType, String fileName) {
if (audioType.equalsIgnoreCase("mp3")) {
System.out.println("Playing mp3 file. Name: " + fileName); // 播放mp3文件
} else if (audioType.equalsIgnoreCase("mp4")) {
mediaAdapter = new MediaAdapter(audioType); // 创建mp4适配器
mediaAdapter.play(audioType, fileName); // 使用mp4适配器播放mp4文件
} else {
System.out.println("Invalid media. " + audioType + " format not supported"); // 不支持的格式
}
}

public static void main(String[] args) {
AudioPlayer audioPlayer = new AudioPlayer();

audioPlayer.play("mp3", "song.mp3"); // 播放mp3文件
audioPlayer.play("mp4", "video.mp4"); // 播放mp4文件
audioPlayer.play("vlc", "movie.vlc"); // 不支持的格式
}
}

对象适配器模式

对象适配器模式通过组合的方式,将现有的类的对象作为适配器的一个字段。

示例代码

对象适配器的实现与类适配器类似,但通过组合来实现。

适配器类
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class MediaAdapter implements MediaPlayer {
Mp4Player mp4Player;

public MediaAdapter(String audioType) {
if (audioType.equalsIgnoreCase("mp4")) {
mp4Player = new Mp4Player();
}
}

@Override
public void play(String audioType, String fileName) {
if (audioType.equalsIgnoreCase("mp4")) {
mp4Player.playMp4(fileName);
}
}
}

优点

  1. 复用现有类:适配器模式可以复用现有的类,无需修改已有代码。
  2. 灵活性高:适配器模式可以让两个不兼容的接口协同工作,提高系统的灵活性和可扩展性。
  3. 解耦合:客户端无需了解适配器背后的实现细节,只需与目标接口交互。

缺点

  1. 额外的开销:增加了一层间接性,可能会导致代码的复杂性增加。
  2. 过度使用:如果系统中大量使用适配器模式,可能会导致代码结构混乱。

使用场景

  1. 使用第三方库:当使用第三方库的接口与系统接口不兼容时,可以使用适配器模式。
  2. 旧系统改造:在旧系统改造中,适配器模式可以让新旧系统一起工作。
  3. 接口不兼容:当接口不兼容但需要协同工作时,可以使用适配器模式。

适配器模式通过引入一个适配器类,将原本不兼容的接口连接起来,使得系统更加灵活和可扩展。在实际开发中,适配器模式广泛应用于需要兼容多个接口的场景。

桥接模式

桥接模式(Bridge Pattern)是一种结构型设计模式,它通过将抽象部分与实现部分分离,使它们可以独立地变化。桥接模式可以使系统在多个维度上扩展时不产生指数级的复杂性增长。

主要组成部分

  1. 抽象(Abstraction):定义抽象的接口,并保存对实现部分的引用。
  2. 扩展抽象(Refined Abstraction):扩展抽象接口,添加额外的操作。
  3. 实现(Implementor):定义实现类的接口,接口不一定要与抽象部分完全一致。
  4. 具体实现(Concrete Implementor):具体实现Implementor接口的方法。

示例代码

假设我们要设计一个图形绘制系统,可以绘制不同的形状(如圆形和方形),并且可以用不同的颜色(如红色和绿色)来绘制这些形状。

实现接口

1
2
3
4
// 实现接口
public interface DrawAPI {
void drawCircle(int radius, int x, int y); // 绘制圆形方法
}

具体实现类

1
2
3
4
5
6
7
// 具体实现类 - RedCircle
public class RedCircle implements DrawAPI {
@Override
public void drawCircle(int radius, int x, int y) {
System.out.println("Drawing Circle[ color: red, radius: " + radius + ", x: " + x + ", y: " + y + "]");
}
}
1
2
3
4
5
6
7
// 具体实现类 - GreenCircle
public class GreenCircle implements DrawAPI {
@Override
public void drawCircle(int radius, int x, int y) {
System.out.println("Drawing Circle[ color: green, radius: " + radius + ", x: " + x + ", y: " + y + "]");
}
}

抽象类

1
2
3
4
5
6
7
8
9
10
// 抽象类
public abstract class Shape {
protected DrawAPI drawAPI;

protected Shape(DrawAPI drawAPI) {
this.drawAPI = drawAPI;
}

public abstract void draw(); // 绘制方法
}

扩展抽象类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 扩展抽象类 - Circle
public class Circle extends Shape {
private int x, y, radius;

public Circle(int x, int y, int radius, DrawAPI drawAPI) {
super(drawAPI);
this.x = x;
this.y = y;
this.radius = radius;
}

@Override
public void draw() {
drawAPI.drawCircle(radius, x, y); // 调用实现接口的绘制圆形方法
}
}

客户端代码

1
2
3
4
5
6
7
8
9
public class BridgePatternDemo {
public static void main(String[] args) {
Shape redCircle = new Circle(100, 100, 10, new RedCircle()); // 创建红色圆形对象
Shape greenCircle = new Circle(100, 100, 10, new GreenCircle()); // 创建绿色圆形对象

redCircle.draw(); // 绘制红色圆形
greenCircle.draw(); // 绘制绿色圆形
}
}

优点

  1. 分离抽象和实现:桥接模式将抽象部分和实现部分分离,使它们可以独立变化。
  2. 提高系统可扩展性:通过组合不同的抽象部分和实现部分,可以灵活地扩展系统功能。
  3. 减少类的数量:避免了使用继承造成的类爆炸问题。

缺点

  1. 增加系统复杂性:引入了额外的抽象层,可能会使系统变得更加复杂。
  2. 理解难度:对开发人员来说,理解和实现桥接模式需要一定的时间和经验。

使用场景

  1. 需要多个维度扩展:系统需要在多个维度上扩展,并且各个维度可以独立变化。
  2. 避免类爆炸:通过桥接模式,可以避免由于多层继承带来的类爆炸问题。
  3. 希望实现细节对客户透明:希望隐藏具体实现,只暴露抽象接口给客户。

桥接模式通过分离抽象部分和实现部分,使系统能够独立地扩展这两个部分。它特别适用于需要在多个维度上扩展系统的场景,能够有效避免类爆炸问题,提高系统的灵活性和可维护性。

组合模式

组合模式(Composite Pattern)是一种结构型设计模式,它允许你将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得客户端对单个对象和组合对象的使用具有一致性。也就是说,客户端可以一致地使用组合结构和单个对象,而无需关心它们是组合对象还是单个对象。

主要组成部分

  1. 组件(Component):定义组合对象和叶子对象的共同接口。
  2. 叶子(Leaf):表示组合的最基本对象,叶子节点没有子节点。
  3. 组合(Composite):定义有子部件的那些对象。存储子部件,实现在组件接口中的子部件相关操作。

示例代码

假设我们要构建一个公司的层次结构,包括部门和员工。

组件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
import java.util.ArrayList;
import java.util.List;

// 组件接口
public abstract class Employee {
protected String name;
protected String dept;
protected int salary;

public Employee(String name, String dept, int salary) {
this.name = name;
this.dept = dept;
this.salary = salary;
}

// 添加子员工
public void add(Employee e) {
// 默认实现
throw new UnsupportedOperationException();
}

// 移除子员工
public void remove(Employee e) {
// 默认实现
throw new UnsupportedOperationException();
}

// 获取子员工列表
public List<Employee> getSubordinates() {
// 默认实现
return new ArrayList<>();
}

// 打印员工信息
public String toString() {
return ("Employee :[ Name : " + name + ", dept : " + dept + ", salary :" + salary + " ]");
}
}

叶子

1
2
3
4
5
6
// 叶子节点
public class Developer extends Employee {
public Developer(String name, String dept, int salary) {
super(name, dept, salary);
}
}
1
2
3
4
5
6
// 叶子节点
public class Manager extends Employee {
public Manager(String name, String dept, int salary) {
super(name, dept, salary);
}
}

组合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
import java.util.ArrayList;
import java.util.List;

// 组合节点
public class CompositeEmployee extends Employee {
private List<Employee> subordinates;

public CompositeEmployee(String name, String dept, int salary) {
super(name, dept, salary);
subordinates = new ArrayList<>();
}

// 添加子员工
@Override
public void add(Employee e) {
subordinates.add(e);
}

// 移除子员工
@Override
public void remove(Employee e) {
subordinates.remove(e);
}

// 获取子员工列表
@Override
public List<Employee> getSubordinates() {
return subordinates;
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public class CompositePatternDemo {

public static void main(String[] args) {
Employee CEO = new CompositeEmployee("John", "CEO", 30000);

Employee headSales = new CompositeEmployee("Robert", "Head Sales", 20000);
Employee headMarketing = new CompositeEmployee("Michel", "Head Marketing", 20000);

Employee clerk1 = new Developer("Laura", "Marketing", 10000);
Employee clerk2 = new Developer("Bob", "Marketing", 10000);

Employee salesExecutive1 = new Developer("Richard", "Sales", 10000);
Employee salesExecutive2 = new Developer("Rob", "Sales", 10000);

CEO.add(headSales);
CEO.add(headMarketing);

headSales.add(salesExecutive1);
headSales.add(salesExecutive2);

headMarketing.add(clerk1);
headMarketing.add(clerk2);

// 打印所有员工
System.out.println(CEO);

for (Employee headEmployee : CEO.getSubordinates()) {
System.out.println(headEmployee);
for (Employee employee : headEmployee.getSubordinates()) {
System.out.println(employee);
}
}
}
}

优点

  1. 树形结构:组合模式允许你创建一个树形结构来表示部分和整体层次结构。
  2. 一致性:客户端可以一致地使用组合和单个对象,无需关心它们的具体类型。
  3. 易于扩展:可以很容易地增加新的叶子和组合类,不影响现有代码。

缺点

  1. 复杂性增加:对于简单的对象结构,使用组合模式会增加不必要的复杂性。
  2. 类型安全性:由于组合模式使用了通用的组件接口,可能会导致类型安全问题,特别是在需要特定类型操作的时候。

使用场景

  1. 部分-整体层次结构:需要表示对象的部分-整体层次结构,例如文件系统、组织结构、UI组件树等。
  2. 统一操作:希望客户端可以一致地使用组合对象和单个对象,而无需关心它们的区别。

组合模式通过将对象组合成树形结构来表示部分和整体的层次结构,使得客户端可以一致地使用单个对象和组合对象。在实际开发中,组合模式广泛应用于各种层次结构的场景,如文件系统、GUI组件等。

装饰者模式

装饰者模式(Decorator Pattern)是一种结构型设计模式,它允许你动态地给对象添加职责,而不会影响其他对象。装饰者模式提供了比继承更有弹性的替代方案,通过组合多个装饰者对象来增强功能。

主要组成部分

  1. 组件(Component):定义一个对象接口,可以给这些对象动态地添加职责。
  2. 具体组件(Concrete Component):实现组件接口的具体对象,职责可以动态地添加到这个对象。
  3. 装饰者(Decorator):实现组件接口,内部持有一个组件对象,具体装饰者类可以通过调用组件对象的相应方法,并对其进行扩展。
  4. 具体装饰者(Concrete Decorator):继承装饰者类,具体实现要添加的职责。

示例代码

假设我们有一个基本的饮料类,我们可以动态地给这个饮料添加不同的配料(如牛奶、糖等)。

组件接口

1
2
3
4
5
// 组件接口
public interface Beverage {
String getDescription(); // 获取描述
double cost(); // 获取价格
}

具体组件

1
2
3
4
5
6
7
8
9
10
11
12
// 具体组件
public class Espresso implements Beverage {
@Override
public String getDescription() {
return "Espresso"; // 浓缩咖啡
}

@Override
public double cost() {
return 1.99; // 价格
}
}

抽象装饰者

1
2
3
4
5
6
7
8
9
10
11
12
13
// 抽象装饰者
public abstract class CondimentDecorator implements Beverage {
protected Beverage beverage; // 被装饰的饮料

public CondimentDecorator(Beverage beverage) {
this.beverage = beverage;
}

@Override
public String getDescription() {
return beverage.getDescription();
}
}

具体装饰者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 具体装饰者 - 牛奶
public class Milk extends CondimentDecorator {
public Milk(Beverage beverage) {
super(beverage);
}

@Override
public String getDescription() {
return beverage.getDescription() + ", Milk"; // 添加牛奶
}

@Override
public double cost() {
return beverage.cost() + 0.30; // 加价
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 具体装饰者 - 糖
public class Sugar extends CondimentDecorator {
public Sugar(Beverage beverage) {
super(beverage);
}

@Override
public String getDescription() {
return beverage.getDescription() + ", Sugar"; // 添加糖
}

@Override
public double cost() {
return beverage.cost() + 0.20; // 加价
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
public class DecoratorPatternDemo {
public static void main(String[] args) {
Beverage beverage = new Espresso(); // 浓缩咖啡
System.out.println(beverage.getDescription() + " $" + beverage.cost());

beverage = new Milk(beverage); // 加牛奶
System.out.println(beverage.getDescription() + " $" + beverage.cost());

beverage = new Sugar(beverage); // 加糖
System.out.println(beverage.getDescription() + " $" + beverage.cost());
}
}

优点

  1. 灵活性:可以动态地扩展对象的功能,比继承更灵活。
  2. 职责分配:可以将不同的职责分配到不同的装饰者类中,符合单一职责原则。
  3. 避免类爆炸:通过组合而不是继承,可以避免由于多层次继承导致的类爆炸问题。

缺点

  1. 复杂性增加:由于增加了很多装饰者类,可能会使系统变得更加复杂。
  2. 调试困难:因为功能是动态添加的,调试和排查问题可能会变得更加困难。

使用场景

  1. 需要动态扩展对象功能:在不影响其他对象的情况下,动态地添加功能。
  2. 使用继承会导致类爆炸:希望通过组合来替代多层次的继承,以避免类爆炸问题。
  3. 需要不同组合的功能:希望通过不同的组合来实现不同的功能。

装饰者模式通过组合多个装饰者对象,能够在运行时动态地扩展对象的功能,而不影响其他对象。这使得系统具有更高的灵活性和可扩展性,适用于需要频繁扩展和变化的场景。

外观模式

外观模式(Facade Pattern)是一种结构型设计模式,它提供了一个统一的接口,用于访问子系统中的一组接口。外观模式定义了一个高层接口,使得客户端可以更加方便地使用子系统。

主要组成部分

  1. 外观(Facade):提供了一个高层接口,封装了子系统的一组接口,简化了客户端与子系统之间的交互。
  2. 子系统(Subsystem):实现了子系统的功能,但对客户端来说是不可见的。

示例代码

假设我们有一个电脑的启动过程,包括了启动CPU、内存、硬盘等多个子系统。

外观类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 外观类
public class ComputerFacade {
private CPU cpu;
private Memory memory;
private HardDrive hardDrive;

public ComputerFacade() {
this.cpu = new CPU();
this.memory = new Memory();
this.hardDrive = new HardDrive();
}

// 启动电脑
public void start() {
cpu.start();
memory.start();
hardDrive.start();
}
}

子系统类

1
2
3
4
5
6
7
// 子系统类 - CPU
public class CPU {
// 启动CPU
public void start() {
System.out.println("CPU is starting...");
}
}
1
2
3
4
5
6
7
// 子系统类 - 硬盘
public class HardDrive {
// 启动硬盘
public void start() {
System.out.println("Hard Drive is starting...");
}
}
1
2
3
4
5
6
7
// 子系统类 - 内存
public class Memory {
// 启动内存
public void start() {
System.out.println("Memory is starting...");
}
}

客户端代码

1
2
3
4
5
6
7
8
public class FacadePatternDemo {
public static void main(String[] args) {
// 创建电脑外观对象
ComputerFacade computer = new ComputerFacade();
// 启动电脑
computer.start();
}
}

优点

  1. 简化客户端:外观模式隐藏了子系统的复杂性,为客户端提供了一个简化的接口。
  2. 解耦合:客户端与子系统之间通过外观类进行通信,避免了直接依赖子系统的细节。
  3. 更好的封装性:外观类对子系统进行了封装,使得子系统的变化对客户端是透明的。

缺点

  1. 不符合开闭原则:外观类如果发生变化,可能会影响多个客户端。
  2. 过度封装:如果外观类设计不合理,可能会导致过度封装,使得系统难以维护。

使用场景

  1. 简化复杂系统:当系统中存在复杂的子系统,而客户端只需要使用部分功能时,可以考虑使用外观模式。
  2. 解耦合:当希望将子系统和客户端之间的依赖关系解耦合时,可以使用外观模式。
  3. 提供简单接口:当希望为客户端提供一个简单的接口,隐藏系统的复杂性时,可以使用外观模式。

外观模式通过提供一个统一的接口,封装了子系统的一组接口,简化了客户端与子系统之间的交互。这使得系统更易于维护和扩展,适用于需要隐藏复杂性、提供简单接口的场景。

享元模式

享元模式(Flyweight Pattern)是一种结构型设计模式,旨在通过共享对象来有效地支持大量细粒度的对象。它适用于系统中存在大量相似对象,而这些对象可以有效地共享相同的状态或属性。

主要组成部分

  1. 享元接口(Flyweight):定义了享元对象的接口,通过这个接口可以接受并作用于外部状态。
  2. 具体享元(Concrete Flyweight):实现了享元接口,包含了内部状态和共享的外部状态。
  3. 享元工厂(Flyweight Factory):负责创建和管理享元对象,通常实现了对象的池化,以便在需要时重复利用已经创建的对象。

示例代码

假设我们有一个简单的文本编辑器,需要大量的文本字符来组成文档。

享元接口

1
2
3
4
5
// 享元接口
public interface TextCharacter {
// 显示字符
void display();
}

具体享元类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 具体享元类
public class ConcreteTextCharacter implements TextCharacter {
// 内部状态,字符
private char character;

public ConcreteTextCharacter(char character) {
this.character = character;
}

@Override
// 显示字符
public void display() {
System.out.print(character);
}
}

享元工厂类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 享元工厂类
import java.util.HashMap;
import java.util.Map;

public class TextCharacterFactory {
// 字符缓存池
private static Map<Character, TextCharacter> characterMap = new HashMap<>();

// 获取字符对象
public static TextCharacter getTextCharacter(char character) {
if (!characterMap.containsKey(character)) {
// 如果缓存中没有,则创建新的字符对象并加入缓存
characterMap.put(character, new ConcreteTextCharacter(character));
}
return characterMap.get(character);
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class FlyweightPatternDemo {
public static void main(String[] args) {
// 待处理文档
String document = "Hello World!";

// 遍历文档中的每个字符
for (char c : document.toCharArray()) {
// 获取字符对象
TextCharacter textCharacter = TextCharacterFactory.getTextCharacter(c);
// 显示字符
textCharacter.display();
}
}
}

优点

  1. 减少内存消耗:通过共享相同的状态或属性,减少了系统中对象的数量,降低了内存消耗。
  2. 提高性能:共享对象可以在多个地方重复使用,提高了系统的性能。
  3. 减少对象创建:通过享元工厂对对象进行管理,可以避免频繁创建和销毁对象,提高了系统的效率。

缺点

  1. 复杂性增加:享元模式可能会引入额外的复杂性,包括共享状态的管理和同步问题。
  2. 可能会影响系统设计:需要仔细权衡对象的共享和独立性,不当的使用可能会导致系统设计上的局限性。

使用场景

  1. 系统中存在大量相似对象:如果系统中存在大量的相似对象,而这些对象可以共享相同的状态或属性,可以考虑使用享元模式。
  2. 需要缓存对象:如果需要频繁地创建和销毁对象,可以考虑使用享元模式来缓存对象,提高系统的性能和效率。

享元模式适用于需要大量细粒度对象,并且这些对象可以共享相同状态或属性的场景。通过共享对象来减少内存消耗和提高性能,可以有效地优化系统的设计和性能。

代理模式

代理模式(Proxy Pattern)是一种结构型设计模式,它允许你提供一个替代品或者占位符,以控制对其它对象的访问。代理对象通常在客户端和目标对象之间起到中介作用,客户端通过代理间接访问目标对象,从而可以在访问前后执行额外的操作。

主要组成部分

  1. 抽象主题(Subject):定义了目标对象和代理对象的共同接口,这样代理对象可以通过实现这个接口来替代目标对象。
  2. 真实主题(Real Subject):定义了代理对象所代表的目标对象,是业务逻辑的具体执行者。
  3. 代理(Proxy):保存了一个引用,使得代理可以访问目标对象,并提供与目标对象相同的接口,以便在需要时可以替代目标对象。

示例代码

假设我们有一个简单的图像查看器,需要加载大图像文件。为了避免每次都加载整个图像文件,我们可以使用代理模式来创建一个代理对象来加载图像。

抽象主题

1
2
3
4
5
// 抽象主题
public interface Image {
// 显示图像的方法
void display();
}

真实主题

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// 真实主题
public class RealImage implements Image {
// 图像文件名
private String filename;

// 构造方法,接受文件名并加载图像
public RealImage(String filename) {
this.filename = filename;
loadFromDisk();
}

@Override
// 显示图像
public void display() {
System.out.println("Displaying " + filename);
}

// 从磁盘加载图像
private void loadFromDisk() {
System.out.println("Loading " + filename);
}
}

代理类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 代理类
public class ProxyImage implements Image {
// 图像文件名
private String filename;
// 真实图像对象
private RealImage realImage;

// 构造方法,接受文件名
public ProxyImage(String filename) {
this.filename = filename;
}

@Override
// 显示图像
public void display() {
// 如果真实图像对象为空,则创建它
if (realImage == null) {
realImage = new RealImage(filename);
}
// 调用真实图像对象的显示方法
realImage.display();
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
public class ProxyPatternDemo {
public static void main(String[] args) {
// 创建代理图像对象
Image image = new ProxyImage("large_image.jpg");

// 图像将从磁盘加载
image.display();
System.out.println();

// 图像不会再次加载,直接从代理对象中获取
image.display();
}
}

优点

  1. 代理对象与目标对象分离:代理对象可以作为目标对象的代表,从而可以控制客户端对目标对象的访问。
  2. 代理对象可以扩展目标对象的功能:代理对象可以在访问目标对象之前或之后执行额外的操作,如权限验证、缓存等。
  3. 远程代理:可以通过代理对象在客户端和远程服务器之间进行通信,实现远程代理。

缺点

  1. 复杂性增加:引入了额外的间接性,可能会增加系统的复杂性。
  2. 性能开销:在访问目标对象时,需要经过代理对象,可能会带来一定的性能开销。

使用场景

  1. 远程代理:需要在客户端和远程服务器之间进行通信时,可以使用远程代理。
  2. 虚拟代理:需要延迟加载目标对象,或者在访问目标对象时执行额外的操作时,可以使用虚拟代理。
  3. 安全代理:需要控制对目标对象的访问权限时,可以使用安全代理。
  4. 缓存代理:需要缓存目标对象的结果,以提高访问速度时,可以使用缓存代理。

代理模式通过引入代理对象,控制客户端对目标对象的访问,并在访问前后执行额外的操作,从而可以更加灵活地管理和控制系统的行为。在实际开发中,代理模式广泛应用于需要对目标对象进行控制和管理的场景。

行为型模式

责任链模式

责任链模式(Chain of Responsibility Pattern)是一种行为型设计模式,它允许你将请求沿着处理者链进行传递,直到有一个处理者处理该请求为止。责任链模式将请求发送者和接收者解耦,使得多个对象都有机会处理该请求,而不需要显式指定接收者。

主要组成部分

  1. 处理者(Handler):定义了处理请求的接口,并维护了一个后继处理者的引用。
  2. 具体处理者(Concrete Handler):实现了处理请求的具体逻辑,并可以决定是否将请求传递给下一个处理者。
  3. 客户端(Client):创建请求,并将其发送给责任链的第一个处理者。

示例代码

假设我们有一个简单的报销审批系统,需要根据员工的职位级别来决定是否可以批准报销请求。高级别的员工可以审批更高额度的报销请求。

处理者接口

1
2
3
4
5
6
7
8
9
10
11
12
13
// 处理者接口
public abstract class Approver {
// 后继处理者
protected Approver successor;

// 设置后继处理者
public void setSuccessor(Approver successor) {
this.successor = successor;
}

// 处理请求的抽象方法
public abstract void processRequest(Request request);
}

具体处理者类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 具体处理者类 - 经理
public class Manager extends Approver {
@Override
// 处理请求的方法
public void processRequest(Request request) {
// 如果请求金额小于等于1000,经理可以批准
if (request.getAmount() <= 1000) {
System.out.println("Manager approves the request with amount: " + request.getAmount());
} else if (successor != null) {
// 否则,将请求传递给后继处理者
successor.processRequest(request);
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 具体处理者类 - 总监
public class Director extends Approver {
@Override
// 处理请求的方法
public void processRequest(Request request) {
// 如果请求金额小于等于5000,总监可以批准
if (request.getAmount() <= 5000) {
System.out.println("Director approves the request with amount: " + request.getAmount());
} else if (successor != null) {
// 否则,将请求传递给后继处理者
successor.processRequest(request);
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 具体处理者类 - CEO
public class CEO extends Approver {
@Override
// 处理请求的方法
public void processRequest(Request request) {
// 如果请求金额小于等于10000,CEO可以批准
if (request.getAmount() <= 10000) {
System.out.println("CEO approves the request with amount: " + request.getAmount());
} else {
// 否则,超出CEO的权限
System.out.println("Request exceeds CEO's authority.");
}
}
}

请求类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 请求类
public class Request {
// 请求金额
private double amount;

// 构造方法,接受请求金额
public Request(double amount) {
this.amount = amount;
}

// 获取请求金额
public double getAmount() {
return amount;
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class ChainOfResponsibilityPatternDemo {
public static void main(String[] args) {
// 创建处理者对象
Approver manager = new Manager();
Approver director = new Director();
Approver ceo = new CEO();

// 设置责任链
manager.setSuccessor(director);
director.setSuccessor(ceo);

// 创建请求对象
Request request1 = new Request(500);
// 处理请求
manager.processRequest(request1);

// 创建请求对象
Request request2 = new Request(5000);
// 处理请求
manager.processRequest(request2);

// 创建请求对象
Request request3 = new Request(15000);
// 处理请求
manager.processRequest(request3);
}
}

优点

  1. 降低耦合度:请求发送者和接收者解耦,可以灵活地组织处理链。
  2. 可扩展性:可以很容易地添加新的处理者,并将它们插入到处理链中。
  3. 灵活性:请求可以沿着处理链传递,直到有一个处理者处理为止。

缺点

  1. 性能问题:请求可能需要在整个处理链中传递,如果处理链过长或者过于复杂,可能会影响系统的性能。
  2. 请求未被处理的风险:如果处理链中没有处理请求的处理者,可能会导致请求未被处理。

使用场景

  1. 多级审批系统:适用于需要多级审批的场景,例如报销审批系统、请假审批系统等。
  2. 事件处理:适用于需要根据不同条件触发不同处理逻辑的场景,例如事件处理、异常处理等。

责任链模式通过将请求发送者和接收者解耦,使得多个对象都有机会处理请求,从而提高了系统的灵活性和可扩展性。它适用于多级审批、事件处理等场景,可以使得系统的设计更加灵活和可维护。

命令模式

命令模式(Command Pattern)是一种行为型设计模式,它将请求封装成一个对象,从而允许你将请求参数化、将请求排队、记录请求日志,以及支持可撤销的操作。命令模式将请求的发送者和接收者解耦,使得请求发送者无需知道请求的具体接收者,只需知道如何发送请求。

主要组成部分

  1. 命令(Command):声明了执行操作的接口,通常包含执行(execute)方法。
  2. 具体命令(Concrete Command):实现了命令接口,并封装了命令的接收者,负责调用接收者的相应方法。
  3. 接收者(Receiver):知道如何实施与执行一个请求相关的操作。
  4. 调用者/请求者(Invoker):负责调用命令对象执行请求的对象。
  5. 客户端(Client):创建具体命令对象并设置其接收者。

示例代码

假设我们有一个简单的遥控器,可以控制电灯的开关。

命令接口

1
2
3
4
5
// 命令接口
public interface Command {
// 执行命令的方法
void execute();
}

具体命令类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 具体命令类 - 开灯命令
public class TurnOnLightCommand implements Command {
// 持有一个接收者对象
private Light light;

// 构造方法,接受一个接收者对象
public TurnOnLightCommand(Light light) {
this.light = light;
}

@Override
// 执行开灯命令,调用接收者的开灯方法
public void execute() {
light.turnOn();
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 具体命令类 - 关灯命令
public class TurnOffLightCommand implements Command {
// 持有一个接收者对象
private Light light;

// 构造方法,接受一个接收者对象
public TurnOffLightCommand(Light light) {
this.light = light;
}

@Override
// 执行关灯命令,调用接收者的关灯方法
public void execute() {
light.turnOff();
}
}

接收者类

1
2
3
4
5
6
7
8
9
10
11
12
// 接收者类
public class Light {
// 开灯方法
public void turnOn() {
System.out.println("Light is on");
}

// 关灯方法
public void turnOff() {
System.out.println("Light is off");
}
}

请求者类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 请求者类
public class RemoteControl {
// 持有一个命令对象
private Command command;

// 设置命令对象
public void setCommand(Command command) {
this.command = command;
}

// 按下按钮,执行命令
public void pressButton() {
command.execute();
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class CommandPatternDemo {
public static void main(String[] args) {
// 创建接收者对象
Light light = new Light();

// 创建具体命令对象,传入接收者
Command turnOnCommand = new TurnOnLightCommand(light);
Command turnOffCommand = new TurnOffLightCommand(light);

// 创建请求者对象
RemoteControl remoteControl = new RemoteControl();

// 设置开灯命令,并执行
remoteControl.setCommand(turnOnCommand);
remoteControl.pressButton();

// 设置关灯命令,并执行
remoteControl.setCommand(turnOffCommand);
remoteControl.pressButton();
}
}

优点

  1. 松耦合:命令模式将请求发送者和接收者解耦,使得系统更加灵活。
  2. 可扩展性:可以很容易地添加新的命令和接收者,而不需要修改现有的代码。
  3. 支持撤销和恢复:命令对象可以记录操作历史,支持撤销和恢复操作。

缺点

  1. 类过多:可能会创建大量的命令类和接收者类,增加了系统的复杂性。
  2. 命令调用可能无法保证完全执行:如果命令的接收者是一个远程对象或者线程池中的对象,可能会导致命令的执行结果与期望不符。

使用场景

  1. 需要将请求发送者和接收者解耦:命令模式可以将请求发送者和接收者解耦,使得系统更加灵活。
  2. 需要支持撤销和恢复操作:命令模式可以记录操作历史,支持撤销和恢复操作,适用于需要此功能的场景。

命令模式通过将请求封装成一个对象,实现了请求的发送者和接收者之间的解耦,使得系统更加灵活和可扩展。它适用于需要将请求发送者和接收者解耦、支持撤销和恢复操作的场景。

解释器模式

解释器模式(Interpreter Pattern)是一种行为型设计模式,它定义了一种语言的文法,并且建立一个解释器来解释该语言中的句子。通过使用解释器模式,可以将复杂的问题表达为简单的语言,然后利用解释器来解释这个语言,从而可以轻松地改变或扩展这个语言。

主要组成部分

  1. 抽象表达式(Abstract Expression):声明一个抽象的解释操作,通常是一个抽象类或接口。
  2. 终结符表达式(Terminal Expression):实现了抽象表达式的解释操作,通常是文法中的基本单元。
  3. 非终结符表达式(Non-terminal Expression):实现了抽象表达式的解释操作,并且通过递归调用来解释语言中的复杂语句。
  4. 环境类(Context):包含解释器解释的全局信息。

示例代码

假设我们有一个简单的算术表达式解释器,可以解释加法和乘法运算。

抽象表达式

1
2
3
4
5
// 抽象表达式接口
public interface Expression {
// 解释操作,传入上下文对象
int interpret(Context context);
}

终结符表达式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 终结符表达式 - 变量表达式
public class VariableExpression implements Expression {
// 变量名称
private String variable;

// 构造方法,传入变量名称
public VariableExpression(String variable) {
this.variable = variable;
}

@Override
// 解释变量表达式,从上下文中获取变量的值
public int interpret(Context context) {
return context.getValue(variable);
}
}

非终结符表达式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 非终结符表达式 - 加法表达式
public class AddExpression implements Expression {
// 左右两个操作数表达式
private Expression leftExpression;
private Expression rightExpression;

// 构造方法,传入左右操作数表达式
public AddExpression(Expression leftExpression, Expression rightExpression) {
this.leftExpression = leftExpression;
this.rightExpression = rightExpression;
}

@Override
// 解释加法表达式,计算左右操作数的值并相加
public int interpret(Context context) {
return leftExpression.interpret(context) + rightExpression.interpret(context);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 非终结符表达式 - 乘法表达式
public class MultiplyExpression implements Expression {
// 左右两个操作数表达式
private Expression leftExpression;
private Expression rightExpression;

// 构造方法,传入左右操作数表达式
public MultiplyExpression(Expression leftExpression, Expression rightExpression) {
this.leftExpression = leftExpression;
this.rightExpression = rightExpression;
}

@Override
// 解释乘法表达式,计算左右操作数的值并相乘
public int interpret(Context context) {
return leftExpression.interpret(context) * rightExpression.interpret(context);
}
}

环境类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
import java.util.HashMap;
import java.util.Map;


// 环境类,保存变量的值
public class Context {
// 存储变量名与值的映射
private Map<String, Integer> variables = new HashMap<>();

// 设置变量的值
public void setVariable(String variable, int value) {
variables.put(variable, value);
}

// 获取变量的值
public int getValue(String variable) {
return variables.get(variable);
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class InterpreterPatternDemo {
public static void main(String[] args) {
// 创建上下文对象,并设置变量的值
Context context = new Context();
context.setVariable("x", 5);
context.setVariable("y", 10);

// 构建表达式 (x + (y * x))
Expression expression = new AddExpression(
new VariableExpression("x"),
new MultiplyExpression(
new VariableExpression("y"),
new VariableExpression("x")
)
);

// 解释表达式,并输出结果
int result = expression.interpret(context);
System.out.println("Result: " + result); // 输出结果:55
}
}

优点

  1. 扩展性:可以很容易地扩展语法,增加新的解释器实现新的语法规则。
  2. 易于实现:每个文法规则都可以实现为一个解释器,简单易懂。

缺点

  1. 复杂度:对于复杂的文法规则,可能需要大量的解释器类来实现,增加了系统的复杂性。
  2. 效率问题:由于解释器模式是递归的,可能会导致一些效率问题,尤其是处理复杂语法时。

使用场景

  1. DSL(Domain Specific Language)解析:解释器模式适用于需要解析和执行DSL的场景。
  2. 编译器:解释器模式可以用于构建简单的编译器。
  3. 规则引擎:解释器模式可以用于构建规则引擎,用于解析和执行规则。

解释器模式通过将语言的文法定义为一组解释器,然后使用解释器来解释这个语言,使得系统更加灵活和可扩展。它适用于需要解析和执行自定义语言或规则的场景。

迭代器模式

迭代器模式(Iterator Pattern)是一种行为型设计模式,它提供了一种方法顺序访问一个聚合对象中的各个元素,而又不暴露其内部的表示。迭代器模式将遍历操作从聚合对象中分离出来,使得聚合对象和遍历操作可以独立变化。

主要组成部分

  1. 迭代器接口(Iterator):定义了访问和遍历聚合对象中元素的接口。
  2. 具体迭代器(Concrete Iterator):实现了迭代器接口,并跟踪当前位置在聚合对象中的位置。
  3. 聚合接口(Aggregate):定义了创建相应迭代器对象的接口。
  4. 具体聚合(Concrete Aggregate):实现了聚合接口,返回相应的迭代器对象。

示例代码

假设我们有一个简单的集合类 MyList,需要实现迭代器来遍历集合中的元素。

迭代器接口

1
2
3
4
5
6
7
// 迭代器接口
public interface Iterator<T> {
// 检查是否还有下一个元素
boolean hasNext();
// 返回下一个元素
T next();
}

具体迭代器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
import java.util.NoSuchElementException;

// 具体迭代器
public class MyListIterator<T> implements Iterator<T> {
private MyList<T> list; // 具体的集合对象
private int index = 0; // 当前遍历的位置

// 构造方法,传入具体的集合对象
public MyListIterator(MyList<T> list) {
this.list = list;
}

@Override
// 检查是否还有下一个元素
public boolean hasNext() {
return index < list.size();
}

@Override
// 返回下一个元素
public T next() {
if (!hasNext()) {
throw new NoSuchElementException();
}
return list.get(index++);
}
}

聚合接口

1
2
3
4
5
6
7
8
9
10
11
// 聚合接口
public interface MyList<T> {
// 添加元素
void add(T element);
// 获取指定位置的元素
T get(int index);
// 返回集合的大小
int size();
// 返回迭代器对象
Iterator<T> iterator();
}

具体聚合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
import java.util.ArrayList;
import java.util.List;

// 具体聚合
public class MyArrayList<T> implements MyList<T> {
private List<T> elements = new ArrayList<>(); // 内部存储元素的集合

@Override
// 添加元素到集合
public void add(T element) {
elements.add(element);
}

@Override
// 获取指定位置的元素
public T get(int index) {
return elements.get(index);
}

@Override
// 返回集合的大小
public int size() {
return elements.size();
}

@Override
// 返回迭代器对象
public Iterator<T> iterator() {
return new MyListIterator<>(this);
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class IteratorPatternDemo {
public static void main(String[] args) {
MyList<Integer> list = new MyArrayList<>();
list.add(1);
list.add(2);
list.add(3);

// 获取迭代器对象
Iterator<Integer> iterator = list.iterator();
// 遍历集合中的元素
while (iterator.hasNext()) {
System.out.println(iterator.next());
}
}
}

优点

  1. 分离聚合对象和迭代器:迭代器模式将遍历操作从聚合对象中分离出来,使得聚合对象和遍历操作可以独立变化。
  2. 简化聚合对象的接口:由于遍历操作被移到迭代器中,聚合对象的接口变得更简单,只需要实现迭代器的获取方法即可。

缺点

  1. 迭代器遍历方式固定:具体迭代器只能实现一种遍历方式,无法灵活切换。

使用场景

  1. 需要遍历聚合对象的场景:当需要遍历一个聚合对象中的元素,并且不暴露其内部表示时,可以使用迭代器模式。
  2. 需要提供多种遍历方式:当需要提供多种不同的遍历方式时,可以为每种遍历方式创建一个具体迭代器。

迭代器模式通过将遍历操作从聚合对象中分离出来,使得聚合对象和遍历操作可以独立变化,提高了系统的灵活性和可扩展性。它适用于需要遍历聚合对象的场景,且希望提供多种遍历方式的场景。

中介者模式

中介者模式(Mediator Pattern)是一种行为型设计模式,它允许对象之间通过一个中介者对象进行通信,而不是直接相互引用。中介者模式将系统中的交互关系集中管理,减少了对象之间的直接耦合,使得系统更加灵活可扩展。

主要组成部分

  1. 中介者(Mediator):定义了一个接口用于与各同事对象通信,并封装了各同事对象之间的交互关系。
  2. 具体中介者(Concrete Mediator):实现了中介者接口,并负责协调各同事对象之间的交互关系。
  3. 同事(Colleague):定义了一个接口用于与中介者进行通信,并将自己的状态通知中介者。
  4. 具体同事(Concrete Colleague):实现了同事接口,并与其他同事对象通过中介者进行通信。

示例代码

假设我们有一个简单的聊天室应用,需要实现用户之间的消息交流,但是用户之间不直接通信,而是通过一个聊天室中介者进行通信。

中介者接口

1
2
3
4
5
6
7
// 中介者接口
public interface ChatMediator {
// 发送消息的方法
void sendMessage(String message, User user);
// 添加用户的方法
void addUser(User user);
}

具体中介者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
import java.util.ArrayList;
import java.util.List;

// 具体中介者
public class ChatRoom implements ChatMediator {
private List<User> users = new ArrayList<>();

@Override
public void sendMessage(String message, User user) {
// 通知所有用户
for (User u : users) {
// 消息不需要发给发送消息的用户自己
if (u != user) {
u.receiveMessage(message);
}
}
}

@Override
public void addUser(User user) {
users.add(user);
}
}

同事接口

1
2
3
4
5
6
7
8
9
10
11
12
13
// 同事接口
public abstract class User {
protected ChatMediator mediator;
protected String name;

public User(ChatMediator mediator, String name) {
this.mediator = mediator;
this.name = name;
}

public abstract void sendMessage(String message);
public abstract void receiveMessage(String message);
}

具体同事

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 具体同事
public class BasicUser extends User {
public BasicUser(ChatMediator mediator, String name) {
super(mediator, name);
}

@Override
public void sendMessage(String message) {
System.out.println(name + " sends message: " + message);
mediator.sendMessage(message, this);
}

@Override
public void receiveMessage(String message) {
System.out.println(name + " receives message: " + message);
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class MediatorPatternDemo {
public static void main(String[] args) {
ChatMediator chatRoom = new ChatRoom();

User user1 = new BasicUser(chatRoom, "User1");
User user2 = new BasicUser(chatRoom, "User2");
User user3 = new BasicUser(chatRoom, "User3");

chatRoom.addUser(user1);
chatRoom.addUser(user2);
chatRoom.addUser(user3);

user1.sendMessage("Hello, everyone!");
user2.sendMessage("Hi, User1!");
}
}

优点

  1. 减少耦合:中介者模式将对象之间的交互关系集中管理,减少了对象之间的直接耦合。
  2. 简化对象:由于对象之间的交互逻辑被封装在中介者中,对象可以更专注于自己的业务逻辑,代码更加简洁清晰。

缺点

  1. 中介者过于庞大:中介者模式可能会导致中介者对象变得过于庞大,处理过多的逻辑,使得代码难以维护。

使用场景

  1. 多个对象之间存在复杂的交互关系:当系统中多个对象之间存在复杂的交互关系时,可以使用中介者模式来简化对象之间的交互逻辑。
  2. 减少子类生成:当对象之间存在很多的交互关系,并且需要通过子类来实现不同的交互逻辑时,可以使用中介者模式来减少子类的生成。

中介者模式通过引入一个中介者对象来封装对象之间的交互关系,使得对象之间不直接相互引用,减少了对象之间的耦合,提高了系统的灵活性和可维护性。它适用于多个对象之间存在复杂的交互关系,并且需要减少对象之间的直接耦合的场景。

备忘录模式

备忘录模式(Memento Pattern)是一种行为型设计模式,它允许你捕获一个对象的内部状态,并在该对象之外保存这个状态,以便在以后的时候将该对象恢复到原先保存的状态。备忘录模式主要用于在不破坏封装性的前提下,捕获对象的内部状态并在外部保存、恢复这些状态。

主要组成部分

  1. 备忘录(Memento):负责存储原始对象的内部状态。备忘录可以保护其状态免受直接访问,只允许发起者(Originator)访问备忘录的内部状态。
  2. 发起者(Originator):负责创建备忘录,并记录其当前内部状态。可以使用备忘录保存和恢复自己的状态。
  3. 管理者(Caretaker):负责保存备忘录。管理者不应该修改或检查备忘录的内容,只负责存储备忘录。

示例代码

假设我们有一个文本编辑器,用户可以对文本进行编辑,我们希望能够保存历史版本,并在需要时进行恢复。

备忘录

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 备忘录类,负责存储文本编辑器的内容
public class EditorMemento {
private final String content; // 保存的内容

// 构造函数,用于初始化备忘录的内容
public EditorMemento(String content) {
this.content = content;
}

// 获取备忘录的内容
public String getContent() {
return content;
}
}

发起者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 发起者类,负责创建和恢复备忘录
public class TextEditor {
private String content; // 当前编辑器的内容

// 获取当前内容
public String getContent() {
return content;
}

// 设置编辑器的内容
public void setContent(String content) {
this.content = content;
}

// 创建一个包含当前内容的备忘录
public EditorMemento save() {
return new EditorMemento(content);
}

// 从备忘录恢复内容
public void restore(EditorMemento memento) {
content = memento.getContent();
}
}

管理者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import java.util.ArrayList;
import java.util.List;

// 管理者类,负责保存和恢复备忘录
public class History {
private final List<EditorMemento> mementos = new ArrayList<>(); // 保存备忘录的列表

// 将备忘录添加到列表中
public void push(EditorMemento memento) {
mementos.add(memento);
}

// 从列表中取出最后一个备忘录,并将其移除
public EditorMemento pop() {
if (!mementos.isEmpty()) {
return mementos.remove(mementos.size() - 1);
}
return null; // 如果列表为空,返回null
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class MementoPatternDemo {
public static void main(String[] args) {
TextEditor editor = new TextEditor(); // 创建文本编辑器
History history = new History(); // 创建历史记录管理者

editor.setContent("Version 1.0"); // 设置编辑器内容为"Version 1.0"
history.push(editor.save()); // 保存当前内容到历史记录

editor.setContent("Version 2.0"); // 设置编辑器内容为"Version 2.0"
history.push(editor.save()); // 保存当前内容到历史记录

editor.setContent("Version 3.0"); // 设置编辑器内容为"Version 3.0"
history.push(editor.save()); // 保存当前内容到历史记录

// 恢复到上一个版本
editor.restore(history.pop()); // 从历史记录中恢复到上一个版本
System.out.println(editor.getContent()); // 输出当前内容,结果应为"Version 2.0"

// 恢复到上一个版本
editor.restore(history.pop()); // 从历史记录中恢复到再上一个版本
System.out.println(editor.getContent()); // 输出当前内容,结果应为"Version 1.0"
}
}

优点

  1. 封装性:备忘录模式将备忘录的存储和恢复逻辑封装在发起者和管理者中,使得原始对象的状态对客户端透明。
  2. 可扩展性:可以通过扩展备忘录类和发起者类来支持更多的备忘录功能。

缺点

  1. 资源消耗:如果备忘录对象过多或过大,可能会消耗大量内存和处理时间。

使用场景

  1. 需要保存对象状态的场景:当需要保存对象的内部状态,并在需要时能够恢复到原先的状态时,可以使用备忘录模式。
  2. 需要实现“撤销”功能的场景:当需要实现撤销功能时,可以使用备忘录模式来保存对象的历史状态。

备忘录模式通过将对象的状态保存在备忘录中,并通过发起者和管理者来管理备忘录,实现了对象状态的保存和恢复,提高了系统的灵活性和可维护性。它适用于需要保存对象状态或实现“

观察者模式

观察者模式(Observer Pattern)是一种行为型设计模式,它定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象,当主题对象状态发生变化时,会通知所有的观察者对象,使它们能够自动更新自己。

主要组成部分

  1. 主题(Subject):也称为被观察者或发布者,维护了一组观察者对象,并提供了添加、删除和通知观察者的方法。
  2. 观察者(Observer):也称为订阅者或观察者,定义了一个更新接口,用于接收并响应主题状态的变化。
  3. 具体主题(Concrete Subject):实现了主题接口,负责维护一组观察者,并在状态发生变化时通知观察者。
  4. 具体观察者(Concrete Observer):实现了观察者接口,负责接收主题的通知,并更新自身状态。

示例代码

假设我们有一个简单的气象站应用,需要将气象数据实时展示给观察者。

主题接口

1
2
3
4
5
6
7
8
9
10
11
// 主题接口,定义了添加、删除和通知观察者的方法
public interface Subject {
// 添加观察者
void addObserver(Observer observer);

// 删除观察者
void removeObserver(Observer observer);

// 通知所有观察者
void notifyObservers();
}

观察者接口

1
2
3
4
5
// 观察者接口,定义了更新方法,用于接收主题的通知
public interface Observer {
// 更新方法,接收气象数据
void update(float temperature, float humidity, float pressure);
}

具体主题

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
import java.util.ArrayList;
import java.util.List;

// 具体主题,实现了主题接口
public class WeatherData implements Subject {
private List<Observer> observers = new ArrayList<>(); // 存储观察者的列表
private float temperature; // 当前温度
private float humidity; // 当前湿度
private float pressure; // 当前气压

// 添加观察者到列表中
@Override
public void addObserver(Observer observer) {
observers.add(observer);
}

// 从列表中移除观察者
@Override
public void removeObserver(Observer observer) {
observers.remove(observer);
}

// 通知所有观察者,调用它们的更新方法
@Override
public void notifyObservers() {
for (Observer observer : observers) {
observer.update(temperature, humidity, pressure);
}
}

// 当气象数据发生变化时,通知所有观察者
public void measurementsChanged() {
notifyObservers();
}

// 设置新的气象数据,并通知观察者
public void setMeasurements(float temperature, float humidity, float pressure) {
this.temperature = temperature;
this.humidity = humidity;
this.pressure = pressure;
measurementsChanged(); // 气象数据发生变化,通知观察者
}
}

具体观察者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 具体观察者,实现了观察者接口
public class Display implements Observer {
private float temperature; // 当前温度
private float humidity; // 当前湿度
private float pressure; // 当前气压

// 更新方法,接收并保存气象数据,然后显示
@Override
public void update(float temperature, float humidity, float pressure) {
this.temperature = temperature;
this.humidity = humidity;
this.pressure = pressure;
display(); // 显示当前气象数据
}

// 显示气象数据
public void display() {
System.out.println("Current conditions: " + temperature + "F degrees and " + humidity + "% humidity");
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class ObserverPatternDemo {
/**
* 观察者模式
*
* @param args
*/
public static void main(String[] args) {
WeatherData weatherData = new WeatherData(); // 创建具体主题

Display display = new Display(); // 创建具体观察者
weatherData.addObserver(display); // 将观察者添加到主题中

// 设置新的气象数据,观察者会自动更新并显示
weatherData.setMeasurements(80, 65, 30.4f); // 输出: Current conditions: 80.0F degrees and 65.0% humidity
}
}

优点

  1. 松耦合:主题和观察者之间是松耦合的,使得它们可以独立地进行扩展和修改。
  2. 可重用性:可以轻松地添加新的观察者和主题,以适应系统的变化和扩展。
  3. 通知机制:主题对象会通知所有观察者,使得观察者可以自动更新自己的状态。

缺点

  1. 可能导致性能问题:如果观察者数量过多或者观察者的更新操作过于复杂,可能会影响主题对象的性能。

使用场景

  1. 多个对象之间存在一对多的依赖关系:当一个对象的状态发生变化需要通知多个对象时,可以使用观察者模式。
  2. 需要实现一种对象与多个对象之间的松耦合关系:当一个对象与多个对象之间需要保持松耦合关系,以便实现对象之间的协作时,可以使用观察者模式。

观察者模式通过定义一种一对多的依赖关系,使得一个主题对象状态的改变可以自动通知多个观察者对象,从而实现对象之间的协作。它适用于多个对象之间存在一对多的依赖关系的场景,例如GUI界面中的事件处理、消息订阅发布系统等。

状态模式

状态模式(State Pattern)是一种行为型设计模式,它允许对象在其内部状态改变时改变它的行为。状态模式通过将对象的状态封装成独立的状态类,使得对象在不同的状态下具有不同的行为,并且可以在运行时动态地改变状态。

主要组成部分

  1. 环境(Context):定义了客户端感兴趣的接口,并且维护一个当前状态对象的引用。
  2. 状态(State):定义了一个接口或抽象类,用于封装环境对象中特定状态相关的行为。
  3. 具体状态(Concrete State):实现了状态接口或抽象类,负责实现该状态下的具体行为。

示例代码

假设我们有一个简单的电梯系统,需要实现电梯在不同状态下的行为。

环境接口

1
2
3
4
5
6
7
// 环境接口,定义了电梯状态的行为
public interface ElevatorState {
void open(); // 开门
void close(); // 关门
void move(); // 移动
void stop(); // 停止
}

具体状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// 具体状态 - 开门状态
public class OpenState implements ElevatorState {
@Override
public void open() {
System.out.println("The door is already open."); // 门已经开了
}

@Override
public void close() {
System.out.println("Close the door."); // 关门
}

@Override
public void move() {
System.out.println("Cannot move when the door is open."); // 门开着时无法移动
}

@Override
public void stop() {
System.out.println("Stop the elevator."); // 停止电梯
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// 具体状态 - 关门状态
public class CloseState implements ElevatorState {
@Override
public void open() {
System.out.println("Open the door."); // 开门
}

@Override
public void close() {
System.out.println("The door is already closed."); // 门已经关了
}

@Override
public void move() {
System.out.println("Move the elevator."); // 移动电梯
}

@Override
public void stop() {
System.out.println("Stop the elevator."); // 停止电梯
}
}

环境类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// 环境类,维护当前电梯状态并调用相应的方法
public class Elevator {
private ElevatorState currentState; // 当前电梯状态

// 设置当前状态
public void setState(ElevatorState state) {
this.currentState = state;
}

// 开门
public void open() {
currentState.open();
}

// 关门
public void close() {
currentState.close();
}

// 移动
public void move() {
currentState.move();
}

// 停止
public void stop() {
currentState.stop();
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
public class StatePatternDemo {
public static void main(String[] args) {
Elevator elevator = new Elevator(); // 创建电梯对象
elevator.setState(new CloseState()); // 初始状态为关门状态

elevator.open(); // Output: Open the door. 开门
elevator.close(); // Output: Close the door. 关门
elevator.move(); // Output: Move the elevator. 移动
elevator.open(); // Output: The door is already open. 门已经开了
}
}

优点

  1. 封装性:状态模式将状态封装在独立的状态类中,使得状态具有较好的封装性,客户端无需了解状态的具体实现。
  2. 扩展性:可以很容易地增加新的状态类,而无需修改原有代码,符合开闭原则。
  3. 减少条件分支:状态模式将状态的判断转移到了状态类中,减少了大量的条件分支判断。

缺点

  1. 可能引入过多的状态类:如果状态过多或者状态类过于复杂,可能会引入过多的状态类,导致系统变得复杂。

使用场景

  1. 对象的行为取决于其状态,并且状态可能在运行时发生改变:当对象的行为取决于其状态,并且状态可能在运行时发生改变时,可以使用状态模式。
  2. 避免使用大量的条件分支:当对象的行为存在大量的条件分支,并且这些条件分支随着状态的改变而改变时,可以使用状态模式。

状态模式通过将对象的状态封装成独立的状态类,并在环境对象中维护一个当前状态对象的引用,使得对象在不同的状态下具有不同的行为,并且可以在运行时动态地改变状态。它适用于对象的行为取决于其状态,并且状态可能在运行时发生改变的场景。

策略模式

策略模式(Strategy Pattern)是一种行为型设计模式,它定义了一系列算法,并将每个算法封装成单独的类,使得它们可以互相替换,而且客户端调用它们的方式保持一致。

主要组成部分

  1. 策略接口(Strategy):定义了算法族的通用接口,可以是抽象类或接口。
  2. 具体策略(Concrete Strategy):实现了策略接口,包含了具体的算法。
  3. 环境类(Context):持有一个策略对象的引用,并在需要时调用策略对象的方法执行算法。

示例代码

假设我们有一个电商平台,针对不同的支付方式需要实现不同的支付策略。

策略接口

1
2
3
4
// 策略接口,定义了支付策略的通用接口
public interface PaymentStrategy {
void pay(double amount); // 支付方法
}

具体策略

1
2
3
4
5
6
7
// 具体策略 - 支付宝支付
public class AlipayStrategy implements PaymentStrategy {
@Override
public void pay(double amount) {
System.out.println("Paid " + amount + " yuan via Alipay."); // 支付宝支付
}
}
1
2
3
4
5
6
7
// 具体策略 - 微信支付
public class WechatPayStrategy implements PaymentStrategy {
@Override
public void pay(double amount) {
System.out.println("Paid " + amount + " yuan via WeChat Pay."); // 微信支付
}
}

环境类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 环境类,持有一个支付策略对象的引用,并在需要时调用支付策略对象的方法执行支付
public class PaymentContext {
private PaymentStrategy paymentStrategy; // 支付策略对象

public PaymentContext(PaymentStrategy paymentStrategy) {
this.paymentStrategy = paymentStrategy;
}

// 设置支付策略
public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
this.paymentStrategy = paymentStrategy;
}

// 执行支付
public void executePayment(double amount) {
paymentStrategy.pay(amount);
}
}

客户端代码

1
2
3
4
5
6
7
8
9
public class StrategyPatternDemo {
public static void main(String[] args) {
PaymentContext context = new PaymentContext(new AlipayStrategy()); // 创建支付环境对象,使用支付宝支付策略
context.executePayment(100); // Output: Paid 100.0 yuan via Alipay. 使用支付宝支付100元

context.setPaymentStrategy(new WechatPayStrategy()); // 切换支付策略为微信支付
context.executePayment(50); // Output: Paid 50.0 yuan via WeChat Pay. 使用微信支付50元
}
}

优点

  1. 灵活性:策略模式允许在运行时动态地切换算法,客户端可以根据需要选择不同的算法。
  2. 可扩展性:可以很容易地添加新的策略类,而无需修改原有代码,符合开闭原则。
  3. 简化代码:策略模式避免了大量的条件分支判断,使得代码更加清晰简洁。

缺点

  1. 客户端必须了解所有的策略类:客户端必须了解所有的策略类,并且在选择具体策略时需要进行判断,增加了客户端的复杂度。

使用场景

  1. 需要在不同场景下使用不同算法的场景:当一个系统需要动态地在几种算法中选择一种执行时,可以使用策略模式。
  2. 需要封装算法的场景:当系统有多种类似的算法,可以使用策略模式封装这些算法,使得它们可以互相替换。

策略模式通过将算法封装成独立的策略类,并在环境类中持有一个策略对象的引用,使得客户端调用策略对象的方式保持一致,同时可以动态地切换算法。它适用于需要在不同场景下使用不同算法或封装算法的场景。

模板方法模式

模板方法模式(Template Method Pattern)是一种行为型设计模式,它定义了一个算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下,重新定义算法的某些步骤。

主要组成部分

  1. 模板类(Abstract Class):定义了一个算法的框架,其中包含了算法的主要逻辑以及一系列抽象方法或具体方法,这些方法可以是固定的、可选的或空的。
  2. 具体子类(Concrete Class):实现了模板类中的抽象方法,完成了算法中特定步骤的具体实现。

示例代码

假设我们有一个制作咖啡和茶的流程,流程中有一些共同的步骤,但是某些步骤在制作咖啡和茶时可能不同。

模板类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// 模板类,定义了制作饮料的算法框架
public abstract class Beverage {
// 模板方法,定义了制作饮料的步骤
public final void prepareBeverage() {
boilWater(); // 具体步骤1:煮水
brew(); // 抽象方法,子类实现,冲泡
pourInCup(); // 具体步骤3:倒入杯中
if (addCondiments()) { // 钩子方法,控制是否添加调料
addCondiments(); // 具体步骤4:添加调料
}
}

// 抽象方法,由子类实现,具体的冲泡方法
protected abstract void brew();

// 具体方法,煮水
private void boilWater() {
System.out.println("Boiling water");
}

// 具体方法,倒入杯中
private void pourInCup() {
System.out.println("Pouring into cup");
}

// 钩子方法,子类可以选择性地覆盖该方法
protected boolean addCondiments() {
return true; // 默认为true,表示需要添加调料
}
}

具体子类 - 制作咖啡

1
2
3
4
5
6
7
8
9
10
11
12
13
// 具体子类 - 制作咖啡
public class Coffee extends Beverage {
@Override
protected void brew() {
System.out.println("Dripping coffee through filter"); // 具体的冲泡方法
}

@Override
protected boolean addCondiments() {
System.out.println("Adding sugar and milk"); // 添加咖啡调料
return false; // 不需要再次添加调料
}
}

具体子类 - 制作茶

1
2
3
4
5
6
7
8
9
10
11
12
13
// 具体子类 - 制作茶
public class Tea extends Beverage {
@Override
protected void brew() {
System.out.println("Steeping the tea"); // 具体的冲泡方法
}

@Override
protected boolean addCondiments() {
System.out.println("Adding lemon"); // 添加茶调料
return true; // 需要再次添加调料
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
public class TemplateMethodPatternDemo {
public static void main(String[] args) {
Beverage coffee = new Coffee(); // 创建制作咖啡的对象
System.out.println("Making coffee..."); // 制作咖啡
coffee.prepareBeverage(); // 调用模板方法制作咖啡

System.out.println();

Beverage tea = new Tea(); // 创建制作茶的对象
System.out.println("Making tea..."); // 制作茶
tea.prepareBeverage(); // 调用模板方法制作茶
}
}

优点

  1. 复用性:模板方法模式将算法的骨架封装在模板类中,可以在不改变算法结构的情况下,复用算法中的公共部分。
  2. 扩展性:模板方法模式允许子类重新定义算法的某些步骤,从而实现算法的动态扩展。
  3. 可维护性:模板方法模式将算法的主要逻辑和细节部分分离,使得系统更容易维护和扩展。

缺点

  1. 逻辑复杂性:模板方法模式可能会导致子类的数量增加,从而使得系统变得更加复杂。

使用场景

  1. 多个子类有共同的行为:当多个子类有共同的行为,并且这些行为可以被封装成一个公共方法时,可以使用模板方法模式。
  2. 不同的子类需要实现相似的算法:当不同的子类需要实现相似的算法,并且这些算法的框架已经确定时,可以使用模板方法模式。

模板方法模式通过定义一个算法的骨架,将一些步骤延迟到子类中实现,从而实现了算法的复用和扩展。它适用于多个子类有共同的行为或不同的子类需要实现相似的算法的场景。

在示例代码中,Beverage 类定义了制作饮料的算法骨架,其中包含了煮水、冲泡、倒入杯中等步骤,并且将添加调料的步骤设计为钩子方法,子类可以选择是否实现该步骤。具体的饮料类如 CoffeeTea 分别实现了不同的冲泡和添加调料的步骤。

使用模板方法模式,可以轻松实现不同饮料的制作过程,并且在需要修改某一步骤时,只需要在相应的子类中进行修改,而不影响整体的算法结构。

访问者模式

访问者模式(Visitor Pattern)是一种行为型设计模式,它可以在不改变已有类的情况下,定义对这些类新的操作。该模式将数据结构与数据操作分离开来,使得数据结构的增加或修改不会影响到数据操作的变化。

主要组成部分

  1. 访问者接口(Visitor):定义了对于每个元素类所提供的访问操作方法。在访问者模式中,这个接口是最重要的部分,每个具体的访问者都要实现这个接口。
  2. 具体访问者(Concrete Visitor):实现了访问者接口中定义的操作方法,提供了对于元素对象的具体访问行为。
  3. 元素接口(Element):定义了一个 accept 方法,该方法需要传入一个访问者对象作为参数,用来接受访问者的访问。
  4. 具体元素(Concrete Element):实现了元素接口,提供了 accept 方法的具体实现。
  5. 对象结构(Object Structure):维护了一个元素的集合,并提供了遍历这些元素的方法,用于供访问者访问。

示例代码

假设我们有一个简单的员工管理系统,其中包含不同类型的员工,我们希望对这些员工进行不同类型的访问。

元素接口

1
2
3
4
// 元素接口,定义了 accept 方法,用于接受访问者的访问
public interface Element {
void accept(Visitor visitor);
}

具体元素 - 全职员工

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// 具体元素 - 全职员工
public class FullTimeEmployee implements Element {
private String name;
private double salary;

// 构造函数
public FullTimeEmployee(String name, double salary) {
this.name = name;
this.salary = salary;
}

// 获取员工姓名
public String getName() {
return name;
}

// 获取员工薪水
public double getSalary() {
return salary;
}

// 接受访问者的访问
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}

具体元素 - 兼职员工

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// 具体元素 - 兼职员工
public class PartTimeEmployee implements Element {
private String name;
private double workingHours;

// 构造函数
public PartTimeEmployee(String name, double workingHours) {
this.name = name;
this.workingHours = workingHours;
}

// 获取员工姓名
public String getName() {
return name;
}

// 获取员工工作小时数
public double getWorkingHours() {
return workingHours;
}

// 接受访问者的访问
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}

访问者接口

1
2
3
4
5
// 访问者接口,定义了 visit 方法,用于访问具体元素
public interface Visitor {
void visit(FullTimeEmployee employee);
void visit(PartTimeEmployee employee);
}

具体访问者 - 薪资计算器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 具体访问者 - 薪资计算器
public class SalaryCalculator implements Visitor {
// 访问全职员工
@Override
public void visit(FullTimeEmployee employee) {
double salary = employee.getSalary();
System.out.println("Full-time employee " + employee.getName() + "'s salary is " + salary);
}

// 访问兼职员工
@Override
public void visit(PartTimeEmployee employee) {
double salary = employee.getWorkingHours() * 100; // 假设时薪为100
System.out.println("Part-time employee " + employee.getName() + "'s salary is " + salary);
}
}

对象结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
import java.util.ArrayList;
import java.util.List;

// 对象结构,维护了一个元素的集合,并提供了遍历这些元素的方法
public class EmployeeManagementSystem {
private List<Element> employees = new ArrayList<>();

// 添加员工
public void attach(Element employee) {
employees.add(employee);
}

// 移除员工
public void detach(Element employee) {
employees.remove(employee);
}

// 接受访问者的访问
public void accept(Visitor visitor) {
for (Element employee : employees) {
employee.accept(visitor);
}
}

客户端代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class VisitorPatternDemo {
public static void main(String[] args) {
EmployeeManagementSystem system = new EmployeeManagementSystem();

FullTimeEmployee fullTimeEmployee = new FullTimeEmployee("Alice", 5000);
PartTimeEmployee partTimeEmployee = new PartTimeEmployee("Bob", 20);

system.attach(fullTimeEmployee); // 添加全职员工
system.attach(partTimeEmployee); // 添加兼职员工

SalaryCalculator calculator = new SalaryCalculator(); // 创建薪资计算器
system.accept(calculator); // 计算员工薪资
}
}

优点

  1. 灵活性:访问者模式将数据结构与数据操作解耦,使得数据结构和操作可以独立变化,灵活性较高。
  2. 扩展性:可以很方便地添加新的访问操作,而不需要修改现有的数据结构。
  3. 符合开闭原则:符合开闭原则,对于已有的数据结构和访问操作都可以进行扩展,而不需要修改已有的代码。

缺点

  1. 增加新的元素类较困难:如果需要增加新的元素类,需要修改所有的访问者类,不符合开闭原则。

使用场景

  1. 数据结构相对稳定,但经常需要在此基础上定义新的操作:当数据结构相对稳定,但经常需要在此基础上定义新的操作时,可以考虑使用访问者模式。
  2. 数据结构中的操作需要依赖于数据结构的具体类:当数据结构中的操作需要依赖于数据结构的具体类时,可以考虑使用访问者模式。

访问者模式通过将数据结构和数据操作分离开来,使得数据结构的增加或修改不会影响到数据操作的变化,同时可以很方便地添加新的访问操作。它适用于数据结构相对稳定,但经常需要在此基础上定义新的操作的场景。