设计模式——一文即可
对常用设计模式的总结，也是对设计模式专栏的总结
简单工厂模式
简单工厂模式（Simple Factory Pattern）是一种创建型设计模式，它提供了一种创建对象的最佳方式，通过将对象的创建逻辑封装在一个工厂类中，客户端不需要知道具体的创建细节，只需要向工厂类请求所需对象即可。
简单工厂模式组成
在简单工厂模式中，主要涉及三个角色：抽象产品、具体产品和简单工厂。
抽象产品（Abstract Product）
抽象产品是具体产品类的共同接口，它定义了产品的通用方法。抽象产品可以是一个接口或抽象类，具体的实现由具体产品类来完成。
具体产品（Concrete Product）
具体产品是抽象产品的实现类，它实现了抽象产品中定义的方法。在简单工厂模式中，每个具体产品都对应一个具体的产品类。
简单工厂（Simple Factory）
简单工厂是一个包含创建产品对象的静态方法的类。它根据客户端的请求创建相应的具体产品对象，并返回给客户端使用。简单工厂隐藏了对象的创建细节，客户端只需通过工厂类获取所需对象，而无需直接实例化具体产品类。
三者关系
1、抽象产品通过定义产品的通用接口，规范了具体产品的行为。 2、具体产品是抽象产品的实现类，负责实现抽象产品中定义的方法。 3、简单工厂作为一个工厂类，封装了对象的创建过程。它根据客户端的请求创建相应的具体产品对象，并返回给客户端使用。
核心思想
将对象的创建过程封装在一个工厂类中，客户端只需通过工厂类的静态方法来获取所需对象，而无需直接实例化具体产品类。这样可以降低客户端与具体产品类之间的耦合度，并且方便了产品类型的扩展和维护。
Java代码实现
首先，我们定义一个抽象产品接口 Product，其中包含一个抽象方法 use()：
public interface Product {
void use();
}然后，我们创建两个具体产品类 ProductA 和 ProductB，它们实现了抽象产品接口 Product：
public class ProductA implements Product {
@Override
public void use() {
System.out.println("Product A is being used.");
}
}
public class ProductB implements Product {
@Override
public void use() {
System.out.println("Product B is being used.");
}
}
接下来，我们创建一个简单工厂类 SimpleFactory，它包含一个静态方法 createProduct(String type)，根据传入的参数类型创建相应的产品对象：
public class SimpleFactory {
public static Product createProduct(String type) {
if (type.equals("A")) {
return new ProductA();
} else if (type.equals("B")) {
return new ProductB();
}
return null;
}
}最后，我们可以在客户端代码中使用简单工厂模式来创建具体产品对象：
//客户端
public class Client {
public static void main(String[] args) {
Product productA = SimpleFactory.createProduct("A");
productA.use(); // Output: Product A is being used.
Product productB = SimpleFactory.createProduct("B");
productB.use(); // Output: Product B is being used.
}
}
代码分析
客户端通过调用 SimpleFactory.createProduct() 方法来创建具体产品对象，而无需直接实例化具体产品类。这样，客户端与具体产品之间的耦合度降低了，同时也方便了产品类型的扩展和维护。
简单工厂类 SimpleFactory 包含一个静态方法 createProduct(String type)，该方法根据传入的参数类型创建相应的产品对象。在实际应用中，根据具体需求可以使用更复杂的逻辑来创建对象，例如读取配置文件或数据库来确定创建哪个具体产品。
在客户端代码中，我们通过调用 SimpleFactory.createProduct() 方法来创建具体产品对象。客户端只需知道产品的类型，而无需关心具体的创建细节。这样可以降低客户端与具体产品类之间的耦合度，并且方便了产品类型的扩展和维护。
优缺点分析
优点
封装了对象的创建过程
简单工厂模式将对象的创建过程封装在一个工厂类中，客户端只需知道产品的类型，而无需关心具体的创建细节。这样可以降低客户端的复杂性，并且方便了产品类型的扩展和维护。
降低了客户端与具体产品类之间的耦合度
客户端只需通过工厂类获取所需对象，而无需直接实例化具体产品类。这样可以降低客户端与具体产品类之间的依赖关系，使客户端代码更加灵活和可维护。
方便了产品类型的扩展和维护
在简单工厂模式中，如果需要新增产品类型，只需修改工厂类的代码即可。这样可以方便地添加新的产品类型，而无需修改客户端代码。同时，也方便了产品类型的维护，集中管理了对象的创建过程。
缺点
违反了开闭原则
在简单工厂模式中，当新增产品类型时，需要修改工厂类的代码。这违反了开闭原则，对于已经存在的代码进行修改可能会引入新的风险。因此，如果产品类型经常变化，不适合使用简单工厂模式。
工厂类职责过重
在简单工厂模式中，工厂类负责创建所有的产品对象。随着产品类型的增多，工厂类的代码会变得越来越复杂，职责过重。这违反了单一职责原则，不利于代码的维护和扩展。
总结
简单工厂模式是一种简单且常用的创建型设计模式，适用于创建对象较少且相对简单的场景。它封装了对象的创建过程，降低了客户端的复杂性，并且方便了产品类型的扩展和维护。然而，简单工厂模式违反了开闭原则，对于产品类型经常变化的情况不适用。此外，工厂类的职责过重也是其缺点之一。因此，在实际应用中，需要根据具体情况选择合适的创建型模式。
策略模式
策略模式（Strategy Pattern）是一种行为型设计模式，它定义了一系列的算法，将每个算法封装起来，使它们可以互相替换。策略模式让算法的变化独立于使用算法的客户端。
主要角色
当我们使用策略模式时，通常会涉及三个主要角色：环境（Context）、抽象策略（Strategy）和具体策略（Concrete Strategy）。
环境（Context）
环境类是策略模式的核心，它持有一个策略对象的引用，并在运行时根据具体需求调用策略对象的算法。环境类提供了一个接口或方法，用于设置和获取策略对象。在客户端使用策略模式时，通常需要与环境类进行交互。
抽象策略（Strategy）
抽象策略类是策略模式的接口或抽象类，定义了具体策略类所必须实现的算法。抽象策略类通常包含一个或多个抽象方法，用于描述策略的行为。客户端通过调用抽象策略类中的方法来使用具体策略。
具体策略（Concrete Strategy）
具体策略类是策略模式的实现类，实现了抽象策略类中定义的算法。具体策略类根据具体的业务需求，实现了不同的算法逻辑。在客户端使用策略模式时，可以根据需要选择合适的具体策略类。
角色总结
环境类持有一个策略对象的引用，并在运行时根据具体需求调用策略对象的算法。抽象策略类定义了具体策略类所必须实现的算法，而具体策略类实现了具体的算法逻辑。通过使用策略模式，可以将算法的定义和使用分离，提高代码的灵活性、可维护性和可扩展性。
核心思想
策略模式的核心思想是将算法的定义和使用分离。在策略模式中，我们将不同的算法封装成不同的策略类，并通过环境类持有一个策略对象的引用。在运行时，根据具体需求选择合适的策略对象，并调用其算法。
封装算法
策略模式将不同的算法封装成不同的策略类。每个策略类都实现了一种具体的算法逻辑。通过封装算法，我们可以将其与其他代码分离，使得算法的定义更加清晰、可读、可维护。
定义抽象策略
策略模式定义了一个抽象策略类，其中包含了策略类所必须实现的方法。抽象策略类可以是一个接口或者抽象类。通过定义抽象策略，我们可以统一不同策略类的接口，使得客户端可以以统一的方式使用不同的策略。
使用环境类
策略模式通过环境类持有一个策略对象的引用。在运行时，客户端可以根据具体需求选择合适的策略对象，并将其设置到环境类中。环境类在运行时根据具体需求调用策略对象的算法，实现了算法的动态切换。
思想总结
通过将算法的定义和使用分离，策略模式提高了代码的灵活性、可维护性和可扩展性。它使得算法的修改和增加变得更加简单，不需要修改原有的代码。同时，策略模式也符合开闭原则，可以方便地增加新的策略类。
Java代码实现——以一个游戏角色攻击方式的例子
首先，我们定义一个抽象策略类 AttackStrategy，它声明了一个 attack() 方法：
public interface AttackStrategy {
void attack();
}然后，我们定义两种具体的攻击策略类：MeleeAttackStrategy 和 RangedAttackStrategy，它们分别实现了 AttackStrategy 接口：
public class MeleeAttackStrategy implements AttackStrategy {
@Override
public void attack() {
System.out.println("近战攻击");
}
}
public class RangedAttackStrategy implements AttackStrategy {
@Override
public void attack() {
System.out.println("远程攻击");
}
}接下来，我们定义一个环境类 Character，它持有一个 AttackStrategy 对象，并提供一个 setAttackStrategy() 方法用于动态设置攻击策略：
public class Character {
private AttackStrategy attackStrategy;
public void setAttackStrategy(AttackStrategy attackStrategy) {
this.attackStrategy = attackStrategy;
}
public void attack() {
attackStrategy.attack();
}
}最后，我们可以在客户端中使用策略模式：
public class Client {
public static void main(String[] args) {
Character character = new Character();
character.setAttackStrategy(new MeleeAttackStrategy());
character.attack(); // 输出：近战攻击
character.setAttackStrategy(new RangedAttackStrategy());
character.attack(); // 输出：远程攻击
}
}
代码分析
在上述代码中，我们通过设置不同的攻击策略，使得角色可以使用不同的攻击方式。这样，当需要增加新的攻击方式时，只需要实现新的具体策略类，并在客户端中设置新的攻击策略即可，而不需要修改原有的代码。
优缺点分析
优点
算法的封装性
策略模式将不同的算法封装成不同的策略类，使得每个策略类都只关注自己的算法逻辑，提高了代码的可读性和可维护性。
策略的替换性
由于策略模式将算法的定义和使用分离，所以在运行时可以根据具体需求选择不同的策略对象，实现算法的动态切换。这样可以方便地替换和扩展算法，而不需要修改原有的代码。
算法的扩展性
策略模式符合开闭原则，可以方便地增加新的策略类。当需要增加新的算法时，只需要添加一个新的策略类，并在环境类中设置该策略对象即可，不需要修改原有的代码。
算法的复用性
策略模式将算法封装成独立的策略类，可以在不同的场景中复用相同的算法。这样可以避免代码的重复编写，提高了代码的复用性。
缺点
增加了类的数量
使用策略模式会增加类的数量，每个具体策略类都需要单独定义一个类。如果策略较多，可能会导致类的数量过多，增加代码的复杂性。
客户端需要了解不同的策略类
客户端在使用策略模式时，需要了解不同的策略类，并选择合适的策略对象。如果策略较多，可能会增加客户端的复杂性。
策略的选择逻辑
在使用策略模式时，需要根据具体需求选择合适的策略对象。这个选择逻辑可能会比较复杂，需要考虑多个因素，增加了代码的复杂性。
优缺点总结
总的来说，策略模式通过将算法的定义和使用分离，提高了代码的灵活性、可维护性和可扩展性。它将不同的算法封装成不同的策略类，实现了算法的动态切换和复用。然而，策略模式也会增加类的数量，增加客户端的复杂性，并且需要考虑策略的选择逻辑。在使用策略模式时，需要权衡其优点和缺点，选择合适的使用方式。
单一职责原则
单一职责原则（Single Responsibility Principle，SRP）是设计模式中的一项原则，它指出一个类或模块应该有且只有一个引起它变化的原因。换句话说，一个类或模块应该只负责一项职责。
核心思想
职责的划分
将系统中的功能和行为划分为不同的职责，每个类或模块只负责一种相关的职责。这样可以使得类的职责更加明确和清晰，便于理解和维护。
单一变化原则
一个类或模块应该只有一个引起它变化的原因。如果一个类负责多种不相关的职责，那么对其中一个职责的修改可能会影响到其他职责，增加了代码的风险和复杂性。
高内聚性
类的内聚性指的是类内部的成员之间联系的紧密程度。遵守单一职责原则可以提高类的内聚性，使得类内部的成员相互关联度高，功能相关的代码放在同一个类中，便于理解和维护。
低耦合性
类之间的耦合性指的是彼此之间的依赖程度。遵守单一职责原则可以降低类之间的耦合性，使得类之间的依赖关系更加清晰和简单，减少代码的依赖和影响范围。
核心总结
单一职责原则的核心思想是将一个类或模块的职责限定在一个很小的范围内，使其只负责一种相关的功能或行为。这样可以保持类的高内聚性、低耦合性，提高代码的可读性、可维护性和可扩展性。
举例
假设我们有一个图书管理系统，其中包含了图书的借阅和归还功能。我们可以将这个系统划分为以下几个类：
图书类（Book）
负责表示图书的属性和行为，比如书名、作者、借阅状态等。
用户类（User）
负责表示用户的属性和行为，比如用户名、密码、借阅图书等。
图书管理类（Library）
负责管理图书的借阅和归还功能。
分析
在这个例子中，每个类都只负责一种相关的职责，符合了单一职责原则。图书类只负责表示图书的属性和行为，用户类只负责表示用户的属性和行为，图书管理类只负责管理图书的借阅和归还功能。
不遵守单一职责原则，可能引发的问题
类的职责不清晰
一个类负责了多种不相关的职责，使得代码难以理解和维护。
类的修改影响范围过大
当一个类负责多种职责时，对其中一个职责的修改可能会影响到其他职责，增加了代码的风险和复杂性。
难以重用和扩展
一个类负责多种职责时，可能会导致代码的耦合性增加，使得难以重用和扩展。
Java代码实现
// 图书类
class Book {
private String title;
private String author;
private int pageCount;
// 构造函数、getter和setter方法省略
// 图书的展示功能
public void display() {
System.out.println("Title: " + this.title);
System.out.println("Author: " + this.author);
System.out.println("Page Count: " + this.pageCount);
}
}
// 图书管理类
class Library {
private List<Book> books;
// 构造函数、getter和setter方法省略
// 图书的借阅功能
public void borrowBook(Book book) {
if (books.contains(book)) {
books.remove(book);
System.out.println("Borrowed book: " + book.getTitle());
} else {
System.out.println("Book not available for borrowing.");
}
}
// 图书的归还功能
public void returnBook(Book book) {
books.add(book);
System.out.println("Returned book: " + book.getTitle());
}
}
程序分析
我们定义了两个类：Book和Library。Book类负责表示图书的属性和行为，包括展示图书的功能；Library类负责管理图书的借阅和归还功能。
通过将图书的展示功能和图书的借阅、归还功能分别放在不同的类中，我们遵守了单一职责原则。每个类只负责一种相关的职责，使得代码更加清晰和易于维护。
当我们需要使用这些功能时，可以直接调用相应的方法
Book book = new Book("Design Patterns", "Gang of Four", 400);
book.display();
Library library = new Library();
library.borrowBook(book);
library.returnBook(book);这样，我们可以很方便地使用图书的展示、借阅和归还功能，而不会影响到其他相关的功能。
总结
总结来说，单一职责原则是设计模式中的一项重要原则，它要求将功能划分得更加细致，使得每个类或模块 只负责一种相关的职责。遵守单一职责原则可以提高代码的可读性、可维护性和可扩展性。
开放封闭原则
开放封闭原则是面向对象设计中的一个重要原则，它指导我们编写可扩展、可维护和可复用的代码。
核心思想
软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。也就是说，当需要增加新的功能时，应该通过扩展已有的代码来实现，而不是修改已有的代码。
关键词概括
扩展
当需求发生变化时，我们希望能够方便地增加新的功能或特性，而不需要对已有的代码进行修改。这样可以减少引入新错误的风险。
封闭
已有的代码应该是稳定的，不应该受到需求变化的影响。即使需求发生变化，我们也不应该修改已有的代码。这样可以保护已有的代码，防止引入新的错误。
解释
抽象和接口
通过定义抽象类或接口，我们可以将可变的部分抽象出来，定义一组公共的方法和属性。这样，在需要扩展时，我们只需要实现新的子类或实现新的接口即可，而不需要修改已有的代码。
多态
通过使用多态，我们可以在运行时动态地选择不同的实现。这样，我们可以通过扩展已有的类或接口来实现新的功能，而不需要修改已有的代码。
代码示例
// 定义一个接口
public interface Shape {
void draw();
}
// 定义一个实现类
public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing a circle");
}
}
// 定义一个扩展类
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Drawing a rectangle");
}
}
// 定义一个客户端类
public class Client {
public void drawShapes(List<Shape> shapes) {
for (Shape shape : shapes) {
shape.draw();
}
}
}
// 测试代码
public class Main {
public static void main(String[] args) {
Client client = new Client();
List<Shape> shapes = new ArrayList<>();
shapes.add(new Circle());
shapes.add(new Rectangle());
client.drawShapes(shapes);
}
}
代码解释
在上面的代码中，我们定义了一个 Shape 接口，它有一个 draw() 方法。然后我们定义了一个实现类 Circle 和一个扩展类 Rectangle，它们都实现了 Shape 接口。
在客户端类 Client 中，我们定义了一个 drawShapes() 方法，它接受一个 List 参数，并循环调用每个 Shape 对象的 draw() 方法。这样，我们可以通过扩展 Shape 接口并实现新的子类来增加新的图形类型，而不需要修改已有的代码。
在测试代码中，我们创建了一个 Client 对象，并传入一个包含 Circle 和 Rectangle 对象的 List。然后调用 drawShapes() 方法，它会依次调用每个图形对象的 draw() 方法，输出相应的图形。
这个示例代码演示了如何使用开放封闭原则来实现代码的扩展。通过定义一个公共的接口并实现多个子类，我们可以在不修改已有的代码的情况下，扩展代码的功能。
优缺点
优点
可扩展性
开放封闭原则可以使系统具有良好的扩展性。通过定义抽象类或接口，并实现新的子类或接口，我们可以在不修改已有的代码的情况下，增加新的功能。
可维护性
开放封闭原则可以提高代码的可维护性。通过将可变的部分与稳定的部分分离开来，我们可以更容易地理解和修改代码。当需求发生变化时，我们只需要扩展已有的类或接口，而不需要修改已有的代码。
可复用性
开放封闭原则可以增加代码的可复用性。通过定义抽象类或接口，并实现新的子类或接口，我们可以将相同的代码逻辑应用于不同的场景中。
高内聚低耦合
开放封闭原则可以提高代码的内聚性和减少代码的耦合性。通过将可变的部分封装在独立的类中，并通过接口进行交互，我们可以将代码分解为独立的模块，从而提高代码的内聚性和减少代码的耦合性。
缺点
抽象设计的复杂性
开放封闭原则可能会增加代码的复杂性。通过引入抽象类或接口，我们需要定义更多的类和接口，这会增加代码的复杂性。
需要预留扩展点
开放封闭原则需要在设计时预留扩展点，这可能会增加设计的难度。如果没有正确地预留扩展点，可能需要修改已有的代码。
可能引入过度设计
开放封闭原则可能会导致过度设计。为了实现扩展性，我们可能会引入过多的抽象类和接口，这可能会增加代码的复杂性和理解难度。
总结
开放封闭原则是面向对象设计中的一个重要原则，它的核心思想是对扩展开放，对修改封闭。通过定义抽象类或接口，并实现新的子类或接口，可以在不修改已有的代码的情况下，增加新的功能。这样可以提高系统的扩展性、可维护性和可复用性，同时减少代码的耦合性和提高代码的内聚性。然而，开放封闭原则也可能增加代码的复杂性和设计难度，需要在实际应用中权衡利弊。总的来说，开放封闭原则是一种有助于构建可扩展、可维护和可复用的系统的重要原则。
依赖倒转原则
依赖倒转原则（Dependency Inversion Principle，DIP）是面向对象设计中的一个重要原则，它指导着如何构建松耦合、可扩展和可维护的软件系统。该原则由罗伯特·C·马丁（Robert C. Martin）提出。
核心思想
通过抽象来解耦高层模块和低层模块之间的依赖关系。
关键点分析
a
高层模块不应该依赖于低层模块的具体实现，而是依赖于抽象接口。这意味着高层模块应该定义一个抽象接口，而低层模块实现该接口。通过依赖于抽象接口，高层模块可以独立于具体实现进行编程。
b
抽象接口应该由高层模块定义，而不是由低层模块定义。这样可以确保高层模块对于依赖的控制，而不会受到低层模块的限制。高层模块可以根据自己的需求定义接口的方法和属性，而不需要依赖于低层模块的具体实现细节。
c
依赖注入是实现依赖倒转原则的重要手段。通过依赖注入，高层模块可以将具体实现类的对象传递给抽象接口。依赖注入可以通过构造函数、方法参数或者属性注入的方式实现。这样可以实现解耦，高层模块不需要关心具体实现类的创建和管理。
优缺点分析
优点
降低模块间的耦合度
通过依赖倒转原则，高层模块不依赖于低层模块的具体实现，而是依赖于抽象接口。这样可以使得模块之间的耦合度降低，提高代码的灵活性和可维护性。
提高代码的可扩展性
由于高层模块不依赖于低层模块的具体实现，当需要新增或修改低层模块时，只需要修改具体实现类而不需要修改高层模块的代码。这样可以提高代码的可扩展性，减少对现有代码的影响。
便于进行单元测试
由于高层模块依赖于抽象接口，可以通过使用模拟对象来进行单元测试，而不需要依赖于具体实现类。这样可以更容易地进行测试，提高代码的质量。
缺点
增加代码的复杂性
依赖倒转原则需要引入抽象接口和依赖注入等机制，这会增加代码的复杂性和理解难度。特别是在项目规模较小或简单场景下，引入这些机制可能会显得过于繁琐。
需要额外的设计和开发工作
在应用依赖倒转原则时，需要进行额外的设计和开发工作，包括定义抽象接口、实现具体实现类、进行依赖注入等。这会增加开发成本和工作量。
综上所述，依赖倒转原则在一定程度上可以提高代码的灵活性、可维护性和可扩展性，但也需要权衡其引入的复杂性和开发成本。在设计和开发过程中，需要根据具体的场景和需求来决定是否采用依赖倒转原则。
Java代码实现
// 定义抽象接口
public interface MessageSender {
void sendMessage(String message);
}
// 具体实现类1
public class EmailSender implements MessageSender {
@Override
public void sendMessage(String message) {
System.out.println("Sending email: " + message);
}
}
// 具体实现类2
public class SmsSender implements MessageSender {
@Override
public void sendMessage(String message) {
System.out.println("Sending SMS: " + message);
}
}
// 高层模块，依赖于抽象接口
public class NotificationService {
private MessageSender messageSender;
// 通过构造函数进行依赖注入
public NotificationService(MessageSender messageSender) {
this.messageSender = messageSender;
}
public void sendNotification(String message) {
// 调用抽象接口的方法
messageSender.sendMessage(message);
}
}
// 测试代码
public class Main {
public static void main(String[] args) {
// 创建具体实现类的对象
MessageSender emailSender = new EmailSender();
MessageSender smsSender = new SmsSender();
// 创建高层模块的对象，并传入具体实现类的对象
NotificationService emailNotificationService = new NotificationService(emailSender);
NotificationService smsNotificationService = new NotificationService(smsSender);
// 调用高层模块的方法
emailNotificationService.sendNotification("Hello, this is an email notification.");
smsNotificationService.sendNotification("Hello, this is an SMS notification.");
}
}
示例分析
在抽象接口MessageSender定义了发送消息的方法。具体实现类EmailSender和SmsSender分别实现了该接口，并提供了发送邮件和发送短信的具体实现。高层模块NotificationService依赖于抽象接口MessageSender，通过构造函数进行依赖注入，从而实现了依赖倒转原则。
总结
依赖倒置原则强调了面向抽象编程的重要性，通过抽象接口和依赖注入等技术，可以降低模块之间的耦合度，提高代码的灵活性和可维护性。
装饰模式
装饰模式（Decorator Pattern）是一种结构型设计模式，它允许你动态地向一个对象添加额外的功能，而不需要修改其原始类。通过将对象包装在装饰器类中，你可以在不改变现有对象结构的情况下，逐步地添加功能。
装饰模式角色
Component（抽象组件）
定义了具体组件和装饰器的共同接口，可以是抽象类或接口。
ConcreteComponent（具体组件）
实现了抽象组件定义的接口，是被装饰的原始对象。
Decorator（抽象装饰器）
包含一个指向具体组件的引用，并实现了抽象组件定义的接口。
ConcreteDecorator（具体装饰器）
通过装饰器对具体组件进行扩展或修改，添加额外的功能。
工作流程
首先
定义一个抽象组件（Component），它声明了具体组件和装饰器共同的接口方法。
其次
创建一个具体组件（ConcreteComponent），它实现了抽象组件的接口方法，是被装饰的原始对象。
然后
创建一个抽象装饰器（Decorator），它也实现了抽象组件的接口方法，并包含一个指向具体组件的成员变量（通常为抽象组件类型），用于持有被装饰的对象。
最后
创建具体装饰器（ConcreteDecorator），它继承自抽象装饰器，并在装饰器的基础上添加了额外的功能。具体装饰器中通常会重写抽象组件的接口方法，以在调用前后进行额外的处理，然后再调用被装饰对象的相应方法。
Java代码实现
// Step 1: 定义抽象组件
interface Component {
void operation();
}
// Step 2: 创建具体组件
class ConcreteComponent implements Component {
public void operation() {
System.out.println("执行具体组件的操作");
}
}
// Step 3: 创建抽象装饰器
abstract class Decorator implements Component {
protected Component component;
public Decorator(Component component) {
this.component = component;
}
public void operation() {
component.operation();
}
}
// Step 4: 创建具体装饰器
class ConcreteDecorator extends Decorator {
public ConcreteDecorator(Component component) {
super(component);
}
public void operation() {
// 在调用具体组件操作前进行额外处理
System.out.println("在调用具体组件操作前进行额外处理");
// 调用具体组件的操作
super.operation();
// 在调用具体组件操作后进行额外处理
System.out.println("在调用具体组件操作后进行额外处理");
}
}
// 使用装饰模式
public class Main {
public static void main(String[] args) {
// 创建具体组件对象
Component component = new ConcreteComponent();
// 创建具体装饰器对象，并将具体组件对象传入
Component decorator = new ConcreteDecorator(component);
// 调用装饰后的操作
decorator.operation();
}
}代码分析
Component 是抽象组件接口，ConcreteComponent 是具体组件类，实现了抽象组件接口的方法。Decorator 是抽象装饰器类，实现了抽象组件接口，并持有一个抽象组件类型的成员变量。ConcreteDecorator 是具体装饰器类，继承自抽象装饰器类，并重写了操作方法，在调用前后添加了额外处理。
在主函数中，先创建具体组件对象ConcreteComponent，然后将其传入具体装饰器对象ConcreteDecorator 的构造函数中，用装饰器包装具体组件。最后调用装饰后的操作，会按照一定的顺序执行额外处理和具体组件操作。
优缺点分析
优点
符合开闭原则
可以在不修改现有代码的情况下，通过新增装饰器类来扩展对象的功能。
可以动态地添加/删除功能
可以根据需要动态地添加或删除对象的功能，组合不同的装饰器实现不同的行为组合。
遵循单一职责原则
具体的组件类只负责核心功能，具体的装饰器类只关注附加的功能，各个类职责明确，可维护性高。
装饰器类与具体组件类独立
装饰器类与具体组件类之间是松耦合的关系，可以独立变化，增加或删除装饰器不会影响其他组件的行为。
缺点
可能产生过多的具体装饰器类
如果系统中有很多功能需要扩展，可能会导致产生大量的具体装饰器类，增加系统的复杂性。
装饰器与组件类的接口不一致
在装饰器模式中，装饰器类和具体组件类的接口不一致，导致客户端需要区分调用。
总结
装饰模式提供了一种灵活的、可扩展的方式来修改对象的功能，同时保持了简单的接口和代码的可维护性。但是需要权衡好扩展的复杂度和对象接口的一致性。
代理模式
代理模式是一种结构型设计模式，它允许通过创建一个代理对象来控制对其它对象的访问。代理对象充当了被代理对象的接口，客户端通过代理对象来访问被代理对象，从而实现了对被代理对象的间接访问。
代理模式角色分析
抽象主题（Subject）
定义了代理对象和被代理对象的共同接口，客户端通过抽象主题来访问被代理对象。
真实主题（Real Subject）
实现了抽象主题接口，是被代理对象，代理对象将对其进行间接访问。
代理（Proxy）
实现了抽象主题接口，同时包含一个对真实主题的引用，客户端通过代理对象来访问真实主题。
应用场景
远程代理
代理模式常用于网络通信中，例如远程方法调用（RPC）。在分布式系统中，客户端可以通过代理对象来调用远程服务器上的方法，代理对象负责将调用请求发送到远程服务器并返回结果。远程代理隐藏了底层网络通信的细节，使得客户端可以像调用本地方法一样调用远程方法。
虚拟代理
虚拟代理用于在访问对象时进行一些额外的处理。一个常见的例子是延迟加载（Lazy Loading），当一个对象的创建或加载非常耗费资源时，可以使用虚拟代理来推迟对象的创建或加载，直到真正需要访问对象时才进行。例如，在图像加载时，可以使用虚拟代理来延迟加载图像数据，只有当需要显示图像时才真正加载图像数据。
安全代理
安全代理用于控制对对象的访问权限。例如，在一个权限管理系统中，可以使用安全代理来限制只有特定角色的用户才能访问某个对象。代理对象可以在访问真实对象前检查用户的角色，如果用户具有访问权限，则允许访问真实对象，否则拒绝访问。
智能引用代理
智能引用代理用于在访问对象时添加一些额外的功能。一个常见的例子是缓存功能，代理对象可以在访问真实对象前先检查缓存中是否存在对应的结果，如果存在则直接返回缓存结果，避免重复计算。另外，还可以使用智能引用代理来实现对象池，代理对象可以管理对象的创建和销毁，并在访问对象时从对象池中获取对象。
总结
代理模式在许多实际应用中都有广泛的应用。通过引入代理对象，可以实现对被代理对象的间接访问，并可以在访问前后做一些额外的处理，如网络通信、延迟加载、权限控制和功能扩展等。代理模式可以提高系统的灵活性和可扩展性，同时也需要权衡系统的复杂性和性能。
Java程序实现
首先，我们定义一个接口 Image，表示图像对象的接口：
public interface Image {
void display();
}其次，我们创建一个真实的图像类 RealImage，实现 Image 接口，表示真实的图像对象：
public class RealImage implements Image {
private String filename;
public RealImage(String filename) {
this.filename = filename;
loadFromDisk();
}
private void loadFromDisk() {
System.out.println("Loading image from disk: " + filename);
}
public void display() {
System.out.println("Displaying image: " + filename);
}
}然后，我们创建一个代理类 ProxyImage，实现 Image 接口，表示图像的代理对象：
public class ProxyImage implements Image {
private String filename;
private RealImage realImage;
public ProxyImage(String filename) {
this.filename = filename;
}
public void display() {
if (realImage == null) {
realImage = new RealImage(filename);
}
realImage.display();
}
}最后，我们可以使用代理对象来访问真实的图像对象，例如：
public class Main {
public static void main(String[] args) {
Image image = new ProxyImage("test.jpg");
// 第一次访问，会创建真实的图像对象并显示
image.display();
// 第二次访问，直接显示之前创建的真实图像对象
image.display();
}
}输出结果
Loading image from disk: test.jpg
Displaying image: test.jpg
Displaying image: test.jpg程序分析
在上面的示例中，ProxyImage 类充当了代理对象，它在访问真实的图像对象之前先进行了一些额外的处理。当第一次访问图像时，代理对象会创建真实的图像对象并显示；当第二次访问图像时，代理对象直接显示之前创建的真实图像对象，避免了重复加载和显示。通过代理对象，我们可以实现对真实对象的间接访问，并在访问前后做一些额外的处理。
优缺点分析
优点
代理模式可以实现对真实对象的间接访问，可以在访问前后做一些额外的处理，如权限控制、延迟加载、缓存等。 代理对象可以隐藏真实对象的具体实现细节，保护真实对象的安全性。 代理模式可以提高系统的灵活性和可扩展性，可以在不修改真实对象的情况下增加新的代理对象。 代理模式符合单一职责原则，可以将真实对象和代理对象分离，分别负责各自的功能。
缺点
由于引入了代理对象，会增加系统的复杂性，增加了代码的数量和维护的难度。 代理模式会引入额外的开销，因为需要通过代理对象来访问真实对象，可能会导致性能下降。 如果代理对象的创建和销毁过程比较复杂，可能会影响系统的性能。
总结
代理模式在许多实际应用中都有广泛的应用，可以提供额外的功能和保护真实对象的安全性。但是，在使用代理模式时需要权衡系统的复杂性和性能，确保代理对象的创建和销毁过程不会影响系统的性能。
工厂方法模式
工厂方法模式是一种创建型设计模式，它定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法模式将对象的实例化推迟到子类中进行。
角色分类
抽象产品（Abstract Product）
定义了产品的接口，是具体产品类的共同父类或接口。
具体产品（Concrete Product）
实现了抽象产品接口的具体类。
抽象工厂（Abstract Factory）
定义了创建产品的接口，包含一个或多个创建产品的抽象方法。
具体工厂（Concrete Factory）
实现了抽象工厂接口，负责实例化具体产品。
核心思想
将对象的创建与使用分离，客户端通过调用工厂方法来创建对象，而不是直接实例化具体产品。这样做的好处是，客户端只需要知道抽象产品和抽象工厂的存在，而无需关心具体产品的细节。当需要创建不同类型的产品时，只需要实现对应的具体产品和具体工厂即可，而不需要修改客户端的代码。
Java代码实现：
假设有一个汽车工厂，可以生产不同类型的汽车，包括小轿车和SUV。首先定义一个抽象汽车类（AbstractProduct）：
public abstract class Car {
public abstract void drive();
}然后定义具体的小轿车类（ConcreteProduct1）和SUV类（ConcreteProduct2），它们都继承自抽象汽车类：
public class SedanCar extends Car {
@Override
public void drive() {
System.out.println("Driving sedan car...");
}
}
public class SUV extends Car {
@Override
public void drive() {
System.out.println("Driving SUV...");
}
}接下来定义抽象汽车工厂类（AbstractFactory），其中包含一个创建汽车的抽象方法：
public abstract class CarFactory {
public abstract Car createCar();
}然后定义具体的小轿车工厂类（ConcreteFactory1）和SUV工厂类（ConcreteFactory2），它们都继承自抽象汽车工厂类：
public class SedanCarFactory extends CarFactory {
@Override
public Car createCar() {
return new SedanCar();
}
}
public class SUVFactory extends CarFactory {
@Override
public Car createCar() {
return new SUV();
}
}最后，在客户端代码中使用工厂方法来创建汽车对象：
public class Client {
public static void main(String[] args) {
CarFactory factory1 = new SedanCarFactory();
Car sedanCar = factory1.createCar();
sedanCar.drive();
CarFactory factory2 = new SUVFactory();
Car suv = factory2.createCar();
suv.drive();
}
}输出结果为
Driving sedan car...
Driving SUV...分析
通过工厂方法模式，客户端代码只需要与抽象产品和抽象工厂进行交互，而无需关心具体产品的创建过程。当需要新增其他类型的汽车时，只需要实现对应的具体产品和具体工厂即可，而不需要修改客户端的代码，实现了代码的可扩展性和可维护性。
优缺点分析
优点
符合开闭原则
工厂方法模式通过引入抽象工厂和具体工厂的概念，使得系统的扩展性更好。当需要新增一种产品时，只需要新增对应的具体产品和具体工厂，而不需要修改已有的代码，符合开闭原则。
封装了对象的创建过程
客户端只需要关心抽象产品和抽象工厂，而无需关心具体产品的创建过程。具体产品的创建过程被封装在具体工厂中，使得客户端代码更加简洁、可读性更高。
降低了客户端和具体产品的耦合
客户端只依赖于抽象产品和抽象工厂，而不依赖于具体产品。这样可以使客户端代码与具体产品解耦，提高代码的灵活性和可维护性。
可以通过配置文件等方式动态指定具体工厂类
工厂方法模式可以通过配置文件、反射等方式动态指定具体工厂类，从而实现更加灵活的对象创建方式。
缺点
增加了系统的复杂度
引入抽象工厂和具体工厂的概念，使得系统的结构变得更加复杂。如果系统中只有少量的产品，使用工厂方法模式可能会显得过于复杂，不利于维护和理解。
增加了代码的数量
工厂方法模式需要定义抽象产品、具体产品、抽象工厂、具体工厂等多个类，这增加了代码的数量。对于简单的项目，使用工厂方法模式可能会显得冗余。
客户端需要知道具体工厂类
客户端需要知道具体工厂类的存在，这增加了客户端的依赖。如果具体工厂类的创建逻辑发生变化，客户端代码也需要相应的修改。
原型模式
这是一种创建型设计模式，它允许通过复制现有对象来创建新对象，而无需通过实例化类来创建。它通过克隆现有对象的属性和方法来创建新对象，从而避免了创建对象时的重复工作。
角色分类
抽象原型（Prototype）
定义了克隆方法的接口，通常是一个接口或抽象类。该接口中声明了一个克隆方法，用于复制原型对象。
具体原型（Concrete Prototype）
实现了抽象原型接口，提供了克隆方法的具体实现。具体原型对象通过克隆方法创建新的对象，同时复制原型对象的属性和方法。
客户端（Client）
通过调用克隆方法来创建新的对象。客户端可以通过克隆方法复制原型对象，然后根据需要修改克隆对象的属性。
原型管理器（Prototype Manager）
用于管理原型对象的创建和克隆过程。原型管理器可以维护一个原型对象的注册表，客户端通过原型管理器获取原型对象的克隆。
核心思想
原型对象的克隆方法，通过克隆方法可以复制原型对象的属性和方法，从而创建新的对象。客户端可以根据需要通过克隆方法创建新的对象，并可以自由地修改克隆对象的属性。原型模式可以有效地提高对象的创建效率，并使对象的创建过程更加灵活和可扩展。
Java代码实现
// 原型接口
interface Prototype {
Prototype clone();
}
// 具体原型类
class ConcretePrototype implements Prototype {
private String name;
public ConcretePrototype(String name) {
this.name = name;
}
public Prototype clone() {
return new ConcretePrototype(this.name);
}
public void setName(String name) {
this.name = name;
}
public String getName() {
return this.name;
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
// 创建原型对象
Prototype prototype = new ConcretePrototype("原型对象");
// 克隆原型对象
Prototype clone = prototype.clone();
// 修改克隆对象的属性
((ConcretePrototype) clone).setName("克隆对象");
// 输出原型对象和克隆对象的属性
System.out.println("原型对象的属性：" + prototype.getName());
System.out.println("克隆对象的属性：" + ((ConcretePrototype) clone).getName());
}
}代码分析
在上面的示例中，我们定义了一个原型接口 Prototype，其中包含一个 clone 方法用于克隆原型对象。然后，我们创建了一个具体原型类 ConcretePrototype，实现了 Prototype 接口，并在 clone 方法中返回一个新的克隆对象。
在客户端代码中，我们创建了一个原型对象 prototype，然后使用 clone 方法克隆了一个新的对象 clone。接下来，我们修改了克隆对象的属性，并输出了原型对象和克隆对象的属性。
优缺点分析
优点
简化对象的创建
原型模式通过克隆原型对象来创建新的对象，避免了重复创建对象的过程，提高了对象的创建效率。
隐藏对象的创建细节
客户端通过克隆方法获取新的对象，无需关心对象的创建细节，使得对象的创建过程对客户端透明。
支持动态添加和修改对象的属性
克隆对象可以独立于原型对象进行修改，不会影响到原型对象，使得对象的创建更加灵活和可扩展。
提供了一种可替代的对象创建方式
原型模式可以作为一种可替代的对象创建方式，特别适用于创建复杂对象或需要大量初始化的对象。
缺点
克隆方法的实现可能较为复杂
如果对象的属性较为复杂或存在循环引用等问题，实现克隆方法可能较为复杂。
克隆对象与原型对象的关系可能较为复杂
克隆对象与原型对象之间可能存在一定的关联关系，需要在克隆方法中进行处理，增加了代码的复杂性。
克隆对象的创建方式受限
克隆对象的创建方式受限于原型对象的结构，需要保证原型对象实现了克隆方法，且克隆方法能够正确地复制对象的属性。
模板方法模式
这是一种行为型设计模式，用于定义算法的框架，将算法的具体实现延迟到子类中。
角色分类
抽象类（Abstract Class）
抽象类定义了一个模板方法，该方法包含了算法的框架，以及一系列基本方法的调用顺序。抽象类还可以定义抽象方法、具体方法和钩子方法，用于延迟具体实现或提供默认实现。
具体子类（Concrete Class）
具体子类继承抽象类，并实现抽象方法和钩子方法。具体子类负责实现算法的具体步骤。
抽象方法（Abstract Method）
抽象方法是在抽象类中声明的方法，由具体子类实现。抽象方法是模板方法中的基本方法，用于完成算法的一部分。
具体方法（Concrete Method）
具体方法是在抽象类中已经实现的方法，可以在模板方法中直接调用。具体方法是模板方法中的基本方法，用于完成算法的一部分。
钩子方法（Hook Method）
钩子方法是在抽象类中有默认实现的方法，子类可以选择是否覆盖。钩子方法可以用于在算法的不同阶段提供不同的行为。
核心思想
将算法的框架固定在抽象类中，而将具体实现延迟到具体子类中。抽象类定义了一个模板方法，该方法包含了算法的框架，以及一系列基本方法的调用顺序。抽象类还可以定义抽象方法、具体方法和钩子方法，用于延迟具体实现或提供默认实现。
Java代码实现
// 抽象模板类
abstract class AbstractClass {
// 模板方法，定义了算法的骨架
public final void templateMethod() {
step1();
step2();
step3();
}
// 基本方法1
protected abstract void step1();
// 基本方法2
protected abstract void step2();
// 基本方法3
protected abstract void step3();
}
// 具体模板类A
class ConcreteClassA extends AbstractClass {
@Override
protected void step1() {
System.out.println("ConcreteClassA: Step 1");
}
@Override
protected void step2() {
System.out.println("ConcreteClassA: Step 2");
}
@Override
protected void step3() {
System.out.println("ConcreteClassA: Step 3");
}
}
// 具体模板类B
class ConcreteClassB extends AbstractClass {
@Override
protected void step1() {
System.out.println("ConcreteClassB: Step 1");
}
@Override
protected void step2() {
System.out.println("ConcreteClassB: Step 2");
}
@Override
protected void step3() {
System.out.println("ConcreteClassB: Step 3");
}
}
// 测试代码
public class Main {
public static void main(String[] args) {
AbstractClass classA = new ConcreteClassA();
classA.templateMethod();
System.out.println();
AbstractClass classB = new ConcreteClassB();
classB.templateMethod();
}
}输出
ConcreteClassA: Step 1
ConcreteClassA: Step 2
ConcreteClassA: Step 3
ConcreteClassB: Step 1
ConcreteClassB: Step 2
ConcreteClassB: Step 3分析
在上面的示例中，抽象模板类AbstractClass定义了一个模板方法templateMethod()，这个方法定义了一个算法的骨架，其中包含了多个基本方法step1()、step2()、step3()。具体模板类ConcreteClassA和ConcreteClassB继承自AbstractClass，并实现了基本方法。
总结
模板方法模式是一种简单但非常实用的设计模式，它通过将算法的框架固定在抽象类中，将具体实现延迟到具体子类中，提供了一种灵活而可扩展的算法设计方案。
迪米特法则
迪米特法则（Law of Demeter）也被称为最少知识原则（Least Knowledge Principle），是一种面向对象设计的原则，它强调一个对象应该尽量减少与其他对象之间的相互依赖。
核心思想
尽量减少对象之间的相互依赖，使对象之间的耦合度降低。具体来说，它强调一个对象应该只与其直接的朋友进行交互，而不与陌生的对象进行直接交互。
这里的“朋友”指
当前对象本身
一个对象可以调用自身的方法，因为它对自身的结构和行为是了解的。
以参数形式传入当前对象的对象
一个对象可以调用作为参数传入的对象的方法，因为它对传入的对象的结构和行为是了解的。
当前对象的成员变量直接引用的对象
一个对象可以调用它的成员变量直接引用的对象的方法，因为它对成员变量引用的对象的结构和行为是了解的。
目标
降低对象之间的耦合度，提高系统的可维护性、可扩展性和可复用性。通过限制对象之间的直接交互，减少了对象之间的依赖关系，使系统更加灵活、易于修改和测试。
遵循迪米特法则可以使系统的设计更加模块化，每个对象只需要关注自身的职责，而不需要了解其他对象的内部细节。这样可以降低系统的复杂性，提高代码的可读性和可维护性。同时，迪米特法则也有助于提高系统的可扩展性，因为减少了对象之间的直接依赖，新增功能时只需要修改少量的对象即可。
Java程序实现
// 定义一个学生类
class Student {
private String name;
public Student(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
// 定义一个班级类
class Class {
private String className;
private List<Student> students;
public Class(String className, List<Student> students) {
this.className = className;
this.students = students;
}
public String getClassName() {
return className;
}
public List<Student> getStudents() {
return students;
}
}
// 定义一个学校类
class School {
private String schoolName;
private List<Class> classes;
public School(String schoolName, List<Class> classes) {
this.schoolName = schoolName;
this.classes = classes;
}
public String getSchoolName() {
return schoolName;
}
public List<Class> getClasses() {
return classes;
}
}
// 客户端代码
public class Main {
public static void main(String[] args) {
// 创建学生对象
Student student1 = new Student("Tom");
Student student2 = new Student("Jerry");
// 创建班级对象
List<Student> students = new ArrayList<>();
students.add(student1);
students.add(student2);
Class class1 = new Class("Class1", students);
// 创建学校对象
List<Class> classes = new ArrayList<>();
classes.add(class1);
School school = new School("School1", classes);
// 输出学校的名称和班级的名称
System.out.println("School Name: " + school.getSchoolName());
for (Class c : school.getClasses()) {
System.out.println("Class Name: " + c.getClassName());
}
// 输出班级中的学生姓名
for (Class c : school.getClasses()) {
for (Student s : c.getStudents()) {
System.out.println("Student Name: " + s.getName());
}
}
}
}程序分析
学生类、班级类和学校类之间的关系是符合迪米特法则的。学生类只与班级类有直接的关联，班级类只与学校类有直接的关联，而学生类和学校类之间没有直接的关联。这样可以降低对象之间的耦合度，提高系统的灵活性和可维护性。
在客户端代码中，我们创建了一个学校对象，然后通过学校对象获取班级对象和学生对象，并输出它们的信息。通过迪米特法则，我们可以看到客户端代码只需要与学校类进行交互，而不需要了解班级类和学生类的内部细节，这样可以降低客户端代码与其他类的直接依赖，使系统更加灵活和易于维护。
总结
迪米特法则强调了对象之间的松耦合设计，通过减少对象之间的直接依赖，提高系统的灵活性和可维护性。遵循迪米特法则可以使系统更加模块化、可扩展和易于测试。
外观模式
外观模式（Facade Pattern）是一种结构型设计模式，它提供了一个统一的接口，用于访问子系统中的一组接口。外观模式定义了一个高层接口，使得子系统更容易使用。
主要目的
简化复杂系统的接口。它通过提供一个统一的接口，隐藏了子系统的复杂性，使得客户端可以更方便地使用系统。外观模式通过将客户端与子系统解耦，提供了一个简化的接口，从而降低了系统的复杂性。
角色分析
外观（Facade）角色
外观角色是外观模式的核心。它知道哪些子系统类负责处理请求，并将客户端的请求委派给适当的子系统对象。外观角色通常是单例模式，可以提供一个简单的接口，隐藏了子系统的复杂性。
子系统（Subsystem）角色
子系统角色是外观模式中的各个子系统类。它们是实际处理请求的类，完成具体的功能。外观角色将客户端的请求委派给适当的子系统对象，由子系统对象完成具体的操作。
客户端（Client）角色
客户端角色是使用外观模式的类。它通过调用外观角色的接口来完成操作，而不需要直接与子系统类交互。客户端角色只需要知道外观角色提供的简单接口，无需了解子系统的复杂性。
工作原理
客户端通过调用外观角色的接口来进行操作，外观角色将请求委派给适当的子系统对象，子系统对象完成具体的操作并返回结果给客户端。客户端无需了解子系统的复杂性，只需要通过外观角色来访问子系统。这样可以降低系统的复杂性，提高系统的可维护性和可扩展性。
核心思想总结
简化接口
外观角色提供了一个简化的接口，将子系统的一组接口封装起来，使得客户端可以更方便地使用系统。客户端只需要调用外观角色的接口，无需了解子系统的复杂性。
解耦客户端和子系统
外观模式将客户端与子系统解耦，客户端只需要与外观角色交互，而不需要直接与子系统类交互。这样可以降低客户端的复杂性，同时也提高了系统的可维护性和可扩展性。
隐藏实现细节
外观模式将子系统的实现细节隐藏起来，只暴露给客户端一个简单的接口。这样可以保护子系统的实现细节，防止客户端直接访问和修改子系统的内部实现。
Java程序实现
// 子系统类A
class SubsystemA {
public void operationA() {
System.out.println("SubsystemA operation");
}
}
// 子系统类B
class SubsystemB {
public void operationB() {
System.out.println("SubsystemB operation");
}
}
// 外观类
class Facade {
private SubsystemA subsystemA;
private SubsystemB subsystemB;
public Facade() {
subsystemA = new SubsystemA();
subsystemB = new SubsystemB();
}
public void operation() {
subsystemA.operationA();
subsystemB.operationB();
}
}
// 客户端类
public class Client {
public static void main(String[] args) {
Facade facade = new Facade();
facade.operation();
}
}程序分析
在上面的示例中，我们定义了两个子系统类 SubsystemA 和 SubsystemB，它们分别实现了不同的操作。然后我们定义了一个外观类 Facade，它将子系统类封装起来，并提供了一个简化的接口 operation。客户端类 Client 使用外观类来完成操作，而不需要直接与子系统类交互。
优缺点分析
优点
简化客户端的操作
外观模式提供了一个简化的接口，隐藏了子系统的复杂性，使客户端更容易使用。
解耦客户端和子系统
外观模式将客户端与子系统解耦，客户端只需要与外观类进行交互，不需要直接与子系统类交互，降低了客户端的复杂性。
提高系统的可用性和可维护性
外观模式将子系统的实现细节封装起来，保护了子系统的实现细节，使系统更加稳定和可维护。
缺点
可能导致系统变得更加复杂
当系统变得复杂时，外观类可能会变得庞大，难以维护。
限制了灵活性
外观模式隐藏了子系统的复杂性，但也限制了客户端对子系统的灵活访问。
总结
外观模式在简化客户端操作、解耦客户端和子系统、提高系统可用性和可维护性方面具有很大的优势，适用于需要隐藏复杂子系统的情况。但需要注意在设计时避免外观类变得庞大和过于复杂，以及权衡灵活性和封装性。
建造者模式
建造者模式是一种创建型设计模式，它可以将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。
角色分类
产品（Product）
表示被构建的复杂对象。通常包含多个部分，如属性、方法等。
抽象建造者（Builder）
定义了构建产品的抽象方法，通常包括构建各个部分的方法和返回产品的方法。
具体建造者（Concrete Builder）
实现了抽象建造者接口，负责具体的产品构建过程。通常包含一个具体产品的实例，通过构建各个部分最终返回该产品实例。
指挥者（Director）
负责调用具体建造者来构建产品，它不知道具体的构建细节，只负责调用构建方法和返回产品。
核心思想
将构建复杂对象的过程分解为多个简单的步骤，通过不同的具体建造者来实现这些步骤，最终由指挥者来调用具体建造者的方法来构建产品。这样可以使得构建过程更加灵活，可以根据需要选择不同的具体建造者来构建不同的产品。
Java程序
// 产品类
class Product {
private String part1;
private String part2;
public void setPart1(String part1) {
this.part1 = part1;
}
public void setPart2(String part2) {
this.part2 = part2;
}
public void show() {
System.out.println("Part 1: " + part1);
System.out.println("Part 2: " + part2);
}
}
// 抽象建造者
interface Builder {
void buildPart1();
void buildPart2();
Product getResult();
}
// 具体建造者
class ConcreteBuilder implements Builder {
private Product product;
public ConcreteBuilder() {
product = new Product();
}
public void buildPart1() {
product.setPart1("Part 1");
}
public void buildPart2() {
product.setPart2("Part 2");
}
public Product getResult() {
return product;
}
}
// 指挥者
class Director {
private Builder builder;
public Director(Builder builder) {
this.builder = builder;
}
public void construct() {
builder.buildPart1();
builder.buildPart2();
}
}
// 客户端
public class Client {
public static void main(String[] args) {
Builder builder = new ConcreteBuilder();
Director director = new Director(builder);
director.construct();
Product product = builder.getResult();
product.show();
}
}程序分析
在上述代码中，我们定义了一个产品类 Product，它有两个部分 part1 和 part2。然后我们定义了一个抽象建造者接口 Builder，其中包含了构建产品各个部分的方法，并定义了获取最终产品的方法。接着我们实现了具体建造者 ConcreteBuilder，它实现了建造者接口，并具体实现了构建各个部分的方法。然后我们定义了一个指挥者 Director，它负责控制建造过程，通过调用建造者的方法来构建产品。最后，在客户端中，我们创建了一个具体建造者对象，并将其传入指挥者中，然后通过指挥者来构建产品，并最终获取到构建好的产品并展示出来。
优缺点分析
优点
1
可以将复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。
2
可以更加精细地控制对象的构建过程，灵活地添加、删除或修改构建步骤，从而创建不同的产品。
3
可以避免构造方法中出现过多的参数，提高代码的可读性和可维护性。
4
可以通过建造者来隐藏具体产品的实现细节，只暴露统一的构建接口，提高代码的封装性。
缺点
1
增加了代码的复杂性，需要定义多个类和接口来实现建造者模式。
2
如果产品的组成部分变化较少，或者只有一个具体建造者，建造者模式可能会显得过于繁琐。
总结分析
建造者模式适用于构建复杂对象的场景，通过将构建过程分解为多个步骤，使得构建过程更加灵活，并且可以复用相同的构建过程来创建不同的产品。然而，建造者模式也会增加代码的复杂性，需要权衡使用建造者模式带来的优势和缺点。
观察者模式
观察者模式（Observer Pattern）是一种行为型设计模式，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，当主题对象发生变化时，它的所有观察者都会收到通知并更新自己。
核心思想
将观察者和被观察者之间的依赖关系解耦，使其彼此之间可以独立变化。被观察者只需要知道观察者实现了某个接口，而不需要知道具体的观察者类，同样，观察者只需要知道被观察者实现了某个接口，而不需要知道具体的被观察者类。
主要角色
Subject（被观察者）
定义了被观察者的接口，包含注册观察者、移除观察者和通知观察者的方法。
ConcreteSubject（具体被观察者）
实现了被观察者接口，维护观察者列表，并在状态发生改变时通知观察者。
Observer（观察者）
定义了观察者的接口，包含更新方法，用于接收被观察者的通知。
ConcreteObserver（具体观察者）
实现了观察者接口，具体实现更新方法，在接收到被观察者的通知时进行相应的处理。
Java程序实现
// 定义观察者接口
interface Observer {
void update(String message);
}
// 定义被观察者接口
interface Subject {
void registerObserver(Observer observer);
void removeObserver(Observer observer);
void notifyObservers(String message);
}
// 具体观察者类
class ConcreteObserver implements Observer {
private String name;
public ConcreteObserver(String name) {
this.name = name;
}
@Override
public void update(String message) {
System.out.println(name + " received message: " + message);
}
}
// 具体被观察者类
class ConcreteSubject implements Subject {
private List<Observer> observers = new ArrayList<>();
@Override
public void registerObserver(Observer observer) {
observers.add(observer);
}
@Override
public void removeObserver(Observer observer) {
observers.remove(observer);
}
@Override
public void notifyObservers(String message) {
for (Observer observer : observers) {
observer.update(message);
}
}
}
// 测试代码
public class ObserverPatternExample {
public static void main(String[] args) {
ConcreteSubject subject = new ConcreteSubject();
Observer observer1 = new ConcreteObserver("Observer 1");
Observer observer2 = new ConcreteObserver("Observer 2");
subject.registerObserver(observer1);
subject.registerObserver(observer2);
subject.notifyObservers("Hello, observers!");
subject.removeObserver(observer2);
subject.notifyObservers("Observer 2 has been removed!");
}
}输出结果
Observer 1 received message: Hello, observers!
Observer 2 received message: Hello, observers!
Observer 1 received message: Observer 2 has been removed!程序分析
在上述示例中，我们定义了一个观察者接口（Observer）和一个被观察者接口（Subject）。具体观察者类（ConcreteObserver）和具体被观察者类（ConcreteSubject）实现了对应的接口。
优缺点分析
优点
解耦性
观察者模式可以将观察者和被观察者之间的依赖关系解耦，使得它们可以独立变化。当被观察者发生变化时，只需要通知观察者即可，而不需要知道具体有哪些观察者存在。
可扩展性
观察者模式可以很方便地增加新的观察者，而不需要修改被观察者的代码。这符合开闭原则，使得系统更加灵活和可扩展。
一对多关系
观察者模式可以实现一对多的依赖关系，一个被观察者可以有多个观察者。这样可以方便地实现事件监听、消息订阅等功能。
缺点
观察者过多
当观察者过多时，被观察者通知观察者的时间可能会较长，影响系统的性能。
循环依赖
如果观察者和被观察者之间存在循环依赖关系，可能会导致系统出现问题，如死锁等。
更新顺序问题
观察者模式中观察者的更新顺序是不确定的，可能会导致观察者之间的依赖关系出现问题。
总结
可以提高系统的灵活性和可扩展性。但同时也需要注意观察者过多、循环依赖和更新顺序等问题，以确保系统的稳定性和性能。在使用观察者模式时，需要根据具体的场景和需求进行权衡和设计。
抽象工厂模式
抽象工厂模式（Abstract Factory Pattern）是一种创建型设计模式，它提供了一种封装一组相关或相互依赖对象创建的方式，而无需指定它们具体的类。
结构
抽象工厂（AbstractFactory）
声明一组创建产品对象的方法，每个方法对应一个具体产品类的创建。
具体工厂（ConcreteFactory）
实现抽象工厂接口，负责创建具体的产品对象。
抽象产品（AbstractProduct）
声明产品的共同接口，所有具体产品类都实现这个接口。
具体产品（ConcreteProduct）
实现抽象产品接口，定义具体产品的属性和行为。
适用情况
1
系统需要一组相关或相互依赖的产品对象，并希望统一创建它们。
2
系统不关心具体产品的创建过程，只关心产品的接口。
3
系统需要提供一个产品的类库，而不想暴露具体实现。
Java程序实现
首先，我们定义抽象产品接口：
public interface Shape {
void draw();
}然后，我们定义具体产品类实现抽象产品接口：
public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Inside Circle::draw() method.");
}
}
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Inside Rectangle::draw() method.");
}
}接下来，我们定义抽象工厂接口：
public interface ShapeFactory {
Shape createShape();
}然后，我们定义具体工厂类实现抽象工厂接口：
public class CircleFactory implements ShapeFactory {
@Override
public Shape createShape() {
return new Circle();
}
}
public class RectangleFactory implements ShapeFactory {
@Override
public Shape createShape() {
return new Rectangle();
}
}最后，我们可以使用抽象工厂模式来创建具体产品对象：
public class Main {
public static void main(String[] args) {
ShapeFactory circleFactory = new CircleFactory();
ShapeFactory rectangleFactory = new RectangleFactory();
Shape circle = circleFactory.createShape();
circle.draw();
Shape rectangle = rectangleFactory.createShape();
rectangle.draw();
}
}输出结果
Inside Circle::draw() method.
Inside Rectangle::draw() method.程序分析
我们定义了抽象产品接口 Shape 和具体产品类 Circle 和 Rectangle。然后，我们定义了抽象工厂接口 ShapeFactory 和具体工厂类 CircleFactory 和 RectangleFactory。最后，我们使用抽象工厂模式创建了具体产品对象 Circle 和 Rectangle。
优缺点分析
优点
1
提供了一种方便的方式来创建一组相关的产品对象，使得客户端无需关心具体产品的创建细节，只需要通过抽象接口来使用产品。
2
客户端与具体产品类解耦，增强了系统的灵活性和可扩展性。可以方便地替换具体工厂类和产品类，而不影响客户端的代码。
3
符合开闭原则，增加新的产品族和产品等级结构时，只需要添加对应的具体工厂类和产品类，而不需要修改已有的代码。
缺点
1
增加了系统的复杂度和理解难度。由于抽象工厂模式涉及多个抽象接口和具体实现类，需要理解和管理的类和接口较多，增加了代码的复杂性。
2
当需要增加新的产品等级结构时，需要修改抽象工厂接口和所有具体工厂类，破坏了开闭原则。
3
当产品族中的产品种类非常多时，会导致具体工厂类的数量增加，增加了系统的维护成本。
状态模式
状态模式是一种行为型设计模式，它允许一个对象在内部状态发生变化时改变其行为。状态模式将对象的行为封装在不同的状态类中，通过改变对象的状态来改变其行为。
关键角色
上下文(Context)
上下文是一个包含状态的对象，它定义了客户端与状态对象的交互接口。上下文中维护了一个指向当前状态的引用，并且在运行时可以切换到不同的状态。上下文将客户端请求委派给当前状态对象处理。
抽象状态(State)
抽象状态是一个接口或抽象类，它定义了状态对象的通用行为。具体状态类需要实现这个接口或继承这个抽象类，并且根据具体的状态来实现相应的行为。
具体状态(Concrete State)
具体状态是实现抽象状态的具体类。每个具体状态类都代表了上下文在特定状态下的行为。具体状态类负责处理上下文的请求，并在需要时切换到其他状态。
核心思想
将状态的判断和状态的行为分离，使得状态的变化不影响行为的变化。通过将状态的行为封装在具体状态类中，可以方便地添加新的状态或修改现有状态的行为，同时也避免了状态判断的复杂性。
Java程序实现
首先，我们定义一个抽象状态类 State，其中包含一个处理请求的方法 handleRequest()：
public abstract class State {
public abstract void handleRequest();
}然后，我们创建两个具体状态类 ConcreteStateA 和 ConcreteStateB，它们分别实现了抽象状态类 State：
public class ConcreteStateA extends State {
@Override
public void handleRequest() {
System.out.println("处理请求，当前状态为A");
}
}
public class ConcreteStateB extends State {
@Override
public void handleRequest() {
System.out.println("处理请求，当前状态为B");
}
}接下来，我们创建一个上下文类 Context，其中包含一个指向当前状态的引用，并提供了一个方法 setState() 用于切换状态和一个方法 request() 用于处理请求：
public class Context {
private State currentState;
public Context() {
// 初始化为初始状态
currentState = new ConcreteStateA();
}
public void setState(State state) {
currentState = state;
}
public void request() {
currentState.handleRequest();
}
}最后，我们可以在客户端代码中使用上下文类来测试状态模式的效果：
public class Client {
public static void main(String[] args) {
Context context = new Context();
// 处理请求，当前状态为A
context.request();
// 切换状态为B
context.setState(new ConcreteStateB());
// 处理请求，当前状态为B
context.request();
}
}输出结果
处理请求，当前状态为A
处理请求，当前状态为B分析
在上述示例中，我们通过状态模式实现了一个简单的上下文对象 Context，它可以根据不同的状态来处理请求。通过切换状态，上下文对象可以改变其行为。这样，我们可以方便地添加新的状态类或修改现有状态的行为，而不需要修改客户端代码。
优缺点分析
优点
1
通过将状态的行为封装在具体状态类中，可以使得状态的变化对客户端透明，客户端只需要与上下文进行交互，不需要关心具体的状态。
2
增加新的状态类相对容易，符合开闭原则，不需要修改现有的代码。
3
将状态的行为集中到具体状态类中，使得代码更加清晰，易于维护和扩展。
缺点
1
当状态的行为比较少或简单时，使用状态模式可能会导致类的数量增加，增加了代码的复杂性。
2
如果状态之间存在相互转换的复杂逻辑，可能需要引入其他模式来处理状态之间的转换。
总结
状态模式是一种通过将状态的行为封装在具体状态类中，使得状态的变化不影响行为的设计模式。它可以使代码更加清晰、易于维护和扩展，适用于状态变化较多且状态之间的行为差异较大的场景。
适配器模式
适配器模式是一种结构型设计模式，它允许将一个类的接口转换成客户端所期望的另一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的类可以一起工作。
角色分析
目标接口（Target）
客户端期望的接口，适配器将原始接口转换成目标接口。
源接口（Adaptee）
需要被适配的类或接口。
适配器（Adapter）
实现目标接口，同时持有源接口的实例，将目标接口的方法调用转发给源接口的实例。
核心思想
通过适配器将目标接口的方法调用转发给源接口的实例。这样一来，客户端就可以通过目标接口来使用源接口的功能。
应用场景
当需要使用一个已经存在的类，但其接口不符合需求时，可以使用适配器模式。例如，使用第三方库提供的接口，但需要将其转换成自己系统中的接口。 当需要复用一些已经存在的类，但是接口与系统的其他部分不兼容时，可以使用适配器模式。例如，将不同数据库的操作接口统一成一个接口。
Java程序实现
// 目标接口
interface Target {
void request();
}
// 源接口
class Adaptee {
void specificRequest() {
System.out.println("Adaptee: specificRequest");
}
}
// 适配器
class Adapter implements Target {
private Adaptee adaptee;
Adapter(Adaptee adaptee) {
this.adaptee = adaptee;
}
@Override
public void request() {
adaptee.specificRequest();
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
Adaptee adaptee = new Adaptee();
Target target = new Adapter(adaptee);
target.request();
}
}
输出结果
Adaptee: specificRequest这说明适配器模式成功地将不兼容的接口转换成了兼容的接口，使得客户端可以使用目标接口来调用源接口的功能。
程序分析
1
在上面的示例中，我们有一个目标接口Target，其中定义了客户端所期望的方法request。我们还有一个源接口Adaptee，其中有一个不兼容的方法specificRequest。
2
为了使得客户端可以使用Target接口来调用specificRequest方法，我们创建了一个适配器Adapter，实现了Target接口，并持有一个Adaptee的实例。在适配器的request方法中，我们将Target接口的方法调用转发给Adaptee的specificRequest方法。
3
在客户端代码中，我们创建了一个Adaptee实例和一个适配器Adapter实例，并将Adaptee实例传递给适配器的构造函数。然后，我们使用Target接口来调用request方法，实际上是调用了Adaptee的specificRequest方法。
优缺点分析
优点
1
适配器模式可以让不兼容的接口协同工作。
2
适配器模式可以复用已有的类，而无需修改其源代码。
3
适配器模式可以将不同接口的类组合在一起工作。
缺点
1
适配器模式增加了系统的复杂性，因为需要增加一个适配器类。
2
适配器模式可能会降低系统的性能，因为需要进行额外的转换操作。
总结
适配器模式可以将不兼容的接口转换成兼容的接口，使得原本无法一起工作的类可以协同工作。它是一种非常常用的设计模式，可以提高系统的灵活性和可扩展性。
备忘录模式
备忘录模式（Memento Pattern）是一种行为型设计模式，它允许在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便在需要时能将该对象恢复到原先保存的状态。
主要角色
发起人（Originator）
负责创建一个备忘录对象，用于保存自身状态，并可以使用备忘录对象来恢复自身状态。
备忘录（Memento）
用于存储发起人对象的内部状态，可以包含多个状态属性。
管理者（Caretaker）
负责保存备忘录对象，但不能对备忘录对象进行修改或检查。
应用场景
- 需要保存和恢复对象的内部状态，但不希望暴露对象实现细节。
- 需要在某个时间点保存对象的状态，并在需要时恢复到该状态。
- 需要实现撤销操作。
结构
- 发起人（Originator） 负责创建一个备忘录对象，保存自身状态，并可以使用备忘录对象来恢复自身状态。可以通过构造函数或者setter方法将自身状态传递给备忘录对象。
- 备忘录（Memento） 用于存储发起人对象的内部状态，可以包含多个状态属性。备忘录对象应该只能由发起人对象访问。
- 管理者（Caretaker） 负责保存备忘录对象，但不能对备忘录对象进行修改或检查。可以使用栈或列表等数据结构来保存多个备忘录对象，以支持多次撤销操作。
实现步骤
- 在发起人类中，定义一个内部类作为备忘录类，该类用于保存发起人对象的状态。
- 在发起人类中，提供创建备忘录对象、恢复状态的方法。
- 在管理者类中，保存备忘录对象，并提供对外的保存和获取备忘录对象的方法。
- 在客户端中，通过发起人类和管理者类来实现对对象状态的保存和恢复操作。
Java程序实现
首先，我们定义发起人类（Originator）
public class Originator {
private String state;
public void setState(String state) {
this.state = state;
}
public String getState() {
return state;
}
public Memento createMemento() {
return new Memento(state);
}
public void restoreMemento(Memento memento) {
this.state = memento.getState();
}
}然后，定义备忘录类（Memento）
public class Memento {
private String state;
public Memento(String state) {
this.state = state;
}
public String getState() {
return state;
}
}接下来，定义管理者类（Caretaker）
public class Caretaker {
private Memento memento;
public void saveMemento(Memento memento) {
this.memento = memento;
}
public Memento getMemento() {
return memento;
}
}最后，我们可以在客户端中使用备忘录模式
public class Client {
public static void main(String[] args) {
Originator originator = new Originator();
originator.setState("State 1");
Caretaker caretaker = new Caretaker();
caretaker.saveMemento(originator.createMemento());
originator.setState("State 2");
System.out.println("Current state: " + originator.getState());
originator.restoreMemento(caretaker.getMemento());
System.out.println("Restored state: " + originator.getState());
}
}输出结果
Current state: State 2
Restored state: State 1
程序分析
以上代码演示了备忘录模式的基本用法。发起人类（Originator）保存了一个状态（state），并提供了创建备忘录和恢复状态的方法。管理者类（Caretaker）负责保存备忘录对象。在客户端中，我们可以通过发起人类和管理者类来实现对状态的保存和恢复操作。
优缺点分析
优点
- 发起人类与备忘录类解耦，发起人类不需要知道备忘录类的实现细节。
- 备忘录类对外提供只读的状态访问接口，保证了状态的安全性。
- 可以轻松实现撤销操作，只需要保存多个备忘录对象，并在需要时恢复到指定的状态。
缺点
- 如果需要保存的状态非常庞大，备忘录对象的创建和恢复操作可能会消耗大量的资源。
总结
备忘录模式通过将对象的状态保存到备忘录对象中，实现了状态的保存和恢复。它可以帮助我们实现撤销操作，以及在需要时恢复对象的状态。备忘录模式可以提高系统的灵活性和可维护性，但需要注意备忘录对象的创建和恢复操作可能会消耗较多的资源。在实际应用中，我们可以根据具体的需求和场景来选择是否使用备忘录模式。
组合模式
组合模式是一种结构型设计模式，它允许将对象组合成树状结构以表示“部分-整体”的层次结构。组合模式使得客户端可以统一地处理单个对象和组合对象，无需区分它们的区别。
对象类型
叶节点（Leaf）和组合节点（Composite）
叶节点
它表示树的最底层的对象，它们没有子节点。
组合节点
它表示树的分支节点，它可以包含其他的组合节点和叶节点。
核心思想
使用一个抽象类或接口来定义组合节点和叶节点的公共操作。这样，客户端可以通过调用这些公共操作来处理组合节点和叶节点，而无需知道具体的节点类型。
应用场景
1
需要表示对象的部分-整体层次结构，并且希望客户端能够一致地处理单个对象和组合对象的情况。
2
需要对树状结构进行递归操作，例如遍历树、查找特定节点等。
3
需要动态地增加或删除树的节点。
结构图
结构图分析
在上面的结构图中，Component 是组合模式的抽象类或接口，定义了组合节点和叶节点共有的操作。Composite 是组合节点的具体实现，它可以包含其他的组合节点和叶节点。Leaf 是叶节点的具体实现。
Java语言实现
首先，我们需要定义一个抽象的组件类 Component，它包含了组合节点和叶节点的公共操作：
public abstract class Component {
protected String name;
public Component(String name) {
this.name = name;
}
public abstract void operation();
public abstract void add(Component component);
public abstract void remove(Component component);
public abstract Component getChild(int index);
}然后，我们定义组合节点类 Composite，它实现了 Component 接口，并包含了一个子组件列表：
import java.util.ArrayList;
import java.util.List;
public class Composite extends Component {
private List<Component> children;
public Composite(String name) {
super(name);
children = new ArrayList<>();
}
@Override
public void operation() {
System.out.println("Composite " + name + " operation.");
for (Component component : children) {
component.operation();
}
}
@Override
public void add(Component component) {
children.add(component);
}
@Override
public void remove(Component component) {
children.remove(component);
}
@Override
public Component getChild(int index) {
return children.get(index);
}
}最后，我们定义叶节点类 Leaf，它也实现了 Component 接口，但它没有子节点：
public class Leaf extends Component {
public Leaf(String name) {
super(name);
}
@Override
public void operation() {
System.out.println("Leaf " + name + " operation.");
}
@Override
public void add(Component component) {
// 叶节点不支持添加操作
}
@Override
public void remove(Component component) {
// 叶节点不支持删除操作
}
@Override
public Component getChild(int index) {
// 叶节点没有子节点
return null;
}
}现在，我们可以使用组合模式来创建一个树状结构并操作它：
public class Main {
public static void main(String[] args) {
// 创建树状结构
Composite root = new Composite("root");
Composite branch1 = new Composite("branch1");
Composite branch2 = new Composite("branch2");
Leaf leaf1 = new Leaf("leaf1");
Leaf leaf2 = new Leaf("leaf2");
Leaf leaf3 = new Leaf("leaf3");
root.add(branch1);
root.add(branch2);
branch1.add(leaf1);
branch2.add(leaf2);
branch2.add(leaf3);
// 调用操作方法
root.operation();
}
}运行上述代码，输出结果如下
Composite root operation.
Composite branch1 operation.
Leaf leaf1 operation.
Composite branch2 operation.
Leaf leaf2 operation.
Leaf leaf3 operation.总结
以上就是使用Java语言实现组合模式的示例代码。通过组合模式，我们可以方便地处理树状结构，并且客户端可以一致地处理单个对象和组合对象。
优缺点分析
优点
简化客户端代码
客户端可以一致地处理单个对象和组合对象，无需区分它们的差异。
增加新的节点类型
通过继承 Component 类，可以方便地增加新的节点类型，而无需修改现有的代码。
方便地处理递归结构
组合模式适用于处理递归结构，例如树状结构。
缺点
可能会导致设计过于一般化
组合模式将叶节点和组合节点都抽象为 Component 类，可能会导致设计过于一般化，不适合特定的场景。
可能会增加系统的复杂性
组合模式引入了组合节点和叶节点的层次结构，可能会增加系统的复杂性。
迭代器模式
迭代器模式是一种行为型设计模式，它提供了一种访问聚合对象中各个元素的方法，而不需要暴露聚合对象的内部表示。迭代器模式将遍历元素的责任交给迭代器对象，从而简化了聚合对象的接口。
对象分析
聚合对象（Aggregate）
聚合对象是包含一组元素的对象，它通常提供一个创建迭代器的方法。聚合对象可以是一个集合、数组、列表等。聚合对象的主要职责是通过迭代器对象提供对元素的遍历。
迭代器对象（Iterator）
迭代器对象负责遍历聚合对象中的元素。它通常包含一些基本的方法，如获取下一个元素、判断是否还有下一个元素等。迭代器对象可以根据具体的需求实现不同的遍历方式，如正向遍历、逆向遍历等。
Java程序示例
// 聚合对象
public interface Aggregate {
Iterator createIterator();
}
// 具体的聚合对象
public class ConcreteAggregate implements Aggregate {
private List<Object> items = new ArrayList<>();
public void addItem(Object item) {
items.add(item);
}
public Iterator createIterator() {
return new ConcreteIterator(items);
}
}
// 迭代器对象
public interface Iterator {
boolean hasNext();
Object next();
}
// 具体的迭代器对象
public class ConcreteIterator implements Iterator {
private List<Object> items;
private int position = 0;
public ConcreteIterator(List<Object> items) {
this.items = items;
}
public boolean hasNext() {
return position < items.size();
}
public Object next() {
Object item = items.get(position);
position++;
return item;
}
}
// 使用迭代器模式
public class Main {
public static void main(String[] args) {
ConcreteAggregate aggregate = new ConcreteAggregate();
aggregate.addItem("Item 1");
aggregate.addItem("Item 2");
aggregate.addItem("Item 3");
Iterator iterator = aggregate.createIterator();
while (iterator.hasNext()) {
Object item = iterator.next();
System.out.println(item);
}
}
}
程序分析
1
在上述示例中，Aggregate 接口定义了创建迭代器的方法 createIterator，ConcreteAggregate 是具体的聚合对象，实现了 createIterator 方法，返回具体的迭代器对象 ConcreteIterator。ConcreteIterator 实现了 Iterator 接口，提供了遍历聚合对象中元素的功能。
2
在 Main 类中，我们创建了一个具体的聚合对象 ConcreteAggregate，添加了一些元素。然后通过 createIterator 方法创建了一个迭代器对象，并使用 while 循环遍历聚合对象中的元素。
优缺点分析
优点
简化了聚合对象的接口
迭代器模式将遍历聚合对象的责任封装在迭代器对象中，使得聚合对象的接口更加简洁，只需要提供一个创建迭代器的方法即可。
统一的遍历方式
迭代器模式提供了一种统一的遍历方式，无论聚合对象的内部结构如何变化，都可以通过迭代器对象进行遍历，使得客户端代码更加简洁和可读。
增加了代码的可读性和可维护性
迭代器模式将遍历逻辑封装在迭代器对象中，使得代码的逻辑更加清晰，易于理解和维护。
缺点
增加了系统的复杂性
引入迭代器模式会增加系统的类和对象的数量，增加了系统的复杂性。
迭代器的实现可能会受到聚合对象的影响
迭代器的实现通常依赖于聚合对象的内部结构，如果聚合对象的结构发生变化，可能需要相应地修改迭代器的实现。
不适合对于某些特殊聚合对象的遍历
迭代器模式适用于遍历聚合对象的情况，但对于某些特殊的聚合对象，如树形结构，可能需要使用其他遍历方式。
总结
迭代器模式通过封装遍历聚合对象的责任，简化了聚合对象的接口，提供了一种统一的遍历方式，增加了代码的可读性和可维护性。然而，迭代器模式也会增加系统的复杂性，可能受到聚合对象的影响，并且不适用于某些特殊聚合对象的遍历。因此，在使用迭代器模式时需要权衡其优缺点，根据具体情况进行选择。
单例模式
单例模式是一种创建型设计模式，它保证一个类只有一个实例，并提供一个全局访问点。单例模式在许多情况下都非常有用，比如控制资源的访问、线程池、日志对象等。
点睛所在
控制对象的实例化过程。通常情况下，我们可以通过将构造函数私有化来防止外部直接创建对象。然后，我们需要提供一个静态方法来获取单例对象，这个方法负责创建对象并在后续调用时返回同一个实例。
优缺点分析
优点
确保只有一个实例
单例模式可以确保一个类只有一个实例存在，这样可以避免多个实例之间的冲突和资源的浪费。
全局访问点
单例模式提供了一个全局访问点，使得其他对象可以方便地访问该实例，避免了对象之间的耦合。
节省资源
由于单例模式只创建一个实例，可以节省系统资源，特别是在需要频繁创建和销毁对象的情况下，可以显著提高系统的性能。
线程安全
通过合理的实现方式，单例模式可以保证在多线程环境下的线程安全性。
缺点
难以扩展
由于单例模式只允许存在一个实例，因此难以扩展为多个实例。如果需要创建多个实例，就需要修改单例模式的实现。
对象的生命周期
由于单例模式的实例在整个程序运行期间都存在，可能会导致对象的生命周期过长，造成资源的浪费。
单一职责原则
单例模式将创建对象和控制访问对象的责任集中在一起，违反了单一职责原则。这可能会导致单例类的职责过重，不利于代码的维护和扩展。
隐藏依赖关系
单例模式可能会导致对象之间的依赖关系变得隐式，使得代码的可读性和可维护性降低。
Java程序实例
实例a
public class Singleton {
private static Singleton instance;
private Singleton() {
// 私有构造函数
}
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}分析
在这个实现中，我们将构造函数私有化，然后提供了一个静态方法 getInstance() 来获取单例对象。在这个方法中，我们首先检查实例是否已经被创建，如果没有则创建一个新的实例并返回。这种实现方式被称为 “懒汉式”，因为它只有在第一次调用 getInstance() 方法时才会创建实例。
但是，这种实现方式并不是线程安全的。如果多个线程同时调用 getInstance() 方法，可能会导致多个实例被创建。为了解决这个问题，我们可以使用同步锁来保证线程安全。
实例b，更安全
public class Singleton {
private static Singleton instance;
private Singleton() {
// 私有构造函数
}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}分析
在这个实现中，我们使用了 synchronized 关键字来保证线程安全。但是，这种实现方式会导致性能问题，因为每次调用 getInstance() 方法时都会进行同步。
优化 ——“双重检查锁定” 实现方式
public class Singleton {
private static volatile Singleton instance;
private Singleton() {
// 私有构造函数
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}分析
在这个实现中，我们首先检查实例是否已经被创建，如果没有则进入同步块。在同步块中，我们再次检查实例是否已经被创建，如果没有则创建一个新的实例。使用 volatile 关键字可以保证多线程下的可见性。
总结
单例模式在一些特定的场景下非常有用，可以确保一个类只有一个实例，并提供全局访问点。但是，需要注意单例模式的实现方式，避免出现线程安全和性能问题，并权衡其优缺点来决定是否使用单例模式。
桥接模式
桥接模式是一种结构型设计模式，它将抽象部分与实现部分分离，使它们可以独立变化。桥接模式通过将抽象和实现分离，可以实现抽象部分和实现部分的独立扩展，从而提高系统的灵活性
主要角色
抽象部分
定义了抽象的接口，包含了抽象方法和属性，它通常是一个抽象类或接口。
实现部分
定义了具体的实现，实现了抽象部分中的方法和属性，它也是一个抽象类或接口。
分析
通过将抽象部分和实现部分分离，使得它们可以独立变化。这样一来，如果需要增加新的抽象部分或实现部分，只需要扩展相应的抽象类或接口即可，而不需要修改原有的代码。
核心思想
将抽象和实现解耦，使得它们可以独立变化。通过桥接模式，可以实现抽象部分和实现部分的独立扩展，提高系统的灵活性和可扩展性。
应用场景
1
当一个类存在两个或多个独立变化的维度时，可以使用桥接模式将它们分离，使得它们可以独立变化。
2
当一个类需要在运行时选择不同的实现时，可以使用桥接模式。
3
当一个类需要通过组合而不是继承来实现不同的行为时，可以使用桥接模式。
优缺点分析
优点
1
分离抽象和实现，提高了系统的灵活性和可扩展性。
2
对于客户端来说，抽象部分和实现部分是透明的，可以独立变化，不影响客户端的使用。
3
可以通过组合来实现不同的行为，避免了继承的缺点。
缺点
1
增加了系统的复杂性，需要额外的抽象部分和实现部分。
2
对于小规模的系统，可能会增加代码量。
总结
桥接模式是一种将抽象和实现解耦的设计模式，通过将抽象部分和实现部分分离，实现了抽象部分和实现部分的独立变化，提高了系统的灵活性和可扩展性。
命令模式
命令模式是一种行为型设计模式，它将请求封装成一个对象，从而使得可以用不同的请求对客户进行参数化，同时支持请求的排队、记录请求日志、撤销操作等
角色分析
命令（Command）
定义了执行操作的接口，通常包含一个execute()方法，用于执行相关操作。
具体命令（ConcreteCommand）
实现了命令接口，具体定义了执行操作的具体逻辑。
接收者（Receiver）
执行命令所要求的操作，是具体命令对象的业务处理对象。
调用者（Invoker）
负责调用命令对象执行请求，通常会持有命令对象的引用。
客户端（Client）
创建具体命令对象，并设置命令对象的接收者。
工作流程
1
客户端创建具体命令对象，并设置命令对象的接收者。
2
调用者持有具体命令对象的引用，并调用命令对象的execute()方法。
3
具体命令对象执行相关操作，并将请求传递给接收者进行处理。
Java程序实现
// 定义命令接口
public interface Command {
void execute();
}
// 定义具体命令类
public class ConcreteCommand implements Command {
private Receiver receiver;
public ConcreteCommand(Receiver receiver) {
this.receiver = receiver;
}
public void execute() {
receiver.action();
}
}
// 定义接收者类
public class Receiver {
public void action() {
System.out.println("接收者执行操作");
}
}
// 定义调用者类
public class Invoker {
private Command command;
public void setCommand(Command command) {
this.command = command;
}
public void executeCommand() {
command.execute();
}
}
// 客户端代码
public class Client {
public static void main(String[] args) {
// 创建接收者对象
Receiver receiver = new Receiver();
// 创建具体命令对象，并传入接收者对象
Command command = new ConcreteCommand(receiver);
// 创建调用者对象，并设置具体命令对象
Invoker invoker = new Invoker();
invoker.setCommand(command);
// 调用者执行命令
invoker.executeCommand();
}
}
分析
在上面的示例中，定义了一个命令接口 Command，具体命令类 ConcreteCommand 实现了该接口，并在 execute() 方法中调用接收者对象的操作方法。
接收者类 Receiver 定义了具体的操作方法 action()。
调用者类 Invoker 持有一个命令对象，并提供了 setCommand() 方法来设置具体的命令对象，以及 executeCommand() 方法来执行命令。
在客户端代码中，创建了接收者对象、具体命令对象和调用者对象，并设置具体命令对象到调用者对象中，最后调用调用者对象的 executeCommand() 方法来执行命令。
输出结果
··· 接收者执行操作 ···
优缺点分析
优点
解耦调用者和接收者
命令模式将请求封装成一个对象，使得调用者不需要知道接收者的具体实现，只需要通过命令对象来执行请求。这样可以降低调用者和接收者之间的耦合度，提高系统的灵活性和可维护性。
支持请求的排队和记录
命令模式可以将多个命令对象放入队列中，按照一定的顺序执行。这样可以实现请求的排队和调度，也可以记录请求日志，方便后续操作和追踪。
支持撤销操作
命令模式可以保存命令对象的状态，从而支持撤销操作。通过保存命令对象的历史状态，可以实现撤销和恢复操作，提供更好的用户体验。
可扩展性强
命令模式可以通过新增具体命令类来扩展系统的功能，而不需要修改现有的代码。这样可以保持系统的稳定性，同时也方便了系统的维护和升级。
缺点
类的数量增加
引入命令模式会增加系统中的类的数量，每个具体命令类都需要实现命令接口。这样可能会增加系统的复杂性，降低代码的可读性。
命令的执行效率
由于命令模式需要将请求封装成对象，并通过调用者来执行，因此相比直接调用接收者的方法，命令模式的执行效率可能会稍低。
可能引入额外的复杂性
命令模式需要设计和管理命令对象、调用者、接收者等多个角色，可能会引入额外的复杂性。尤其是在处理多个命令对象之间的协作和交互时，需要仔细设计和管理。
总结
命令模式在需要将请求封装成对象、支持请求的排队、记录请求日志、撤销操作等场景下非常有用。但在一些简单的场景下，引入命令模式可能会增加系统的复杂性，需要权衡使用。
职责链模式
职责链模式（Chain of Responsibility Pattern）是一种行为型设计模式，它允许多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。职责链模式将请求的发送者和接收者解耦，让多个对象都有机会处理请求，直到其中一个对象处理成功为止。
分析
在职责链模式中，通常会有一个抽象处理者（Handler）类，它定义了处理请求的接口和一个指向下一个处理者的引用。具体处理者（ConcreteHandler）类实现了抽象处理者的接口，负责处理特定的请求，如果自己无法处理，则将请求传递给下一个处理者。
角色分析
抽象处理者（Handler）
定义了处理请求的接口，并持有下一个处理者的引用。
具体处理者（ConcreteHandler）
实现了抽象处理者的接口，负责处理特定的请求，如果无法处理则将请求传递给下一个处理者。
客户端（Client）
创建处理链，并将请求发送给链中的第一个处理者。
优缺点分析
优点
1
降低了请求的发送者和接收者之间的耦合，请求发送者无需知道具体的处理者，只需将请求发送给第一个处理者即可。
2
可以动态地增加或修改处理链，增强了灵活性。
3
可以将请求的处理逻辑分布到多个处理者中，避免了单个处理者处理过多的责任。
缺点
1
请求可能无法被处理，或者没有处理者能够处理请求，需要在链的末尾设置一个默认的处理者来处理这种情况。
2
请求可能会被多个处理者都处理，需要控制好处理者之间的关系，避免重复处理。
应用场景
多级审批流程
例如请假审批、报销审批等，每个级别的领导都有机会处理请求。
异常处理
例如在一个系统中，可以通过职责链模式将不同类型的异常交给不同的处理者处理。
日志记录
例如在一个系统中，可以通过职责链模式将不同级别的日志交给不同的处理者记录。
Java程序分析
首先，我们需要定义抽象处理者（Handler）接口，包含处理请求的方法和设置下一个处理者的方法：
public abstract class Handler {
protected Handler nextHandler;
public void setNextHandler(Handler nextHandler) {
this.nextHandler = nextHandler;
}
public abstract void handleRequest(Request request);
}然后，我们创建具体处理者（ConcreteHandler）类，实现抽象处理者接口，并在处理请求时判断是否能够处理该请求，如果能够处理则进行处理，否则将请求传递给下一个处理者：
public class ConcreteHandlerA extends Handler {
@Override
public void handleRequest(Request request) {
if (request.getType().equals("TypeA")) {
System.out.println("ConcreteHandlerA handles the request.");
} else if (nextHandler != null) {
nextHandler.handleRequest(request);
}
}
}
public class ConcreteHandlerB extends Handler {
@Override
public void handleRequest(Request request) {
if (request.getType().equals("TypeB")) {
System.out.println("ConcreteHandlerB handles the request.");
} else if (nextHandler != null) {
nextHandler.handleRequest(request);
}
}
}
public class ConcreteHandlerC extends Handler {
@Override
public void handleRequest(Request request) {
if (request.getType().equals("TypeC")) {
System.out.println("ConcreteHandlerC handles the request.");
} else if (nextHandler != null) {
nextHandler.handleRequest(request);
}
}
}最后，我们创建客户端（Client）类，创建处理链并将请求发送给链中的第一个处理者：
public class Client {
public static void main(String[] args) {
Handler handlerA = new ConcreteHandlerA();
Handler handlerB = new ConcreteHandlerB();
Handler handlerC = new ConcreteHandlerC();
handlerA.setNextHandler(handlerB);
handlerB.setNextHandler(handlerC);
Request requestA = new Request("TypeA");
Request requestB = new Request("TypeB");
Request requestC = new Request("TypeC");
Request requestD = new Request("TypeD");
handlerA.handleRequest(requestA);
handlerA.handleRequest(requestB);
handlerA.handleRequest(requestC);
handlerA.handleRequest(requestD);
}
}输出结果
ConcreteHandlerA handles the request.
ConcreteHandlerB handles the request.
ConcreteHandlerC handles the request.
No handler can handle the request.
分析
在这个示例中，我们创建了三个具体处理者（ConcreteHandlerA、ConcreteHandlerB、ConcreteHandlerC），它们分别能够处理不同类型的请求。我们通过设置每个处理者的下一个处理者，形成了一个处理链。当客户端发送请求时，请求会从链的第一个处理者开始处理，如果某个处理者能够处理该请求，则进行处理，否则将请求传递给下一个处理者，直到找到能够处理请求的处理者为止。如果整个链都无法处理请求，则输出提示信息。
中介者模式
中介者模式（Mediator Pattern）是一种行为型设计模式，它通过将对象之间的通信封装到一个中介者对象中，从而实现对象之间的松耦合。中介者模式可以减少对象之间的直接依赖，提高系统的灵活性和可维护性。
分析
在中介者模式中，存在一个中介者对象，它封装了对象之间的通信逻辑。对象之间的通信不再直接发生，而是通过中介者对象进行。当一个对象需要与其他对象进行通信时，它不需要知道其他对象的具体细节，只需要与中介者进行交互即可。
角色分析
抽象中介者（Mediator）
定义了中介者对象的接口，它通常包含一个或多个抽象的通信方法，用于定义对象之间的通信规则。
具体中介者（ConcreteMediator）
实现了抽象中介者的接口，它通过协调各个同事对象来实现协作行为。
抽象同事类（Colleague）
定义了同事对象的接口，它通常包含一个中介者对象的引用，用于与中介者进行通信。
具体同事类（ConcreteColleague）
实现了抽象同事类的接口，它与其他同事对象通过中介者进行通信。
工作过程
各个同事对象将自己的引用传递给中介者对象，以便中介者对象能够与各个同事对象进行通信。 当一个同事对象需要与其他同事对象进行通信时，它将请求发送给中介者对象。 中介者对象接收到请求后，根据通信规则进行相应的处理，并将请求转发给目标同事对象。 目标同事对象接收到请求后，进行相应的处理。
优缺点分析
优点分析
1
减少了对象之间的直接依赖，提高了系统的灵活性和可维护性。
2
将对象之间的通信集中到一个中介者对象中，使得系统结构更加清晰。
缺点分析
1
中介者对象将承担较多的责任，可能会变得复杂。
2
如果中介者对象存在过多的逻辑，可能会影响系统的性能。
适用场景
1
当对象之间存在复杂的通信逻辑时，可以使用中介者模式将通信逻辑集中到一个中介者对象中。
2
当对象之间的通信关系呈现网状结构时，可以使用中介者模式将通信关系简化为星型结构。
Java程序分析
// 抽象中介者
interface Mediator {
void sendMessage(String message, Colleague colleague);
}
// 具体中介者
class ConcreteMediator implements Mediator {
private Colleague colleague1;
private Colleague colleague2;
public void setColleague1(Colleague colleague1) {
this.colleague1 = colleague1;
}
public void setColleague2(Colleague colleague2) {
this.colleague2 = colleague2;
}
@Override
public void sendMessage(String message, Colleague colleague) {
if (colleague == colleague1) {
colleague2.receiveMessage(message);
} else if (colleague == colleague2) {
colleague1.receiveMessage(message);
}
}
}
// 抽象同事类
abstract class Colleague {
protected Mediator mediator;
public Colleague(Mediator mediator) {
this.mediator = mediator;
}
public abstract void sendMessage(String message);
public abstract void receiveMessage(String message);
}
// 具体同事类
class ConcreteColleague1 extends Colleague {
public ConcreteColleague1(Mediator mediator) {
super(mediator);
}
@Override
public void sendMessage(String message) {
mediator.sendMessage(message, this);
}
@Override
public void receiveMessage(String message) {
System.out.println("ConcreteColleague1 received message: " + message);
}
}
// 具体同事类
class ConcreteColleague2 extends Colleague {
public ConcreteColleague2(Mediator mediator) {
super(mediator);
}
@Override
public void sendMessage(String message) {
mediator.sendMessage(message, this);
}
@Override
public void receiveMessage(String message) {
System.out.println("ConcreteColleague2 received message: " + message);
}
}
// 测试类
public class MediatorPatternExample {
public static void main(String[] args) {
ConcreteMediator mediator = new ConcreteMediator();
ConcreteColleague1 colleague1 = new ConcreteColleague1(mediator);
ConcreteColleague2 colleague2 = new ConcreteColleague2(mediator);
mediator.setColleague1(colleague1);
mediator.setColleague2(colleague2);
colleague1.sendMessage("Hello from colleague1");
colleague2.sendMessage("Hi from colleague2");
}
}分析
1
在上述示例中，Mediator是抽象中介者接口，定义了中介者对象的通信方法。ConcreteMediator是具体中介者类，实现了抽象中介者接口，并通过协调各个同事对象来实现协作行为。
2
Colleague是抽象同事类，定义了同事对象的接口，并包含一个中介者对象的引用，用于与中介者进行通信。ConcreteColleague1和ConcreteColleague2是具体同事类，分别实现了抽象同事类的接口。
3
在测试类MediatorPatternExample中，创建了具体中介者对象和具体同事对象，并将同事对象的引用传递给中介者对象。然后，通过同事对象调用sendMessage方法发送消息，中介者对象根据通信规则进行处理，并将消息转发给目标同事对象。最后，目标同事对象接收到消息并进行处理。
输出结果
ConcreteColleague2 received message: Hello from colleague1
ConcreteColleague1 received message: Hi from colleague2
以上示例演示了中介者模式的基本实现，通过中介者对象实现了对象之间的松耦合，实现了对象之间的通信。总结
总结起来，中介者模式通过将对象之间的通信封装到一个中介者对象中，实现了对象之间的松耦合。它可以减少对象之间的直接依赖，提高系统的灵活性和可维护性。中介者模式适用于对象之间存在复杂的通信逻辑或通信关系呈现网状结构的场景。
享元模式
享元模式（Flyweight Pattern）是一种结构型设计模式，它通过共享对象来减少内存使用和提高性能。在享元模式中，共享的对象被称为享元（Flyweight），而非共享的对象被称为外部状态（Extrinsic State）。
模式结构分析
享元工厂（FlyweightFactory）
负责创建和管理享元对象。它维护一个享元池（Flyweight Pool），用于存储已经创建的享元对象。
享元接口（Flyweight）
声明共享对象的方法，可以接收外部状态作为参数。
具体享元（ConcreteFlyweight）
实现享元接口，实现共享对象的方法。具体享元对象可以被共享和重用。
非共享具体享元（UnsharedConcreteFlyweight）
不可共享的具体享元对象，通常不会被其他对象使用。
客户端（Client）
使用享元模式的对象。它通过享元工厂获取享元对象，并将外部状态传递给享元对象。
工作原理
1
在客户端需要使用享元对象时，首先通过享元工厂获取对象。如果对象已经存在于享元池中，则直接返回该对象；否则，创建一个新的享元对象并加入到享元池中。
2
客户端将外部状态作为参数传递给享元对象，享元对象根据外部状态进行处理，完成相应的操作。
3
客户端可以同时使用多个享元对象，每个对象都可以接收不同的外部状态。
适用场景
1
系统中存在大量相似对象，且这些对象可以共享部分内部状态。
2
对象的创建和销毁频繁，且创建和销毁对象的代价较大。
3
对象的内部状态可以被外部状态替代，且外部状态可以在对象被创建之后进行修改。
优缺点分析
优点
减少内存使用
通过共享对象，减少系统中的对象数量，从而减少内存的使用。
提高性能
通过共享对象，减少对象的创建和销毁次数，提高系统的性能。
简化对象结构
将对象的内部状态和外部状态分离，简化对象的结构。
缺点：
对象共享可能导致线程安全问题
如果多个线程同时访问共享对象，并修改其外部状态，可能会导致线程安全问题。
需要额外的管理机制
为了确保对象的共享和重用，需要额外的管理机制来维护享元池，增加了系统的复杂性。
Java程序示例
// 享元接口
public interface Flyweight {
void operation(String externalState);
}
// 具体享元
public class ConcreteFlyweight implements Flyweight {
private String internalState;
public ConcreteFlyweight(String internalState) {
this.internalState = internalState;
}
@Override
public void operation(String externalState) {
System.out.println("Internal state: " + internalState);
System.out.println("External state: " + externalState);
}
}
// 享元工厂
public class FlyweightFactory {
private Map<String, Flyweight> flyweights = new HashMap<>();
public Flyweight getFlyweight(String key) {
if (flyweights.containsKey(key)) {
return flyweights.get(key);
} else {
Flyweight flyweight = new ConcreteFlyweight(key);
flyweights.put(key, flyweight);
return flyweight;
}
}
}
// 客户端
public class Client {
public static void main(String[] args) {
FlyweightFactory factory = new FlyweightFactory();
Flyweight flyweight1 = factory.getFlyweight("key1");
flyweight1.operation("state1");
Flyweight flyweight2 = factory.getFlyweight("key2");
flyweight2.operation("state2");
Flyweight flyweight3 = factory.getFlyweight("key1");
flyweight3.operation("state3");
}
}程序分析
在上述示例中，享元模式通过共享具有相同内部状态的对象来减少内存使用。FlyweightFactory负责创建和管理享元对象，ConcreteFlyweight实现了享元接口，并可以被共享和重用。客户端通过享元工厂获取享元对象，并将外部状态作为参数传递给享元对象。
解释器模式
解释器模式是一种行为型设计模式，它提供了一种解释一个语言的方式，用于解析和执行特定的文法规则。该模式将一个语言表示为一个解释器，该解释器可以解释语言中的表达式，从而实现特定的行为。
角色分析
抽象表达式（Abstract Expression）
定义了一个抽象的解释操作，所有的具体表达式都继承自该抽象类。
终结符表达式（Terminal Expression）
表示语法中的终结符，即不再进行解释的表达式。
非终结符表达式（Non-terminal Expression）
表示语法中的非终结符，该表达式可以通过递归调用其他表达式来解释。
上下文（Context）
包含解释器需要的一些全局信息。
客户端（Client）
创建和配置解释器，然后调用解释器的解释方法来解释语言中的表达式。
工作原理
1
客户端创建和配置解释器，并将需要解释的语言表达式传递给解释器。
2
解释器根据语法规则，将表达式解释成相应的抽象语法树。
3
客户端调用解释器的解释方法，解释器根据抽象语法树递归地解释表达式，最终得到结果。
优缺点分析
优点
可扩展性
通过增加新的表达式类，可以轻松扩展语言的语法规则。
易于实现语法规则
解释器模式将每个语法规则都封装在一个表达式类中，使得每个规则的实现都相对简单。
易于修改和维护
由于解释器模式将语法规则和表达式分离，因此可以独立地修改和维护每个表达式类。
缺点
复杂性
随着语法规则的增加，解释器模式的复杂性也会增加，维护和理解整个解释器系统可能会变得困难。
性能问题
由于解释器模式需要递归地解释表达式，可能会导致性能问题，特别是处理大型表达式时。
Java程序示例
首先，我们定义抽象表达式接口 Expression，其中包含一个解释方法 interpret：
public interface Expression {
int interpret(Context context);
}然后，我们实现具体的终结符表达式 NumberExpression，它表示一个数字：
public class NumberExpression implements Expression {
private int number;
public NumberExpression(int number) {
this.number = number;
}
@Override
public int interpret(Context context) {
return number;
}
}接下来，我们实现具体的非终结符表达式 AddExpression，它表示两个表达式的相加操作：
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) {
int leftValue = leftExpression.interpret(context);
int rightValue = rightExpression.interpret(context);
return leftValue + rightValue;
}
}接下来，我们定义上下文类 Context，用于存储解释器需要的全局信息：
public class Context {
private Map<String, Integer> variables;
public Context() {
variables = new HashMap<>();
}
public void setVariable(String name, int value) {
variables.put(name, value);
}
public int getVariable(String name) {
return variables.get(name);
}
}最后，我们可以在客户端中使用解释器模式：
public class Client {
public static void main(String[] args) {
// 创建上下文
Context context = new Context();
context.setVariable("x", 10);
context.setVariable("y", 5);
// 创建表达式
Expression expression = new AddExpression(
new NumberExpression(context.getVariable("x")),
new NumberExpression(context.getVariable("y"))
);
// 解释表达式
int result = expression.interpret(context);
System.out.println("Result: " + result); // 输出结果: Result: 15
}
}分析
在上面的示例中，我们创建了一个上下文对象，并设置了两个变量 x 和 y 的值。然后，我们创建了一个表达式对象，该表达式对象表示将变量 x 和 y 相加的操作。最后，我们调用表达式的解释方法，传入上下文对象，得到最终的结果并输出。
总结
解释器模式是一种用于解释和执行特定语言的设计模式。它通过将语言表示为一个解释器，并使用抽象语法树来解释表达式，实现了特定的行为。尽管存在一些缺点，但解释器模式在某些特定场景下仍然是一个有用的设计模式。
访问者模式
访问者模式是一种行为型设计模式，它允许你将算法与一个对象结构分离开来。通过这种方式，可以在不改变对象结构的情况下，向对象结构中添加新的操作。
角色分析
访问者（Visitor）和被访问者（Element）
访问者
定义了一组可以访问不同类型被访问者的方法
被访问者
定义了接受访问者的方法。访问者通过被访问者的接口访问被访问者，并对其进行操作。
优缺点分析
优点
将数据结构与算法分离
访问者模式可以将数据结构与算法分离，使得算法可以独立于数据结构而变化，提高了代码的可维护性和可扩展性。
增加新的操作很容易
当需要增加新的操作时，只需要增加一个新的访问者类即可，不需要修改原有的代码。
增加新的数据结构很困难
当需要增加新的数据结构时，需要修改所有的访问者类，因此增加新的数据结构比较困难。
4
访问者模式符合单一职责原则和开闭原则
缺点
增加新的数据结构比较困难
当需要增加新的数据结构时，需要修改所有的访问者类，因此增加新的数据结构比较困难。
增加新的操作会导致访问者类的数量增加
当需要增加新的操作时，需要增加一个新的访问者类，因此访问者类的数量会增加。
3
导致系统变得复杂，增加了代码的阅读难度。
4
访问者模式需要对数据结构进行抽象，增加了系统的抽象性和理解难度。
总结
访问者模式适用于数据结构相对稳定，但是经常需要增加新的操作的场景，同时访问者模式也需要权衡系统的复杂度和可维护性。
Java程序示例
要求：
为一个图形库添加一个新的功能，即计算图形的面积和周长。我们可以使用访问者模式来实现这个功能。
首先，我们定义一个抽象的图形类（Element），其中包含一个接受访问者的方法 accept()，以及一个抽象的计算面积和周长的方法 calculate()。
abstract class Shape {
public abstract void accept(Visitor visitor);
public abstract void calculate();
}```
### 然后，我们定义两个具体的图形类，圆形和矩形，它们都继承自图形类。
```java
class Circle extends Shape {
private double radius;
public Circle(double radius) {
this.radius = radius;
}
public double getRadius() {
return radius;
}
public void accept(Visitor visitor) {
visitor.visit(this);
}
public void calculate() {
System.out.println("Calculating area and perimeter of circle");
}
}
class Rectangle extends Shape {
private double width;
private double height;
public Rectangle(double width, double height) {
this.width = width;
this.height = height;
}
public double getWidth() {
return width;
}
public double getHeight() {
return height;
}
public void accept(Visitor visitor) {
visitor.visit(this);
}
public void calculate() {
System.out.println("Calculating area and perimeter of rectangle");
}
}接下来，我们定义一个访问者接口（Visitor），其中包含了访问圆形和矩形的方法 visit()。
interface Visitor {
void visit(Circle circle);
void visit(Rectangle rectangle);
}然后，我们实现具体的访问者类（AreaVisitor和PerimeterVisitor），分别用于计算图形的面积和周长。
class AreaVisitor implements Visitor {
public void visit(Circle circle) {
double area = Math.PI * circle.getRadius() * circle.getRadius();
System.out.println("Area of circle: " + area);
}
public void visit(Rectangle rectangle) {
double area = rectangle.getWidth() * rectangle.getHeight();
System.out.println("Area of rectangle: " + area);
}
}
class PerimeterVisitor implements Visitor {
public void visit(Circle circle) {
double perimeter = 2 * Math.PI * circle.getRadius();
System.out.println("Perimeter of circle: " + perimeter);
}
public void visit(Rectangle rectangle) {
double perimeter = 2 * (rectangle.getWidth() + rectangle.getHeight());
System.out.println("Perimeter of rectangle: " + perimeter);
}
}最后，我们可以在客户端代码中使用访问者模式来计算图形的面积和周长。
public static void main(String[] args) {
List<Shape> shapes = new ArrayList<>();
shapes.add(new Circle(5));
shapes.add(new Rectangle(3, 4));
Visitor areaVisitor = new AreaVisitor();
Visitor perimeterVisitor = new PerimeterVisitor();
for (Shape shape : shapes) {
shape.accept(areaVisitor);
shape.accept(perimeterVisitor);
}
}程序分析
在上面的代码中，我们创建了一个包含圆形和矩形的列表，并分别使用面积访问者和周长访问者来计算每个图形的面积和周长。
总结
访问者模式可以帮助我们将算法与对象结构分离开来，提高代码的可维护性和可扩展性。在实现访问者模式时，需要定义一个抽象的被访问者类和访问者接口，然后实现具体的被访问者类和访问者类。在客户端代码中，可以使用访问者来访问被访问者，并对其进行操作。