设计模式

📅 时间: 17:22
🌤️ 天气: 银川 19~31℃ 晴

袨服华妆着处逢，六街灯火闹儿童。

— 元好问 · 《京都元夕》

面向对象设计原则概述

常见的 面向对象设计五大基本原则（SOLID）：

类之间的关系:

1

开闭原则

• 开闭原则由Bertrand Meyer于1988年提出
• 在开闭原则的定义中，软件实体可以是一个软件模块、一个由多个类组成的局部结构或一个独立的类
• 开闭原则是指软件实体应尽量在不修改原有代码的情况下进行扩展
• 
• 

简单工厂模式

将对象的创建和对象本身业务处理分离可以降低系统的耦合度，使得两者修改起来都相对容易 在调用工厂类的工厂方法时，由于工厂方法是静态方法，使用起来很方便，可通过工厂类类名直接调用，只需要传入一个简单的参数即可，无须知道对象的创建细节 问题：工厂类的职责相对过重，增加新的产品需要修改工厂类的判断逻辑，违背开闭原则 简单工厂模式就是定义一个专门的类（工厂），这个类负责创建其他类的实例。你只需要告诉这个工厂你想要什么，它就会帮你“生产”出来，而你不用关心具体是怎么生产的。 简单工厂模式，就像一个代购。 你（客户端）想要一个东西（比如：披萨），但你不想自己动手做。 这时，你就找到一个专门做披萨的代购（工厂）。 你告诉代购：“我要海鲜披萨。” 代购就把海鲜披萨做好给你。 你告诉代购：“我要培根披萨。” 代购就把培根披萨做好给你。 核心思想就三句话：

• 一个专门的“生产线” (工厂类)。
• 你告诉它你想要什么 (传入参数)。
• 它把你要的东西“生产”出来给你 (返回实例)。

工厂方法模式

简单工厂模仿违反==开闭原则==(扩展尽量不修改)

核心要点

1. 分工明确：每个产品都有自己的专属工厂，职责单一。
2. 易于扩展（开闭原则）：新增一种产品，只需增加一个新产品类和一个新的专属工厂，不改动现有代码。
3. 增加了类的数量和复杂度：产品一多，工厂类也会跟着多起来，代码结构会更复杂。 缺点:

• 类多且复杂： 每增加一种产品，你不仅要加产品类，还要加对应的工厂类，导致系统中的类数量暴增，整体结构更复杂。
• 客户端依然要选工厂： 客户端代码虽然不用直接创建产品，但它仍需要知道并选择具体是哪个工厂来创建产品，没有完全解除与具体类的耦合。 一句话总结： 工厂方法模式就是“一个产品一个工厂”，实现产品创建的解耦和系统扩展性。

单例模式

单例模式的要点有三个：

• 某个类只能有一个实例
• 必须自行创建这个实例
• 必须自行向整个系统提供这个实例
• 

饿汉式单例类

public class EagerSingleton { 
    private static final EagerSingleton instance = new EagerSingleton(); 
    private EagerSingleton() { } 
 
    public static EagerSingleton getInstance() {
        return instance; 
    }
}

饿汉式： 程序启动就创建，简单直接，绝对线程安全，但可能浪费资源。

懒汉式单例类

public class LazySingleton {
    // 1. 私有化构造函数
    private LazySingleton() {}

    // 2. 声明实例，但不立即创建
    private static LazySingleton instance = null;

    // 3. 提供公共静态方法获取实例
    public static LazySingleton getInstance() {
        // 第一次调用时才创建实例
        if (instance == null) {
            instance = new LazySingleton();
        }
        return instance;
    }
}

懒汉式： 用到才创建，节约资源，但需要额外处理线程安全（通常会牺牲一些性能）。

饿汉式单例类：无须考虑多个线程同时访问的问题；调用速度和反应时间优于懒汉式单例；资源利用效率不及懒汉式单例；系统加载时间可能会比较长 懒汉式单例类：实现了延迟加载；必须处理好多个线程同时访问的问题；需通过双重检查锁定等机制进行控制，将导致系统性能受到一定影响

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

synchronized

桥接模式：

把“变化”拆开，再灵活组装

桥接模式就像一座桥，它的作用是把两个经常独立变化的东西（维度）分离开来，然后让你能自由地组合它们。

理解 想象你要做一杯饮品：有不同的口味（咖啡、茶、果汁），和不同的杯型（大杯、中杯、小杯）。

没有桥接模式，你可能会做：

• 大杯咖啡
• 中杯咖啡
• 小杯咖啡
• 大杯茶
• 中杯茶
• …

