🎨 设计模式的四大原则

字数统计: 4k字   |   阅读时长≈ 16分

🎯 导读：本文将用生动有趣的方式，带你深入理解面向对象设计的四大核心原则。每个原则都配有 🎭 生活比喻、💻 完整代码案例 和 📊 UML类图，让你轻松掌握这些看似高深的设计思想！

🏛️ 前言：为什么需要设计原则？

想象一下，你正在搭建一座大厦：

  • ❌ 没有原则：就像用泥巴和树枝随意堆砌，风一吹就倒
  • ✅ 遵循原则：就像使用钢筋混凝土的标准结构，稳固且可扩展

设计原则就是软件世界的”建筑规范”，它们让我们的代码：

  • 🧩 易于维护 —— 修改一处，不影响全局
  • 🚀 易于扩展 —— 新增功能，不用改老代码
  • 🤝 易于协作 —— 团队成员都能快速理解

📐 原则一：单一职责原则 (SRP)

“一个类应该只有一个引起它变化的原因”

🎭 生动比喻：瑞士军刀 vs 专业厨房

场景 形象 问题
❌ 违反SRP 🔪 瑞士军刀 既能切菜、开红酒、拧螺丝、剪指甲… 看似全能，但哪个功能都不专业！剪刀坏了，可能影响到拔塞器
✅ 遵守SRP 👨‍🍳 专业厨房 切肉有斩骨刀，削皮有削皮刀，开红酒有海马刀。各司其职，哪把钝了磨哪把

📊 UML 对比

❌ 违反 SRP —— “上帝类” 设计

classDiagram
    class OptimizationReport {
        - string reportData
        + processData()
        + formatToHTML()
        + saveToFile()
    }

🔥 问题：一个类干了3个人的活！任何需求变更都要修改这个类，高耦合、高风险

✅ 遵守 SRP —— 各司其职

classDiagram
    class OptimizationData {
        - double maxStress
        - double minDensity
        + getRawData()
    }
    
    class ReportFormatter {
        + formatAsHTML()
        + formatAsMarkdown()
    }
    
    class DataSaver {
        + saveToDisk()
        + saveToCloud()
    }
    
    OptimizationData ..> ReportFormatter : 被格式化
    ReportFormatter ..> DataSaver : 被保存

✅ 单一职责：每个类只负责一件事

💻 代码实战

❌ 反面教材：大包大揽的”上帝类”

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
#include <iostream>
#include <string>

// 🔥 【反面教材】：这个类承担了太多的职责！
class OptimizationReport {
private:
    std::string reportData;

public:
    // 🔄 职责 1：负责业务逻辑处理（处理计算数据）
    void processData(double maxStress, double minDensity) {
        std::cout << "📊 正在处理应力和密度数据..." << std::endl;
        reportData = "最大应力: " + std::to_string(maxStress) 
                    + ", 最小密度: " + std::to_string(minDensity);
    }

    // 🎨 职责 2：负责格式化输出（排版）
    std::string formatToHTML() {
        std::cout << "🎨 正在将数据排版为 HTML 格式..." << std::endl;
        return "<html><body><h1>优化报告</h1><p>" 
               + reportData + "</p></body></html>";
    }

    // 💾 职责 3：负责文件存储（持久化）
    void saveToFile(const std::string& fileName, 
                    const std::string& content) {
        std::cout << "💾 正在将结果写入磁盘文件: " << fileName << std::endl;
        // 假装这里有写文件的底层代码
    }
};

⚠️ 为什么说这个设计很糟糕？ 因为它有 **3个”引起它变化的原因”**：

  1. 📊 改变数据处理逻辑（增加应变数据）→ 要改这个类
  2. 🎨 报告格式从 HTML 改成 PDF → 要改这个类
  3. 💾 存储从本地改成云端 → 还要改这个类

🔥 一个类被修改的理由太多 = 高耦合 = 牵一发而动全身！

✅ 正面教材：拆分解耦，各司其职

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
#include <iostream>
#include <string>

// ==========================================
// 🧩 类 1：只负责数据处理（数据模型）
// ==========================================
class OptimizationData {
private:
    double maxStress;
    double minDensity;

public:
    OptimizationData(double stress, double density) 
        : maxStress(stress), minDensity(density) {}
    
