23种设计模式与UML类图实战指南
简介：设计模式是软件开发中解决常见问题的有效方案，而UML提供了一种统一的图形化表示方法，用于清晰展示类、对象和它们之间的关系。本书详细介绍了23种经典设计模式，涵盖了创建型、结构型和行为型模式，每个模式都辅以UML类图，帮助开发者提高代码质量，并促进团队间的有效沟通。
1. 设计模式概述
设计模式作为软件开发中的重要概念，其重要性不言而喻。它提供了一种在一定上下文中针对常见问题的标准解决方案，能够帮助开发者避免重蹈覆辙，提高代码质量和开发效率。
1.1 设计模式的定义与重要性
设计模式是面向对象软件设计中，可复用的、经过验证的最佳实践。它们是经验丰富的开发人员，在面对重复出现的设计问题时，总结出的解决方案模板。通过学习和运用设计模式，我们能够创建出更加灵活、可维护和可扩展的软件系统。
1.2 设计模式的分类
设计模式主要分为三大类：创建型模式、结构型模式和行为型模式。创建型模式关注对象的创建过程，结构型模式关注对象与类的组织结构，而行为型模式关注对象之间的通信。每种类型下都有其特定的设计模式，它们各自解决了软件设计中的特定问题。
1.3 设计模式的实践意义
在实际开发中，设计模式不仅提供了解决问题的方案，还促进了团队间的沟通。它为开发者提供了一个共享的语言和知识库，使项目中的问题和解决方案都能被更好地理解和执行。此外，熟练掌握和运用设计模式，对于个人技术成长以及职业发展都有极大的帮助。
2. UML类图介绍
2.1 UML类图基础
2.1.1 UML类图的定义
统一建模语言（UML）类图是面向对象分析和设计中的一种静态结构图，用于可视化系统的蓝图。通过类图，可以展示系统中类的属性、方法以及类之间的各种静态关系，比如继承、依赖、关联、聚合和组合等。类图是软件开发人员在设计阶段用于讨论软件结构的重要工具，它帮助开发者捕捉设计细节，并允许团队成员之间就系统的实现达成共识。
2.1.2 UML类图中的基本元素
在UML类图中，基本元素主要包括类、接口、依赖关系、关联关系、聚合关系和组合关系等。每个类由三个部分组成：类名、属性和操作（方法），并且可以通过接口来实现多继承，通过关系来展示类与类之间的联系。
- 类：用矩形表示，分为三部分，顶部是类名，中间是属性，底部是方法。
- 接口：用一个带有名称的圆角矩形表示，然后通过虚线连接类。
- 依赖关系：用带有箭头的虚线表示，箭头指向被依赖的元素。
- 关联关系：用实线表示，并且可以有箭头来表明导航性，或者在关联的末端标明多重性（比如1..*表示一个到多个）。
- 聚合关系：用空心菱形加实线表示，表示整体和部分的关系，但部分可以独立于整体存在。
- 组合关系：用实心菱形加实线表示，强调的是部分与整体的紧密联系，部分的生命周期由整体决定。
2.2 UML类图的高级应用
2.2.1 关联、聚合和组合的区分与应用
关联、聚合和组合是描述类之间关系的三种方式，它们在UML类图中通过不同的图形表示，各有其特殊的含义和应用。
- 关联关系代表了两个类之间的一种连接，通常通过实线来表示。它可以有方向，表示导航性，以及通过在连接线末端标注来指示多重性。例如，一个
Car类可以关联多个Wheel类的实例。
classDiagram
class Car
class Wheel
Car "1" -- "4" Wheel : has~
- 聚合关系用于表示整体和部分的“has-a”关系，它强调的是整体与部分的弱连接。在聚合关系中，部分可以独立于整体存在。例如，
Library类和Book类之间存在聚合关系。
classDiagram
class Library
class Book
Library o-- "many" Book : contains~
- 组合关系是更强的“has-a”关系，其中部分的生命周期完全由整体来控制。组合关系用实心菱形表示。例如，在一个
Department类中包含多个Employee实例，这些Employee的创建和销毁都由Department控制。
classDiagram
class Department
class Employee
Department *-- "many" Employee : employs~
2.2.2 依赖关系和实现关系的使用场景
依赖关系和实现关系是UML类图中表示类之间依赖和实现接口的两种连接方式。
- 依赖关系使用带箭头的虚线表示，它表示一个类使用或依赖另一个类的接口，但不一定是直接的类之间的关系。例如，
ClassA依赖于InterfaceB。
classDiagram
class InterfaceB
class ClassA
ClassA ..> InterfaceB : implements~
- 实现关系通常用于接口和实现类之间，用带箭头的虚线表示。在实现关系中，接口是目标，而实现类是源。例如，
ConcreteClass实现了InterfaceB。
classDiagram
class InterfaceB
class ConcreteClass
ConcreteClass ..|> InterfaceB : implements~
在设计软件时，理解这些关系的不同可以帮助我们构建出更加模块化、可复用和易于维护的系统。正确的使用关联、聚合、组合、依赖和实现关系，可以让系统的组件更加清晰，进而提高软件的整体质量。
3. 创建型模式详述
创建型模式是设计模式的一个重要类别，主要关注如何创建对象，而不是对象的结构和属性。这五种创建型模式分别是：单例模式、原型模式、工厂方法模式、抽象工厂模式和建造者模式。每种模式解决不同的问题，在实际开发中具有广泛的应用。
3.1 单例模式的实现与应用
单例模式是一种常见的设计模式，其目的是确保一个类只有一个实例，并提供一个全局访问点。
3.1.1 单例模式的概念与原理
单例模式的主要特点就是确保一个类只有一个实例，并提供一个全局访问点。它通常通过一个私有构造函数、一个私有静态变量以及一个公有静态函数来实现。私有构造函数确保了不能通过构造函数来创建对象实例，只能通过公有静态函数返回唯一的私有静态变量。
单例模式的实现主要分为饿汉式和懒汉式两种。饿汉式在类加载时就完成初始化，懒汉式则在第一次被引用时进行初始化。
3.1.2 单例模式的UML类图与代码实现
UML类图
Java代码实现
public class Singleton {
// 私有静态实例
private static Singleton instance = new Singleton();
// 私有构造函数，防止被外部实例化
private Singleton() {}
// 提供一个全局访问点，返回实例对象
public static Singleton getInstance() {
return instance;
}
// 业务方法
public void businessMethod() {
// ...
}
}
分析说明
在上述代码中， Singleton 类的构造函数是私有的，因此不能在类的外部通过 new 关键字创建 Singleton 类的实例。同时， getInstance 方法是公有的静态方法，因此可以通过 Singleton.getInstance() 获取 Singleton 类的唯一实例。这种方式是饿汉式单例模式的实现。
3.2 原型模式的实现与应用
原型模式通过复制现有的实例来创建新的实例，而不是新建实例。
3.2.1 原型模式的原理与特点
原型模式是一种创建型设计模式，用于创建重复的对象，同时又能保证性能。这种模式实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，原型模式非常有用。
原型模式的关键是 Cloneable 接口，需要克隆的对象必须实现这个接口。克隆分为浅克隆和深克隆，浅克隆只复制对象的引用，而深克隆复制对象本身及其引用的对象。
3.2.2 原型模式的UML类图与代码实现
UML类图
Java代码实现
public class Prototype implements Cloneable {
public int data;
public Prototype clone() throws CloneNotSupportedException {
return (Prototype) super.clone();
}
// 克隆构造函数
private Prototype(Prototype other) {
this.data = other.data;
}
public static Prototype newPrototype(Prototype other) {
return new Prototype(other);
}
}
分析说明
在上述代码中， Prototype 类实现了 Cloneable 接口，这允许 Prototype 的实例被克隆。通过调用 clone() 方法，我们可以创建 Prototype 的一个新的实例，该实例在内存中是原实例的一个独立拷贝。这种方式是原型模式的实现。
在实践中，使用原型模式可以避免重复的初始化操作，从而提高创建对象的效率。在多线程环境下，复制对象比获取锁来同步访问原始对象更安全和高效。
3.3 工厂方法模式的实现与应用
工厂方法模式定义了一个创建对象的接口，但让子类决定实例化哪一个类。
3.3.1 工厂方法模式的定义与结构
工厂方法模式又称为多态性工厂模式，属于创建型模式。它的核心工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去完成。工厂方法模式中的工厂类与产品类往往可以形成一个等级结构。
工厂方法模式包含以下几个角色：
- Creator （抽象工厂）：声明工厂方法，返回 Product 类型的对象。
- ConcreteCreator （具体工厂）：实现工厂方法，该方法返回一个 ConcreteProduct 的实例。
- Product （抽象产品）：定义产品的接口。
- ConcreteProduct （具体产品）：实现或继承 Product 接口，并具体实现产品。
3.3.2 工厂方法模式的UML类图与代码实现
UML类图
Java代码实现
interface Product {
void use();
}
class ConcreteProductA implements Product {
public void use() {
// 实现具体逻辑
}
}
class ConcreteProductB implements Product {
public void use() {
// 实现具体逻辑
}
}
abstract class Creator {
public abstract Product factoryMethod();
}
class ConcreteCreator extends Creator {
public Product factoryMethod() {
return new ConcreteProductA();
}
}
分析说明
在上述代码中，我们定义了一个 Product 接口和两个实现了该接口的 ConcreteProduct 类。 Creator 是一个抽象类，定义了一个 factoryMethod() 方法，该方法在 ConcreteCreator 类中被重写，并返回一个 ConcreteProduct 的实例。
工厂方法模式的优点是增加了系统的可扩展性和开放性，缺点是每个具体产品类都要对应的工厂类，增加了系统结构的复杂性。
3.4 抽象工厂模式的实现与应用
抽象工厂模式是一种创建型设计模式，用于创建一系列相关或依赖对象的接口，无需指定这些对象的具体类。
3.4.1 抽象工厂模式的原理与优势
抽象工厂模式提供了一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。抽象工厂模式通常用于创建一系列的对象，这些对象有共同的主题，但属于不同的产品族。
抽象工厂模式的主要优势在于它能够隔离具体类的生成，当一个产品族中的多个对象被设计成一起工作时，抽象工厂模式可以保证客户端始终只使用同一个产品族中的对象。这有助于将代码与具体的产品实现细节分离。
3.4.2 抽象工厂模式的UML类图与代码实现
UML类图
Java代码实现
interface AbstractFactory {
AbstractProductA createProductA();
AbstractProductB createProductB();
}
interface AbstractProductA {
void useA();
}
interface AbstractProductB {
void useB();
}
class ConcreteFactory1 implements AbstractFactory {
public AbstractProductA createProductA() {
return new ConcreteProductA1();
}
public AbstractProductB createProductB() {
return new ConcreteProductB1();
}
}
class ConcreteFactory2 implements AbstractFactory {
public AbstractProductA createProductA() {
return new ConcreteProductA2();
}
public AbstractProductB createProductB() {
return new ConcreteProductB2();
}
}
分析说明
在上述代码中，我们定义了 AbstractFactory 接口，它声明了用于创建两个产品族成员的方法。然后我们定义了两个具体的工厂类 ConcreteFactory1 和 ConcreteFactory2 ，它们分别实现了 AbstractFactory 接口，并创建了与它们相关的产品族对象。
抽象工厂模式的一个典型应用是JDBC驱动程序，它允许数据库制造商提供适用于多种数据库的产品族。
3.5 建造者模式的实现与应用
建造者模式是一种创建型设计模式，提供了一种创建对象的最佳方式。
3.5.1 建造者模式的组成与实现细节
建造者模式将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。它是一种对象创建型模式，通常使用链式调用来表示复杂对象的构建过程。
建造者模式主要包含以下角色：
- Builder （建造者）：为创建一个 Product 对象的各个部件指定抽象接口。
- ConcreteBuilder （具体建造者）：实现 Builder 接口，构造和装配各个部件。
- Director （指挥者）：构建一个使用 Builder 接口的对象。
- Product （产品）：表示被构造的复杂对象。 ConcreteBuilder 创建该产品的内部表示并定义它的装配过程。
3.5.2 建造者模式的UML类图与代码实现
UML类图
Java代码实现
class Product {
private String partA;
private String partB;
public void setPartA(String partA) {
this.partA = partA;
}
public void setPartB(String partB) {
this.partB = partB;
}
// ...
}
abstract class Builder {
protected Product product = new Product();
public abstract void buildPartA();
public abstract void buildPartB();
public Product getResult() {
return product;
}
}
class ConcreteBuilder extends Builder {
public void buildPartA() {
product.setPartA("A");
}
public void buildPartB() {
product.setPartB("B");
}
}
class Director {
public void construct(Builder builder) {
builder.buildPartA();
builder.buildPartB();
}
}
分析说明
在上述代码中， Builder 是一个抽象类，它定义了构建产品的接口。 ConcreteBuilder 类继承了 Builder ，并具体实现构建产品的过程。 Director 类控制整个构建过程，它接受一个 Builder 对象，并指导其构建过程。
建造者模式适合创建那些属性相互依赖或创建过程复杂的对象。它避免了在构建过程中出现错误，同时提高了代码的可读性和安全性。
以上内容展示了创建型模式中的五种模式：单例模式、原型模式、工厂方法模式、抽象工厂模式和建造者模式。每种模式都用UML类图和Java代码来详尽地阐述了其实现和应用，可以帮助开发者在遇到相关问题时找到合适的解决方案。
4. 结构型模式详述
在软件工程领域，结构型模式关注的是软件设计中的类和对象的组织。这些模式通过继承、接口和组合等机制，构建系统更大的结构。本章将深入探讨五种结构型设计模式：适配器模式、桥接模式、组合模式、装饰模式和外观模式。每一个模式都旨在解决特定的结构问题，同时提供更清晰、灵活和可维护的代码组织方式。
4.1 适配器模式的实现与应用
4.1.1 适配器模式的适用场景与效果
适配器模式（Adapter Pattern）是一种结构型设计模式，主要用于将一个类的接口转换成客户期望的另一个接口。模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
适配器模式特别适用于以下场景：
- 当你想要使用一个已经存在的类，而它的接口不符合你的需求时；
- 当你想要创建一个可以复用的类，该类可以与不相关的或者未来不知道的类一起工作时；
- 在一些遗留系统中，你想创建一个统一的接口来与这些系统的各个不同版本交互。
适配器模式的主要效果如下：
- 它可以帮助实现客户端和目标接口的解耦，实现对多个类的兼容性；
- 通过适配器，代码复用变得更加简单，因为你可以创建一个通用的适配器来适配不同的类；
- 它保持了每个类的封装性。
4.1.2 适配器模式的UML类图与代码实现
以下是适配器模式的UML类图表示：
classDiagram
class Target {
<<interface>>
operation()
}
class Client
class Adaptee {
specificOperation()
}
class Adapter {
<<interface>>
operation()
specificOperation()
}
Client --> Target : <<uses>>
Target <|-- Adapter : realizes
Adapter o-- Adaptee : <<uses>>
在这个类图中， Target 是客户期望的接口， Client 是使用 Target 接口的类， Adaptee 是已存在的不兼容接口的类， Adapter 是适配器类，实现了 Target 接口，并且内部使用了 Adaptee 。
接下来，我们将通过代码示例来实现适配器模式：
// Target 接口定义
public interface Target {
void operation();
}
// Adaptee 类定义
class Adaptee {
void specificOperation() {
System.out.println("Adaptee specific operation");
}
}
// Adapter 类实现 Target 接口，内部使用 Adaptee
class Adapter implements Target {
private Adaptee adaptee = new Adaptee();
// 实现 Target 的 operation 方法，实际上是对 Adaptee 的封装
public void operation() {
adaptee.specificOperation();
System.out.println("Adapter calls specificOperation of Adaptee");
}
}
// 客户端代码使用 Target 接口
public class Client {
public static void main(String[] args) {
Target target = new Adapter();
target.operation();
}
}
在这个 Java 代码示例中， Client 使用 Target 接口。 Adapter 类实现了 Target 接口，并将 Adaptee 的行为适配到 Target 接口。这样， Client 可以通过 Target 接口来间接调用 Adaptee 的功能，实现了接口的适配。
适配器模式通过这样的包装方式，允许原本不兼容的对象能够一起工作。这在软件开发中是非常常见和有用的，特别是当系统中需要整合多个模块、库或框架时。适配器模式通过引入一个中间层，使得原始类能够在新的系统中得到重用，而不需要修改原有的类代码。
5. 行为型模式详述
行为型设计模式关注对象之间的通信，实现软件系统的封装性、灵活性以及可复用性。本章将深入探讨行为型模式的分类及其在实际开发中的应用，并通过UML类图和代码实现来具体解析每种模式的工作原理。
5.1 责任链模式的实现与应用
5.1.1 责任链模式的解耦与事件处理
责任链模式通过定义一系列的请求处理者，并将请求沿着链传递，直到被某个处理者处理。这种模式的实现可以有效地解耦请求的发送者和接收者，增强系统的灵活性和扩展性。
责任链模式的核心思想是将请求发送者和接收者之间的直接耦合关系转化为链式间接耦合关系。这不仅使得系统中的对象能够灵活地处理请求，而且还可以动态地指定请求的处理顺序。
5.1.2 责任链模式的UML类图与代码实现
在责任链模式中，主要涉及到两个角色：处理者(Handler)和具体处理者(ConcreteHandler)。下面是一个处理请求责任链的UML类图和代码实现。
UML类图
classDiagram
class Handler {
<<abstract>>
setNext(Handler) Handler
handle(Request) void
}
class ConcreteHandlerA {
handle(Request) void
}
class ConcreteHandlerB {
handle(Request) void
}
class Client {
setHandlerChain() Handler
}
Handler <|-- ConcreteHandlerA
Handler <|-- ConcreteHandlerB
Client --> Handler : uses
代码实现
// Handler.java
public abstract class Handler {
protected Handler successor;
public void setSuccessor(Handler successor) {
this.successor = successor;
}
public abstract void handleRequest(Request request);
}
// ConcreteHandlerA.java
public class ConcreteHandlerA extends Handler {
@Override
public void handleRequest(Request request) {
if (canHandle(request)) {
// 处理请求
} else if (successor != null) {
successor.handleRequest(request);
}
}
private boolean canHandle(Request request) {
// 判断能否处理请求
return false;
}
}
// Client.java
public class Client {
public static Handler setHandlerChain() {
Handler handlerA = new ConcreteHandlerA();
Handler handlerB = new ConcreteHandlerB();
handlerA.setSuccessor(handlerB);
return handlerA;
}
}
代码逻辑的逐行解读
-
Handler.java中定义了一个抽象类Handler，包含successor成员变量用于指向下一个处理者，以及setSuccessor和handleRequest抽象方法。 -
ConcreteHandlerA.java中定义了具体的处理者ConcreteHandlerA，继承自抽象类Handler。实现了handleRequest方法，用于处理请求。当无法处理请求时，会调用successor的handleRequest方法继续请求链传递。 -
Client.java中创建了责任链，并返回了责任链的起始处理者。在Client类中，setHandlerChain方法用于设置并返回责任链。
责任链模式适用于不希望发送者与接收者耦合的情况，如事件处理、日志记录、工作流审批等场景。通过责任链模式的使用，可以实现请求的灵活处理和系统功能的动态扩展。
在接下来的章节中，我们将继续深入了解其他行为型模式，并逐一分析它们的UML类图和代码实现。
6. UML类图与设计模式结合使用
在软件开发领域中，设计模式与UML类图是提高软件质量的重要工具。本章将探讨如何将UML类图与设计模式结合使用，以提高代码的可复用性、可维护性和可扩展性，并改进团队沟通效率。
6.1 提高代码的可复用性、可维护性、可扩展性
设计模式提供了经过验证的解决方案来应对软件设计中常见的问题。UML类图则是一种可视化工具，用于表示系统中类的设计和它们之间的关系。将二者结合使用，可以使设计更加直观、易于理解和实施。
6.1.1 设计模式与UML类图的组合优势
结合使用设计模式与UML类图能够带来以下优势：
- 直观性 ：UML类图为设计模式的结构提供了直观的视图，帮助开发者快速理解设计意图。
- 标准化 ：通过UML标准化设计模式的应用，可以创建出符合特定模式规范的代码结构。
- 复用性增强 ：设计模式的复用性可以通过UML类图的模板来进一步增强，因为它们都是经过实践检验的最佳实践。
- 易维护 ：UML类图可以简化代码结构，使维护变得更加直观和简单。
6.1.2 实际案例分析
我们可以通过一个案例来展示设计模式与UML类图结合使用的实际效果。考虑一个在线购物平台，它使用了工厂方法模式来创建不同类型的订单对象。
classDiagram
class OrderFactory {
+createOrder(type: String): Order
}
class Order {
+calculateTotal(): Double
}
class StandardOrder {
+calculateTotal(): Double
}
class PremiumOrder {
+calculateTotal(): Double
}
OrderFactory "1" *-- "0..*" Order : creates >
Order <|-- StandardOrder
Order <|-- PremiumOrder
在上述UML类图中， OrderFactory 是一个工厂类，负责根据类型创建对应的订单实例。 Order 是一个抽象类，定义了订单的基本行为，如 calculateTotal 。 StandardOrder 和 PremiumOrder 分别继承自 Order ，代表不同类型的具体订单。
通过这种设计，我们可以轻松地扩展新的订单类型，而无需修改工厂类的代码。只需增加新的订单子类并实现 calculateTotal 方法即可。这种设计显著提升了代码的可扩展性和可维护性。
6.2 改进团队沟通效率
设计模式和UML类图在项目开发中的另一个重要应用是改进团队的沟通效率。
6.2.1 设计模式的标准化通信作用
设计模式提供了一种标准化的方式来描述软件组件和它们之间的关系，这有助于团队成员之间的沟通：
- 共同的语言 ：团队成员可以使用设计模式的术语作为共同语言，减少误解和沟通成本。
- 快速决策 ：对常见的设计问题有了共同的理解，团队可以快速作出决策。
- 提高效率 ：标准化的设计模式可以加速项目开发过程，因为团队不需要每次都重新发明解决方案。
6.2.2 UML类图在文档和沟通中的重要性
UML类图在项目文档和沟通中的作用也不可忽视：
- 清晰的表达 ：UML类图能够清晰地表达系统架构和设计决策，使项目文档更加易读。
- 辅助讨论 ：在讨论设计时，使用UML类图可以帮助团队成员更快地理解和参与到问题的讨论中。
- 记录变更 ：随着项目进展，UML类图可以记录设计的变更，作为版本控制的辅助工具。
以一个网站后台管理系统为例，UML类图可以用来展示用户权限管理的结构，帮助团队理解权限如何在系统中流动和被管理。
classDiagram
class User {
+username: String
+password: String
}
class Role {
+name: String
+permissions: List~Permission~
}
class Permission {
+name: String
+description: String
}
class UserRole {
+user: User
+role: Role
}
User "1" *-- "1" UserRole : has >
Role "1" *-- "0..*" Permission : has >
通过这张UML类图，团队成员可以直观地了解用户、角色、权限之间的关系，并且讨论如何实现权限控制的逻辑。
通过以上分析，我们可以看出，将设计模式与UML类图结合使用能够显著提升项目的质量和开发效率。这种结合不仅有助于提高代码的质量，还能够加强团队之间的沟通，确保项目的顺利进行。
简介：设计模式是软件开发中解决常见问题的有效方案，而UML提供了一种统一的图形化表示方法，用于清晰展示类、对象和它们之间的关系。本书详细介绍了23种经典设计模式，涵盖了创建型、结构型和行为型模式，每个模式都辅以UML类图，帮助开发者提高代码质量，并促进团队间的有效沟通。
北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台
更多推荐
17
0- 0
已为社区贡献15条内容
所有评论(0)