这样，每增加一个口味或一个杯型，你的组合就会爆炸式增长。

有了桥接模式，你会怎么做？

1. 把“口味”和“杯型”这俩维度拆开：
   • 口味（抽象部分）： 定义一个“饮品”接口，有咖啡、茶、果汁等具体实现。
   • 杯型（实现部分）： 定义一个“杯子”接口，有大杯、中杯、小杯等具体实现。
2. 用“桥”连接： 在“饮品”接口里，不再直接绑定具体的杯型，而是持有一个“杯子”的引用。这个引用就是我们的“桥”。

现在，你想要大杯咖啡，就拿咖啡（口味）和大杯（杯型）组合；想要小杯果汁，就拿果汁和小杯组合。

核心思想

• 分离： 把一个事物的**“高层抽象”（做什么）** 和它的**“底层实现”（怎么做）** 完全分离开来。
• 桥接： 高层抽象通过持有一个对底层实现的引用来“连接”它们。

优点 & 缺点

• 优点：

  • 超级灵活： 两个维度可以独立变化和扩展，互相不影响。
  • 减少代码： 避免了组合爆炸导致的类数量过多和代码冗余。

• 缺点：

  • 初期理解复杂： 刚开始看这种模式，可能会觉得多了一层抽象，有点绕。 一句话总结： 桥接模式就是**“解耦两个独立变化的维度**，让它们可自由组合和扩展”**。

• 现需要提供大中小3种型号的画笔，能够绘制5种不同颜色，如果使用蜡笔，我们需要准备3*5=15支蜡笔，也就是说必须准备15个具体的蜡笔类。而如果使用毛笔的话，只需要3种型号的毛笔，外加5个颜料盒，用3+5=8个类就可以实现15支蜡笔的功能。本实例使用桥接模式来模拟毛笔的使用过程。

• 

• 

• 桥接模式包含如下角色：

• Abstraction：抽象类

• RefinedAbstraction：扩充抽象类

• Implementor：实现类接口

• ConcreteImplementor：具体实现类

组合模式

组合模式包含如下角色：

• Component: 抽象构件

• Leaf: 叶子构件

• Composite: 容器构件

• 

外观模式

外观模式包含如下角色：

• Facade: 外观角色
• SubSystem:子系统角色

public class Client { // 客户端类，可以是程序的任何一部分
    public static void main(String[] args) {
        // 1. 创建 Facade 类的实例（也就是那个“总开关”或“前台接待”）
        Facade facade = new Facade();

        // 2. 调用 Facade 实例的 method() 方法
        // 这一步就触发了 Facade 内部对 SubSystemA, SubSystemB, SubSystemC 的一系列调用
        System.out.println("客户端开始调用外观模式的简化方法...");
        facade.method(); // <--- 这里就是调用！
        System.out.println("外观模式方法调用完成。");
    }
}

// SubSystemA, SubSystemB, SubSystemC 定义：
class SubSystemA {
    public void method() {
        System.out.println("子系统A执行操作。");
    }
}

class SubSystemB {
    public void method() {
        System.out.println("子系统B执行操作。");
    }
}

class SubSystemC {
    public void method() {
        System.out.println("子系统C执行操作。");
    }
}

// Facade 类
public class Facade {
    private SubSystemA obj1 = new SubSystemA();
    private SubSystemB obj2 = new SubSystemB();
    private SubSystemC obj3 = new SubSystemC();

    public void method() {
        System.out.println("Facade: 协调子系统操作开始。");
        obj1.method();
        obj2.method();
        obj3.method();
        System.out.println("Facade: 协调子系统操作结束。");
    }
}

命令模式

命令模式包含如下角色：

• Command: 抽象命令类

• ConcreteCommand: 具体命令类

• Invoker: 调用者

• Receiver: 接收者

• execute() 是命令的执行入口，它定义了“做什么”。

• state : 是命令的状态或参数，它定义了“用什么（数据）来做”或者“做了什么（以便撤销）”。

• 模式分析

• 将请求发送者和接收者完全解耦

• 发送者与接收者之间没有直接引用关系

• 发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求

• 命令模式的本质是对请求进行封装

• 一个请求对应于一个命令，将发出命令的责任和执行命令的责任分开

• 电视机是请求的接收者，遥控器是请求的发送者，遥控器上有一些按钮，不同的按钮对应电视机的不同操作。抽象命令角色由一个命令接口来扮演，有三个具体的命令类实现了抽象命令接口，这三个具体命令类分别代表三种操作：打开电视机、关闭电视机和切换频道。显然，电视机遥控器就是一个典型的命令模式应用实例。

•