    std::string getRawData() const {
        return "最大应力: " + std::to_string(maxStress) 
             + ", 最小密度: " + std::to_string(minDensity);
    }
};

// ==========================================
// 🎨 类 2：只负责格式化排版（视图展示）
// ==========================================
class ReportFormatter {
public:
    // 📝 如果以后要加 Markdown 格式，修改这个类即可
    std::string formatAsHTML(const OptimizationData& data) {
        return "<html><body><h1>优化报告</h1><p>" 
               + data.getRawData() + "</p></body></html>";
    }
    
    // 🆕 新增 Markdown 格式，不影响其他类
    std::string formatAsMarkdown(const OptimizationData& data) {
        return "# 优化报告\n\n" + data.getRawData();
    }
};

// ==========================================
// 💾 类 3：只负责存储（持久化）
// ==========================================
class DataSaver {
public:
    // 💿 存本地
    void saveToDisk(const std::string& fileName, 
                    const std::string& content) {
        std::cout << "💿 [本地存储] 成功写入: " << fileName << std::endl;
    }
    
    // ☁️ 如果要存数据库，新增方法即可
    void saveToCloud(const std::string& content) {
        std::cout << "☁️ [云端存储] 正在上传数据..." << std::endl;
    }
};

// ==========================================
// 🎯 业务调用端：像搭积木一样组合它们
// ==========================================
int main() {
    std::cout << "🚀 === 开始生成报告 ===" << std::endl;

    // 1️⃣ 数据组：处理数据
    OptimizationData myData(250.5, 0.05);

    // 2️⃣ 排版组：渲染数据
    ReportFormatter formatter;
    std::string htmlReport = formatter.formatAsHTML(myData);

    // 3️⃣ 存储组：保存文件
    DataSaver saver;
    saver.saveToDisk("result.html", htmlReport);

    std::cout << "✅ 报告生成完成！" << std::endl;
    return 0;
}

🎯 SRP 核心总结

好处 说明
🧩 代码像积木 ReportFormatter 可被系统任何地方复用
🛡️ 修改不胆战心惊 DataSaver 出 BUG 不会影响数据计算逻辑
👥 团队协作顺畅 三个程序员可同时开发，无代码冲突

💡 判断技巧：试着用一句话描述类的功能。如果用到”和“、”并且“、”此外“，大概率违反了 SRP！

🔓 原则二：开放封闭原则 (OCP)

“对扩展开放，对修改封闭”

  • ✅ 对扩展开放：需求变化时，能够方便地增加新功能
  • 🔒 对修改封闭：增加新功能时，不修改已测试通过的老代码

🎭 生动比喻：电脑的 USB 接口 🖥️🔌

特性 说明
✅ 对扩展开放 买新鼠标、键盘、USB风扇，都能直接插上使用
🔒 对修改封闭 不需要拆开机箱，把鼠标线焊接到主板上！

核心思想：通过预留标准接口，让新功能像插件一样”插”进系统！

📊 UML 对比

❌ 违反 OCP —— 被 if-else 支配的恐惧

classDiagram
    class PaymentProcessor {
        + processPayment()
    }

❌ 问题：新增支付方式必须修改核心类，容易引入 BUG，违反”对修改封闭”

代码示例：

1
2
3
4
if (payType == 'Alipay') { ... }
else if (payType == 'WeChat') { ... }
else if (payType == 'ApplePay') { ... } 🔥
else if (payType == 'UnionPay') { ... } 🔥

✅ 遵守 OCP —— 面向接口，热插拔

classDiagram
    class IPaymentMethod {
        + pay()
    }
    
    class PaymentProcessor {
        + processPayment()
    }
    
    class AliPay {
        + pay()
    }
    
    class WeChatPay {
        + pay()
    }
    
    class ApplePay {
        + pay()
    }
    
    class UnionPay {
        + pay()
    }
    
    PaymentProcessor ..> IPaymentMethod : 依赖接口
    AliPay ..|> IPaymentMethod : 实现
    WeChatPay ..|> IPaymentMethod : 实现
    ApplePay ..|> IPaymentMethod : 实现
    UnionPay ..|> IPaymentMethod : 实现

✅ 完美遵守 OCP：这个方法永远不需要再修改！只依赖抽象接口，不依赖具体实现

🆕 新增支付方式：只需添加新类，无需修改原有代码

💻 代码实战

