[设计模式]1_设计模式概览

摘要：设计模式原则、设计模式的划分与简要概括，怎么使用重构获得设计模式并改善代码的坏味道。

本篇作概览与检索用，后续结合源码进行具体模式深入学习。

目录

1、设计模式原理

核心原则（语言无关）

本质原理图

原则关联矩阵

2、设计模式分类

1. 创建型模式

2. 结构型模式

3. 行为型模式

3、重构获得模式

重构关键技法

静态——>动态

早绑定——>晚绑定

继承——>组合

编译时依赖——>运行时依赖

紧耦合——>松耦合

生产设计的原则倾向

什么样的代码算是好的代码呢？同好的服务一样（此处强行关联 《[微服务设计]1_微服务》）——功能正确、高效、可维护性强、健壮抗压、写作流畅。也可以总的来说，低耦合高内聚的高质量可维护代码，就是好的代码。

那么，有没有一些规范可以遵循的呢？

有的，设计模式就是这样的指导规范。

1、设计模式原理

核心原则（语言无关）

众所周知，设计模式有一些原则可以遵守：

单一职责：一个模块/类应仅负责一个职责。降低模块间耦合，提升可维护性。

里氏替换：所有引用基类的地方必须能透明地使用子类对象。这样利于抽象与类型封装。

开放封闭：对修改封闭、对拓展开放。

迪米特：减少对象间不必要的直接交互，降低耦合，提高模块独立性。

接口隔离原则：客户端不应依赖未使用的接口。将大接口拆分为小的、高内聚的接口。

依赖倒置：高层模块不应该依赖于底层模块，转换为二者都依赖于抽象。具体来说就是针对接口编程，而不是针对具体实现，这样可以减少各部分依赖关系，这也面向对象设计的亮点。

还有优先使用对象组合而不是类继承等等……

总的来说：从通用核心原则到实现层原则再到构造策略相关的原则，均追求代码模块的低耦合高内聚，降低复杂度。

本质原理图

原则关联矩阵

2、设计模式分类

Gang of Four（四人组，GOF） 在经典著作《设计模式：可复用面向对象软件的基础》中提出的23种设计模式的分类方式，按功能和用途分为三大类——创建型、结构型、行为型。

1. 创建型模式

目的：解决对象的创建问题，封装实例化逻辑，提升代码复用性和灵活性。

核心思想：将对象的创建与使用解耦，通过统一接口或模板控制对象实例化过程。

2. 结构型模式

目的：处理类与对象的组合，优化系统结构，提高模块间的解耦性。

关注如何将对象组合成更大的结构，处理类和对象的关系，以实现更大的功能。

核心思想：通过组合、继承或接口，调整类与对象的结构，增强系统的灵活性和扩展性。

3. 行为型模式

目的：定义对象间的通信机制，管理算法或职责的动态变化。

核心思想：通过解耦对象间的直接依赖，实现行为的动态组合、算法替换或事件驱动。

3、重构获得模式

需要强调的是：

设计模式是循序渐进的，如同架构设计一样，没有一步到位的设计模式，也少有单一的设计模式，要掌握应用时间、地点。

应对变化，提高复用，寻找变化点。

设计模式应在变化点处应用：设计模式是对动态变化点的设计，在变化、稳定中寻找隔离点，来分离他们，从而管理变化，以稳控变。

没有一个稳定的点，设计模式就没有意义。

设计模式有23种，慢慢理解嘛。

重构关键技法

在《重构-改善既有代码的设计》一书中，作者Martin Fowler有提到一些有效的重构手法，重构时遵守设计原则。

技法对应原则如下：

静态——>动态

更好地适应变化与减少重复代码：动态结构可以通过配置或者接口灵活调整，可以服用逻辑，避免静态编码导致的重复。

设计模式：

如策略模式（通过接口定义算法族，运行时选择具体策略）、观察者模式（事件驱动的动态通知机制）

重构手法：

替换条件分支为多态（如将if-else替换为不同子类实现）。

引入参数化配置（如通过配置文件动态加载行为）。

示例如下：

// 静态：硬编码的条件判断
public void calculateTax(double income) {
    if (country == "USA") {
        // 美国税率逻辑
    } else if (country == "China") {
        // 中国税率逻辑
    }
}

// 动态：使用策略模式
interface TaxStrategy {
    double calculate(double income);
}
class USATax implements TaxStrategy { ... }
class ChinaTax implements TaxStrategy { ... }

public void calculateTax(TaxStrategy strategy, double income) {
    return strategy.calculate(income);
}

早绑定——>晚绑定

通过接口和运行时决策增强灵活性。

定义与背景

为什么需要转向晚绑定？

如何实现？

// 早绑定：直接依赖具体类
public void sendEmail(Email email) {
    EmailSender sender = new GmailSender();
    sender.send(email);
}

// 晚绑定：通过接口实现多态
public interface EmailSender {
    void send(Email email);
}
public class GmailSender implements EmailSender { ... }
public class OutlookSender implements EmailSender { ... }

public void sendEmail(Email email, EmailSender sender) {
    sender.send(email); // 运行时决定具体实现
}

继承——>组合

用组合替代继承，避免层级过深。

定义与背景

为什么需要转向组合？

如何实现？

// 继承：硬编码行为
class Animal {
    void move() { ... }
}
class Bird extends Animal { ... }
class Fish extends Animal { ... }

// 组合：通过接口解耦
interface MovementStrategy {
    void move();
}
class Bird {
    private MovementStrategy movement;
    public Bird(MovementStrategy movement) {
        this.movement = movement;
    }
    void fly() {
        movement.move(); // 组合不同策略
    }
}

编译时依赖——>运行时依赖

将依赖关系移到运行时，提高可测试性和扩展性。

定义与背景

为什么需要转向运行时依赖？

如何实现？

// 编译时依赖：硬编码依赖
class Service {
    private Database database = new MySQLDatabase();

    void doWork() {
        database.query();
    }
}

// 运行时依赖：通过构造函数注入
class Service {
    private Database database;

    public Service(Database database) {
        this.database = database; // 运行时注入
    }

    void doWork() {
        database.query();
    }
}

紧耦合——>松耦合

通过抽象接口和事件机制降低模块间依赖。

定义与背景

为什么需要转向松耦合？

如何实现？

// 紧耦合：直接调用具体类
class Button {
    void onClick() {
        Text text = new Text();
        text.update();
    }
}

// 松耦合：通过接口解耦
interface Updatable {
    void update();
}
class Button {
    private Updatable listener;

    public Button(Updatable listener) {
        this.listener = listener;
    }

    void onClick() {
        listener.update();
    }
}

总结一下核心思想是动态化、低耦合高内聚、保证可读性与可维护性。

生产设计的原则倾向

低耦合、高内聚是软件设计的核心原则，但并非所有设计场景的最优先考虑的事情。

比如业务服务设计中，优先考虑组织架构所需求的迭代或者用户需求和业务目标，在架构设计中，优先考虑系统性能、可维护性。

需要依据具体场景灵活变动。

再次强调，无必要修改的“完美主义”重构，设计模式也不是最优先考虑的，优先完成，优先保证代码清晰。