🏗️ 设计模式基础与SOLID原则
设计模式是软件开发中经过验证的、可复用的解决方案。掌握设计模式，能够让我们的代码更加优雅、可维护、可扩展。
一、什么是设计模式
设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
设计模式的核心思想是：在特定环境下解决软件设计中某类通用问题的方案。它不是可以直接复制粘贴的代码，而是一种解决问题的思路和方法论。
🎯 设计模式的本质价值
| 价值维度 | 说明 |
|---|---|
| 可复用性 | 避免重复造轮子，站在巨人的肩膀上 |
| 可维护性 | 遵循统一的模式，代码结构清晰易懂 |
| 可扩展性 | 方便添加新功能，减少对现有代码的修改 |
| 沟通效率 | 提供统一的术语，团队沟通更高效 |
二、设计模式的三大分类
根据设计模式的用途，可以将其分为三大类：创建型模式、结构型模式和行为型模式。
2.1 创建型模式（5种）
创建型模式关注对象的创建过程，将对象的创建和使用分离，降低系统的耦合度。
| 模式名称 | 核心思想 | 适用场景 |
|---|---|---|
| 工厂方法模式 | 定义一个创建对象的接口，让子类决定实例化哪一个类 | 需要根据条件创建不同对象 |
| 抽象工厂模式 | 提供一个创建一系列相关或相互依赖对象的接口 | 需要创建产品族 |
| 单例模式 | 确保一个类只有一个实例，并提供全局访问点 | 配置管理器、连接池、日志对象 |
| 建造者模式 | 将一个复杂对象的构建与它的表示分离 | 创建复杂对象，如配置项较多的对象 |
| 原型模式 | 通过复制现有对象来创建新对象 | 创建成本较高的对象 |
2.2 结构型模式（7种）
结构型模式关注类和对象的组合，通过继承或组合来构建更大的结构。
| 模式名称 | 核心思想 | 适用场景 |
|---|---|---|
| 适配器模式 | 将一个类的接口转换成客户希望的另一个接口 | 接口不兼容时进行转换 |
| 装饰器模式 | 动态地给一个对象添加一些额外的职责 | 不通过继承扩展对象功能 |
| 代理模式 | 为其他对象提供一种代理以控制对这个对象的访问 | 远程代理、虚拟代理、保护代理 |
| 外观模式 | 为子系统中的一组接口提供一个一致的界面 | 简化复杂系统的使用 |
| 桥接模式 | 将抽象部分与实现部分分离，使它们都可以独立变化 | 多维度变化的对象 |
| 组合模式 | 将对象组合成树形结构以表示"部分-整体"的层次结构 | 树形结构数据处理 |
| 享元模式 | 运用共享技术有效地支持大量细粒度的对象 | 大量相似对象的共享 |
2.3 行为型模式（11种）
行为型模式关注对象之间的通信、职责划分，以及算法的封装。
| 模式名称 | 核心思想 | 适用场景 |
|---|---|---|
| 策略模式 | 定义一系列算法，把它们一个个封装起来，并且使它们可相互替换 | 多种算法可互换 |
| 模板方法模式 | 定义一个操作中的算法骨架，而将一些步骤延迟到子类中 | 固定流程，具体步骤可变 |
| 观察者模式 | 定义对象间一对多的依赖关系，当一个对象状态改变时，所有依赖它的对象都得到通知 | 事件驱动系统 |
| 迭代器模式 | 提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示 | 遍历集合 |
| 责任链模式 | 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系 | 多级审批、事件处理链 |
| 命令模式 | 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化 | 撤销/重做操作 |
| 备忘录模式 | 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态 | 撤销操作、游戏存档 |
| 状态模式 | 允许一个对象在其内部状态改变时改变它的行为 | 状态机实现 |
| 访问者模式 | 表示一个作用于某对象结构中的各元素的操作 | 数据结构与操作分离 |
| 中介模式 | 用一个中介对象来封装一系列的对象交互 | 对象间复杂交互 |
| 解释器模式 | 给定一个语言，定义它的文法的一种表示，并定义一个解释器 | SQL解析、正则表达式 |
三、SOLID原则详解
SOLID是面向对象设计的五大基本原则的首字母缩写，由Robert C. Martin（Uncle Bob）提出。这些原则是设计模式的理论基础，理解它们对于正确使用设计模式至关重要。
3.1 单一职责原则（Single Responsibility Principle, SRP）
定义：一个类应该只有一个引起它变化的原因。
核心思想：每个类只负责一项职责，不要将多个职责耦合在一个类中。
// ❌ 违反单一职责原则classUser{public:voidlogin(){/* 登录逻辑 */}voidsaveToDatabase(){/* 数据库存储逻辑 */}voidsendEmail(){/* 发送邮件逻辑 */}};// ✅ 遵循单一职责原则classUser{public:voidlogin(){/* 登录逻辑 */}};classUserRepository{public:voidsave(User user){/* 数据库存储逻辑 */}};classEmailService{public:voidsend(User user){/* 发送邮件逻辑 */}};实际经验：
- 如果一个类的方法超过10个，或者代码超过300行，就需要考虑是否职责过多
- 职责的划分粒度需要根据实际项目规模来定，不要过度拆分
3.2 开闭原则（Open-Closed Principle, OCP）
定义：软件实体应该对扩展开放，对修改关闭。
核心思想：在不修改现有代码的情况下，通过扩展来增加新功能。
// ✅ 通过抽象实现开闭原则classShape{public:virtualdoublearea()=0;virtual~Shape()=default;};classRectangle:publicShape{doublewidth,height;public:doublearea()override{returnwidth*height;}};classCircle:publicShape{doubleradius;public:doublearea()override{return3.14159*radius*radius;}};// 新增三角形，不需要修改现有代码classTriangle:publicShape{doublebase,height;public:doublearea()override{return0.5*base*height;}};实际经验：
- 使用抽象和多态是实现开闭原则的主要手段
- 设计时要预见可能的变化点，提前做好抽象
3.3 里氏替换原则（Liskov Substitution Principle, LSP）
定义：所有引用基类的地方必须能透明地使用其子类的对象。
核心思想：子类必须能够替换其基类，且不破坏程序的正确性。使用多态、面向接口编程。
// ❌ 违反里氏替换原则classBird{public:virtualvoidfly(){/* 飞行 */}};classPenguin:publicBird{public:voidfly()override{throwstd::runtime_error("Penguins can't fly!");}};// ✅ 正确的设计classBird{/* 基类不包含fly */};classFlyingBird:publicBird{public:virtualvoidfly()=0;};classSparrow:publicFlyingBird{/* 可以飞 */};classPenguin:publicBird{/* 企鹅只是鸟，不会飞 */};实际经验：
- 子类不应该覆盖父类的非抽象方法
- 子类可以有更严格的前置条件，但必须有更宽松的后置条件
3.4 接口隔离原则（Interface Segregation Principle, ISP）
定义：客户端不应该依赖它不需要的接口。
核心思想：提供尽可能小的单独接口，而不要提供大的总接口。将一个大接口分解为多个小接口。
// ❌ 违反接口隔离原则classIWorker{public:virtualvoidwork()=0;virtualvoideat()=0;};// ✅ 遵循接口隔离原则classIWorkable{public:virtualvoidwork()=0;};classIFeedable{public:virtualvoideat()=0;};classWorker:publicIWorkable,publicIFeedable{// 实现工作接口voidwork()override{/* ... */}// 实现进食接口voideat()override{/* ... */}};classRobot:publicIWorkable{// 机器人只需要工作，不需要进食voidwork()override{/* ... */}};实际经验：
- 接口的粒度要适中，太大会导致实现类被迫实现不需要的方法，太小会导致接口数量爆炸
- 一个接口只服务于一个子模块或业务逻辑
3.5 依赖倒置原则（Dependency Inversion Principle, DIP）
定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
核心思想：面向接口编程。当模块A需要用到模块B的功能时，应当通过一个接口来使用B，而不是直接使用B的实现。
// ❌ 违反依赖倒置原则classMySQLDatabase{public:voidsave(string data){/* MySQL存储 */}};classUserService{MySQLDatabase*db;// 直接依赖具体实现public:voidsaveUser(string data){db->save(data);}};// ✅ 遵循依赖倒置原则classIDatabase{public:virtualvoidsave(string data)=0;virtual~IDatabase()=default;};classMySQLDatabase:publicIDatabase{public:voidsave(string data)override{/* MySQL存储 */}};classPostgreSQLDatabase:publicIDatabase{public:voidsave(string data)override{/* PostgreSQL存储 */}};classUserService{IDatabase*db;// 依赖抽象接口public:UserService(IDatabase*database):db(database){}voidsaveUser(string data){db->save(data);}};实际经验：
- 依赖注入是实现依赖倒置原则的常用手段
- 通过构造函数、setter方法或接口传递依赖
四、设计模式与SOLID原则的关系
设计模式是SOLID原则的具体应用，每种设计模式都体现了某些SOLID原则。
| 设计模式 | 体现的SOLID原则 |
|---|---|
| 工厂模式 | 依赖倒置原则、开闭原则 |
| 单例模式 | 单一职责原则 |
| 策略模式 | 开闭原则、单一职责原则 |
| 观察者模式 | 开闭原则、依赖倒置原则 |
| 适配器模式 | 开闭原则、接口隔离原则 |
| 装饰器模式 | 开闭原则、单一职责原则 |
| 模板方法模式 | 开闭原则 |
💡 理解要点
- 设计模式是手段，原则是目的：设计模式是实现设计原则的具体方法
- 灵活应用：不要为了使用设计模式而使用，要根据实际需求选择
- 权衡取舍：设计模式会增加代码复杂度，需要权衡利弊
五、学习建议
📚 推荐学习路径
第一步：理解面向对象基础 → 第二步：学习SOLID原则 → 第三步：学习设计模式 ↓ 第四步：项目实战应用 ↓ 第五步：阅读优秀源码🎯 实践建议
- 从小处着手：先在小型项目中尝试应用设计模式
- 重构现有代码：在代码重构中应用设计模式效果最佳
- 阅读开源项目：学习优秀项目如何使用设计模式
- 画UML图：用类图辅助理解设计模式的结构
- 写技术博客：输出是最好的学习方式
⚠️ 常见误区
| 误区 | 正确理解 |
|---|---|
| 设计模式越多越好 | 根据实际需求选择，过度设计反而有害 |
| 设计生搬硬套 | 理解模式的本质，灵活应用 |
| 忽视简单性 | 简单的代码优于复杂的模式 |
| 只学用法不学原理 | 理解设计原则才能真正掌握设计模式 |
六、总结
设计模式是软件开发的智慧结晶，SOLID原则是面向对象设计的指导思想。掌握它们能够：
- 📈 提高代码质量和可维护性
- 🔄 增强代码的可扩展性和灵活性
- 🤝 提升团队协作效率
- 🎯 培养良好的设计思维
记住：设计模式不是银弹，正确的使用场景和方法才是关键。
参考资料
- C++各类设计模式及实现详解 - 知乎
- 面向对象5个基本原则 - CSDN
- 突破编程_C++_设计模式（策略模式）- CSDN