❌ 反面教材：if-else 地狱

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <iostream>
#include <string>

// 🔥 【反面教材】：严重违反开闭原则
class PaymentProcessor {
public:
    // 💣 核心支付逻辑 - 每次新增支付方式都要改这里！
    void processPayment(const std::string& payType, double amount) {
        if (payType == "Alipay") {
            std::cout << "💰 正在调用支付宝 API，扣款: " 
                      << amount << " 元。" << std::endl;
        } 
        else if (payType == "WeChat") {
            std::cout << "💬 正在调用微信支付 API，扣款: " 
                      << amount << " 元。" << std::endl;
        }
        // 🔥 噩梦：每加一种支付方式都要来这里加 else if！
        // else if (payType == "ApplePay") { ... }
        // else if (payType == "UnionPay") { ... }
        else {
            std::cout << "❌ 不支持的支付方式！" << std::endl;
        }
    }
};

⚠️ 噩梦场景：公司业务拓展，要求接入 Apple Pay 和 银联支付。

你被迫打开 PaymentProcessor 核心类，继续增加 else if。

🔥 风险：加 Apple Pay 时不小心删了支付宝的逻辑 → 整个支付系统崩溃！

✅ 正面教材：策略模式 + 多态

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
44
#include <iostream>
#include <string>
#include <memory>

// ==========================================
// 🔌 1. 制定标准接口（相当于电脑的 USB 接口）
// ==========================================
class IPaymentMethod {
public:
    virtual ~IPaymentMethod() = default;
    // 纯虚函数，要求子类必须实现
    virtual void pay(double amount) = 0;
};

// ==========================================
// 🔌 2. 具体的支付方式（相当于各种 USB 设备）
// ==========================================
class AliPay : public IPaymentMethod {
public:
    void pay(double amount) override {
        std::cout << "  💰 支付宝：成功支付 " << amount << " 元。" << std::endl;
    }
};

class WeChatPay : public IPaymentMethod {
public:
    void pay(double amount) override {
        std::cout << "  💬 微信：成功扫码支付 " << amount << " 元。" << std::endl;
    }
};

// ==========================================
// 🖥️ 3. 核心处理类（相当于电脑主板）
// ==========================================
class PaymentProcessor {
public:
    // ✅ 【完美遵守 OCP】：这个方法永远不需要再修改！
    // 它只依赖抽象的接口，不依赖具体的实现
    void processPayment(IPaymentMethod* method, double amount) {
        std::cout << "🛒 系统开始处理订单..." << std::endl;
        method->pay(amount);  // 🎯 多态调用
        std::cout << "✅ 订单处理完成。\n" << std::endl;
    }
};

🆕 见证奇迹：扩展新功能无需修改老代码！

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
// 🎉 只需要新增代码，绝不修改老代码！（对扩展开放）
class ApplePay : public IPaymentMethod {
public:
    void pay(double amount) override {
        std::cout << "  🍎 Apple Pay：FaceID 认证成功，支付 " 
                  << amount << " 元。" << std::endl;
    }
};

class UnionPay : public IPaymentMethod {
public:
    void pay(double amount) override {
        std::cout << "  🏦 银联：银行卡支付 " 
                  << amount << " 元。" << std::endl;
    }
};

// ==========================================
// 🎯 业务调用
// ==========================================
int main() {
    PaymentProcessor processor;

    // 💰 支付宝支付
    AliPay alipay;
    processor.processPayment(&alipay, 100.0);

    // 💬 微信支付
    WeChatPay wechat;
    processor.processPayment(&wechat, 200.0);

    // 🍎 Apple Pay - 新增功能，像插 USB 一样简单！
    ApplePay applePay;
    processor.processPayment(&applePay, 599.0);
    
    // 🏦 银联支付 - 再新增一个！
    UnionPay unionPay;
    processor.processPayment(&unionPay, 1000.0);

    return 0;
}

🎯 OCP 核心总结

问题 解决方案
🤔 为什么需要 OCP？ 软件需求变化是绝对的。如果每次变动都要修改底层核心代码，系统会越来越脆弱（代码腐化）
🛠️ 怎么实现 OCP？ 秘诀是 **”抽象”**（接口/抽象类）+ **”多态”**。把易变部分抽象成接口，调用方只依赖接口
🎨 和设计模式的关系 策略模式就是 OCP 最完美的践行者！OCP 是思想，策略模式是具体战术

