️ 设计模式基础与SOLID原则设计模式是软件开发中经过验证的、可复用的解决方案。掌握设计模式能够让我们的代码更加优雅、可维护、可扩展。一、什么是设计模式设计模式Design Pattern是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式的核心思想是在特定环境下解决软件设计中某类通用问题的方案。它不是可以直接复制粘贴的代码而是一种解决问题的思路和方法论。 设计模式的本质价值价值维度说明可复用性避免重复造轮子站在巨人的肩膀上可维护性遵循统一的模式代码结构清晰易懂可扩展性方便添加新功能减少对现有代码的修改沟通效率提供统一的术语团队沟通更高效二、设计模式的三大分类根据设计模式的用途可以将其分为三大类创建型模式、结构型模式和行为型模式。2.1 创建型模式5种创建型模式关注对象的创建过程将对象的创建和使用分离降低系统的耦合度。模式名称核心思想适用场景工厂方法模式定义一个创建对象的接口让子类决定实例化哪一个类需要根据条件创建不同对象抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口需要创建产品族单例模式确保一个类只有一个实例并提供全局访问点配置管理器、连接池、日志对象建造者模式将一个复杂对象的构建与它的表示分离创建复杂对象如配置项较多的对象原型模式通过复制现有对象来创建新对象创建成本较高的对象2.2 结构型模式7种结构型模式关注类和对象的组合通过继承或组合来构建更大的结构。模式名称核心思想适用场景适配器模式将一个类的接口转换成客户希望的另一个接口接口不兼容时进行转换装饰器模式动态地给一个对象添加一些额外的职责不通过继承扩展对象功能代理模式为其他对象提供一种代理以控制对这个对象的访问远程代理、虚拟代理、保护代理外观模式为子系统中的一组接口提供一个一致的界面简化复杂系统的使用桥接模式将抽象部分与实现部分分离使它们都可以独立变化多维度变化的对象组合模式将对象组合成树形结构以表示部分-整体的层次结构树形结构数据处理享元模式运用共享技术有效地支持大量细粒度的对象大量相似对象的共享2.3 行为型模式11种行为型模式关注对象之间的通信、职责划分以及算法的封装。模式名称核心思想适用场景策略模式定义一系列算法把它们一个个封装起来并且使它们可相互替换多种算法可互换模板方法模式定义一个操作中的算法骨架而将一些步骤延迟到子类中固定流程具体步骤可变观察者模式定义对象间一对多的依赖关系当一个对象状态改变时所有依赖它的对象都得到通知事件驱动系统迭代器模式提供一种方法顺序访问一个聚合对象中各个元素而又不需暴露该对象的内部表示遍历集合责任链模式使多个对象都有机会处理请求从而避免请求的发送者和接收者之间的耦合关系多级审批、事件处理链命令模式将一个请求封装为一个对象从而使你可用不同的请求对客户进行参数化撤销/重做操作备忘录模式在不破坏封装性的前提下捕获一个对象的内部状态并在该对象之外保存这个状态撤销操作、游戏存档状态模式允许一个对象在其内部状态改变时改变它的行为状态机实现访问者模式表示一个作用于某对象结构中的各元素的操作数据结构与操作分离中介模式用一个中介对象来封装一系列的对象交互对象间复杂交互解释器模式给定一个语言定义它的文法的一种表示并定义一个解释器SQL解析、正则表达式三、SOLID原则详解SOLID是面向对象设计的五大基本原则的首字母缩写由Robert C. MartinUncle 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 cant 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