🔄 原则三：依赖倒置原则 (DIP)

“高层模块不应该依赖低层模块，两者都应该依赖抽象”

🎭 生动比喻：墙壁插座与家用电器 🔌

角色 类比
🏠 高层模块 你家房子的供电系统
📺 低层模块 电视机、电冰箱、电灯泡

❌ 违反 DIP（硬连接）

装修工人把供电系统的电线，直接焊死在电视机内部。

  • 🔥 后果：电视机坏了想换电冰箱？得把墙砸了，重新焊接！

✅ 遵守 DIP（引入插座）

国家规定 “三孔插座标准”（抽象接口）：

  • 🔌 供电系统（高层）：只负责把电送到插座，不关心外面接什么
  • 🔌 电视机（低层）：只负责设计能插进插座的插头
  • ✅ 结果：想插什么电器就插什么，墙壁永远不需要改动！

📊 UML 对比

❌ 违反 DIP —— 高层直接依赖低层

classDiagram
    class TopologyProject {
        - LocalDiskWriter diskWriter
        + saveResult()
    }
    
    class LocalDiskWriter {
        + writeToDisk()
    }
    
    TopologyProject --> LocalDiskWriter

❌ 致命错误：高层模块直接绑定低层模块，想换云端存储？必须剖开核心代码！

✅ 遵守 DIP —— 依赖注入

classDiagram
    class IStorage {
        + saveData()
    }
    
    class TopologyProject {
        - IStorage storage
        + TopologyProject()
        + saveResult()
    }
    
    class LocalDiskWriter {
        + saveData()
    }
    
    class CloudStorageWriter {
        + saveData()
    }
    
    TopologyProject ..> IStorage : 依赖抽象
    LocalDiskWriter ..|> IStorage : 实现
    CloudStorageWriter ..|> IStorage : 实现

✅ 依赖注入：通过构造函数传入具体实现，高层只认接口，不认具体类

🆕 新增云端存储：无需修改 TopologyProject 一行代码！

💻 代码实战

❌ 反面教材：高层直接依赖低层

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
#include <iostream>
#include <string>

// ==========================================
// 💾 【低层模块】：专门负责写本地硬盘
// ==========================================
class LocalDiskWriter {
public:
    void writeToDisk(const std::string& data) {
        std::cout << "  💾 [低层] 正在将数据写入本地 C 盘： " 
                  << data << std::endl;
    }
};

// ==========================================
// 🏗️ 【高层模块】：核心优化项目类
// ==========================================
class TopologyProject {
private:
    // 🔥 致命错误：高层模块直接绑定了低层模块的实体类！
    LocalDiskWriter diskWriter; 

public:
    void saveResult() {
        std::string resultData = "单元密度矩阵: [0.9, 0.1, ...]";
        std::cout << ">>> 拓扑优化计算完毕，准备保存结果 <<<" << std::endl;
        
        // 🔥 高层直接调用低层的方法
        diskWriter.writeToDisk(resultData); 
    }
};

⚠️ 痛点：公司要求软件支持”保存到阿里云数据库”。

你必须把 TopologyProject（核心高层代码）剖开，把 LocalDiskWriter 删掉换成 CloudWriter。

🔥 极易引入 BUG！

✅ 正面教材：依赖注入大法

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
#include <iostream>
#include <string>
#include <memory>

// ==========================================
// 🔌 1. 抽象接口（插座标准）- 属于高层定义
// ==========================================
class IStorage {
public:
    virtual ~IStorage() = default;
    virtual void saveData(const std::string& data) = 0;
};

// ==========================================
// 🏗️ 2. 高层模块（墙里的电线，只认插座）
// ==========================================
class TopologyProject {
private:
    // ✅ 高层模块只依赖抽象接口！
    // 完全不知道硬盘、云端的存在
    std::shared_ptr<IStorage> storageMethod;

public:
    // 🎯 【核心战术：依赖注入】
    // 在创建项目时，从外部把具体的"插头"插进来
    TopologyProject(std::shared_ptr<IStorage> method) 
        : storageMethod(method) {}

    void saveResult() {
        std::string resultData = "单元密度矩阵: [0.9, 0.1, ...]";
        std::cout << ">>> 拓扑优化计算完毕，准备保存结果 <<<" << std::endl;
        
        // 🎯 盲调用接口方法
        storageMethod->saveData(resultData); 
    }
};

// ==========================================
// 💾 3. 低层模块（具体的电器，负责实现插头）
// ==========================================
class LocalDiskWriter : public IStorage {
public:
    void saveData(const std::string& data) override {
        std::cout << "  💿 [本地驱动] 转动磁盘，写入本地硬盘。" << std::endl;
    }
};

class CloudStorageWriter : public IStorage {
public:
    void saveData(const std::string& data) override {
        std::cout << "  ☁️ [云端驱动] 建立 TCP 连接，上传至云服务器。" << std::endl;
    }
};

class DatabaseWriter : public IStorage {
public:
    void saveData(const std::string& data) override {
        std::cout << "  🗄️ [数据库驱动] 执行 SQL 插入语句。" << std::endl;
    }
};

// ==========================================
// 🎯 业务调用端：组装系统
// ==========================================
int main() {
    // 🏠 场景 1：用户在没有网络的环境下使用
    std::cout << "=== 场景 1：本地存储 ===" << std::endl;
    std::shared_ptr<IStorage> localMethod = 
        std::make_shared<LocalDiskWriter>();
    TopologyProject projectA(localMethod);  // 把本地插头插进项目
    projectA.saveResult();

    std::cout << "\n-------------------\n" << std::endl;

    // ☁️ 场景 2：用户在公司内网，要求数据上云
    // 🎉 注意：TopologyProject 核心类的一行代码都不用改！
    std::cout << "=== 场景 2：云端存储 ===" << std::endl;
    std::shared_ptr<IStorage> cloudMethod = 
        std::make_shared<CloudStorageWriter>();
    TopologyProject projectB(cloudMethod);  // 把云端插头插进项目
    projectB.saveResult();
    
    std::cout << "\n-------------------\n" << std::endl;
    
    // 🗄️ 场景 3：保存到数据库
    std::cout << "=== 场景 3：数据库存储 ===" << std::endl;
    std::shared_ptr<IStorage> dbMethod = 
        std::make_shared<DatabaseWriter>();
    TopologyProject projectC(dbMethod);
    projectC.saveResult();

    return 0;
}

🎯 DIP 核心总结

为什么叫”倒置”(Inversion)？

1
2
3
4
5
传统思维（自顶向下）：
🏗️ 高层模块 ──(依赖)──> 💾 低层模块

DIP 思维（倒置依赖）：
🏗️ 高层模块 ──(依赖)──> 🔌 抽象接口 <──(实现)── 💾 低层模块

四大原则的关系

原则 作用 关系
📐 SRP 让类保持小巧和纯洁 基础：扎马步
🔓 OCP 最终目标：不改老代码，只加新代码 目标：武功大成
🔄 DIP 实现 OCP 的最核心手段 心法：内功
🎨 策略/工厂模式 落地到代码的具体招式 招式：降龙十八掌

💡 一句话总结：DIP 就是通过面向接口编程，让高层和低层都依赖于抽象，而不是相互直接依赖！

🧬 原则四：里氏替换原则 (LSP)

“所有引用基类的地方必须能透明地使用其子类的对象”

由计算机科学家 芭芭拉·里斯科夫（Barbara Liskov） 提出，专门约束继承关系。

🎭 生动比喻：老爹的炸鸡店 🍗

你老爹开了一家”老爹炸鸡店”（父类），契约是：”本店提供美味的炸鸡“。

❌ 违反 LSP —— 坑爹的儿子

你（子类）继承了店，但为了省钱，把炸鸡换成了炸馒头，还说：”都是炸的，差不多！”

🔥 后果：老顾客（客户端代码）来点餐，发现味道完全不对，程序崩溃！

✅ 遵守 LSP —— 合格的继承者

你（子类）继承了店，提供了更美味的炸鸡（优化实现），但契约不变。

✅ 结果：老顾客完全无感知，甚至觉得更好吃了！

📊 UML 对比

❌ 违反 LSP —— 子类破坏父类契约

classDiagram
    class Bird {
        + fly()
    }
    
    class Sparrow {
        + fly()
    }
    
    class Ostrich {
        + fly()
    }
    
    Bird <|-- Sparrow : 继承
    Bird <|-- Ostrich : 继承

❌ 违反 LSP：鸵鸟重写了 fly() 方法，但里面写着 throw Exception(“不会飞”) 或空的 {} 来掩盖错误。用 Bird 的地方替换为 Ostrich 会崩溃！

✅ 遵守 LSP —— 正确的继承层次

classDiagram
    class Animal {
        + move()
    }
    
    class Bird {
        + fly()
    }
    
    class Sparrow {
        + fly()
    }
    
    class Ostrich {
        + run()
    }
    
    Animal <|-- Bird : 继承
    Animal <|-- Ostrich : 继承
    Bird <|-- Sparrow : 继承

✅ 遵守 LSP：鸵鸟不继承 Bird，而是直接继承 Animal，实现自己的 move()。不会飞的鸟就不应该继承会飞的鸟！

💻 代码实战

❌ 反面教材：鸵鸟继承鸟（经典错误）

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
#include <iostream>
#include <stdexcept>

// ==========================================
// 🐦 父类：鸟（会飞）
// ==========================================
class Bird {
public:
    virtual void fly() {
        std::cout << "🐦 鸟儿展翅高飞！" << std::endl;
    }
    
    virtual ~Bird() = default;
};

// ==========================================
// 🐦 子类：麻雀（会飞，正常）
// ==========================================
class Sparrow : public Bird {
public:
    void fly() override {
        std::cout << "🐦 麻雀轻盈地飞过树梢！" << std::endl;
    }
};

// ==========================================
// 🦩 子类：鸵鸟（不会飞，问题大了！）
// ==========================================
class Ostrich : public Bird {
public:
    // 🔥 致命错误：鸵鸟不会飞，但被迫实现 fly()！
    void fly() override {
        // ❌ 方案 1：抛出异常
        throw std::runtime_error("🦩 鸵鸟不会飞！这是设计错误！");
        
        // ❌ 方案 2：空实现（掩盖错误）
        // std::cout << "🦩 鸵鸟：我假装会飞..." << std::endl;
    }
};

// ==========================================
// 🎯 客户端代码：让鸟飞起来
// ==========================================
void makeBirdFly(Bird* bird) {
    std::cout << "准备让鸟儿起飞..." << std::endl;
    bird->fly();  // 🎯 多态调用
    std::cout << "飞行结束。\n" << std::endl;
}

// ==========================================
// 🧪 测试代码
// ==========================================
int main() {
    // ✅ 麻雀能飞，没问题
    Sparrow sparrow;
    makeBirdFly(&sparrow);
    
    // 🔥 鸵鸟不会飞，但程序崩溃了！
    Ostrich ostrich;
    try {
        makeBirdFly(&ostrich);  // 💥 抛出异常！
    } catch (const std::exception& e) {
        std::cout << "❌ 错误：" << e.what() << std::endl;
    }
    
    return 0;
}

⚠️ 问题分析：

  • 🦩 鸵鸟是鸟，但不会飞
  • 🔥 强迫鸵鸟继承 Bird 类，违反了自然属性
  • 💥 用 Bird* 的地方替换为 Ostrich*，程序行为异常！

✅ 正面教材：正确的继承层次设计

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
#include <iostream>
#include <memory>

// ==========================================
// 🐾 顶层抽象：动物（都会移动）
// ==========================================
class Animal {
public:
    virtual void move() = 0;  // 纯虚函数
    virtual ~Animal() = default;
};

// ==========================================
// 🐦 中间层：会飞的鸟
// ==========================================
class FlyableBird : public Animal {
public:
    void move() override {
        fly();  // 移动方式就是飞
    }
    
    virtual void fly() {
        std::cout << "🐦 鸟儿展翅高飞！" << std::endl;
    }
};

// ==========================================
// 🐦 具体鸟类：麻雀
// ==========================================
class Sparrow : public FlyableBird {
public:
    void fly() override {
        std::cout << "🐦 麻雀轻盈地飞过树梢！" << std::endl;
    }
};

// ==========================================
// 🦅 具体鸟类：老鹰
// ==========================================
class Eagle : public FlyableBird {
public:
    void fly() override {
        std::cout << "🦅 老鹰在高空翱翔！" << std::endl;
    }
};

// ==========================================
// 🦩 不会飞的鸟：直接继承 Animal
// ==========================================
class FlightlessBird : public Animal {
public:
    void move() override {
        run();  // 移动方式是跑
    }
    
    virtual void run() {
        std::cout << "🏃 鸟儿在奔跑！" << std::endl;
    }
};

// ==========================================
// 🦩 具体鸟类：鸵鸟
// ==========================================
class Ostrich : public FlightlessBird {
public:
    void run() override {
        std::cout << "🦩 鸵鸟迈开大长腿飞奔！时速 70 公里！" << std::endl;
    }
};

// ==========================================
// 🐧 具体鸟类：企鹅
// ==========================================
class Penguin : public FlightlessBird {
public:
    void run() override {
        std::cout << "🐧 企鹅摇摇摆摆地走路，偶尔滑个冰~" << std::endl;
    }
};

// ==========================================
// 🎯 客户端代码：让动物移动
// ==========================================
void makeAnimalMove(Animal* animal) {
    std::cout << "准备让动物移动..." << std::endl;
    animal->move();  // 🎯 多态调用
    std::cout << "移动结束。\n" << std::endl;
}

// ==========================================
// 🧪 测试代码：所有替换都正常工作！
// ==========================================
int main() {
    std::cout << "=== 🧪 LSP 测试：所有子类都能透明替换父类 ===\n" << std::endl;
    
    // ✅ 会飞的鸟
    std::cout << "【会飞的鸟类】" << std::endl;
    Sparrow sparrow;
    makeAnimalMove(&sparrow);  // 🐦 麻雀飞
    
    Eagle eagle;
    makeAnimalMove(&eagle);    // 🦅 老鹰飞
    
    std::cout << "-------------------\n" << std::endl;
    
    // ✅ 不会飞的鸟 - 也能正常工作！
    std::cout << "【不会飞的鸟类】" << std::endl;
    Ostrich ostrich;
    makeAnimalMove(&ostrich);  // 🦩 鸵鸟跑
    
    Penguin penguin;
    makeAnimalMove(&penguin);  // 🐧 企鹅走
    
    std::cout << "✅ 所有测试通过！每个子类都能完美替换父类！" << std::endl;
    
    return 0;
}

🎯 LSP 核心总结

判断标准

检查项 说明
✅ 行为一致 子类替换父类后，程序行为不变
✅ 契约遵守 子类不破坏父类的前置条件、后置条件
❌ 反模式 子类重写方法时抛出异常或空实现来掩盖错误

常见违反场景

1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ 危险信号：这些写法 100% 违反 LSP！

void SomeMethod() override {
    throw NotSupportedException("不支持此操作");  // 🔥 违反！
}

void SomeMethod() override {
    // 空的 {}  // 🔥 违反！掩盖错误
}

void SomeMethod() override {
    // 做了和父类完全不同的事情  // 🔥 违反！
}

解决方案

如果发现子类需要”破坏”父类的行为，说明继承关系设计错误：

  1. 🔄 抽离更细的接口 —— 如 Flyable 和 Runnable 分开
  2. 🔀 改为组合关系 —— 用”有一个”代替”是一个”

💡 一句话总结：子类必须能够 100% 替代父类，而不改变程序的正确性！

🎓 总结：四大原则的关系

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────────────────────────────────────────┐
│                    🏛️ SOLID 设计原则                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   📐 SRP (单一职责)                                          │
│   └── 基础：让每个类只干一件事，保持小巧纯洁                    │
│           ↓                                                 │
│   🔄 DIP (依赖倒置)                                          │
│   └── 手段：通过接口解耦，高层低层都依赖抽象                    │
│           ↓                                                 │
│   🔓 OCP (开放封闭)                                          │
│   └── 目标：不改老代码，只加新代码，系统稳定可扩展               │
│           ↓                                                 │
│   🧬 LSP (里氏替换)                                          │
│   └── 约束：继承必须正确，子类要能透明替换父类                   │
│                                                             │
├─────────────────────────────────────────────────────────────┤
│  🎨 设计模式（策略模式、工厂模式等）是这些原则的具体实现招式      │
└─────────────────────────────────────────────────────────────┘

🎯 记忆口诀

“单开依里” —— 单（SRP）开（OCP）依（DIP）里（LSP）

记住：单身开放，依然美丽 😄

📝 本文通过 🎭 生活比喻、📊 UML类图、💻 完整代码案例，帮助你深入理解设计模式四大原则。希望对你有所帮助！

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

僕は新世界の神となる!