【实战指南】深入了解23种设计模式

本文涉及的产品
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,182元/月
简介: 《深入了解23种设计模式:程序员必读指南》旨在帮助程序员理解和应用设计模式,以解决常见编程问题。书中介绍了设计模式的起源、目的及其在提高代码复用性、质量和团队沟通中的作用。涵盖创建型、结构型和行为型三大类共23种设计模式,每种模式均附有详细解析与C++实现示例,适合初学者和有经验的开发者学习参考。

深入了解23种设计模式:程序员必读指南

引言

  随着编码时间拉长,遇到的问题增加,发现设计模式对于解决某类场景问题确实帮助很大。其实在不了解设计模式之前,其设计思想也已经在日常开发中有所体现,只是没有总结出来。设计模式像是经验老道的程序员将他的编程经验毫无保留的开源,引导新手更好的处理某一类问题。

  之前我发布了一系列关于设计模式的文章。通过总结这个系列,有助于以后回顾和修改。如果用C++来实现所有的设计模式,将会显著提升C++编程能力,是入门的好方法。

概述

  为什么会有一系列设计模式的产生,而且还有23种? 总结主要有以下几点:

  • 代码复用
    在软件开发过程中,经常会遇到相似的问题需要解决。设计模式通过提供一套经过验证的解决方案,可以帮助开发者更高效地重用代码,减少重复工作,提高开发效率。

  • 经验总结
    软件行业经验丰富的开发者在解决问题时积累了大量的经验和技巧,设计模式可以将这些经验进行抽象、总结和归纳,从而为其他开发者提供参考和指导。

  • 代码质量
    设计模式能够帮助开发者编写具有良好结构和可维护性的代码。它们提供了一种被广泛认可的最佳实践,可以避免一些常见的设计错误,并促进代码的质量和可读性。

  • 沟通和传递知识
    设计模式为开发者之间的沟通提供了共享的词汇和方法。它们使得开发者能够更容易地理解、讨论和交流关于软件设计的话题,促进团队合作和知识传递。

  以上是设计模式的目的,主要是为了提升代码质量,方便项目的维护和扩展。但需要注意的是,使用设计模式的前提是对业务场景了然于心;若没有吃透业务,而贸然使用设计模式反而会适得其反,让自己困于设计模式中,束手束脚。另外,设计模式并不是万能的,它只是为解决某一类场景提供一种编程思路,使用它应该是顺理成章,而非生搬硬套。

  另外,设计模式并不是架构设计。两者侧重点不一样,架构设计关注的是层次结构、模块划分、数据流动、组件间协作等各个方面;设计模式则更多地关注于局部问题的解决方案,例如如何更好地组织对象、如何实现松耦合、如何应对变化等。可以说,设计模式是架构设计的一种工具。

基本原则

  说到底设计模式只是一种编程思路和一套通用解决方案,既然是编程那么它也是遵循一套编程原则的。理解它遵循的原则,能够方便我们更容易理解每一种设计模式;同时,对于日常开发也裨益匪浅。

  • 单一职责原则(Single Responsibility Principle, SRP)
    原则 一个类应该有且仅有一个引起它变化的原因。
    理解 单一职责原则要求一个类或模块应该只负责一项功能或责任。如果一个类承担了多个不同的职责,那么对其中一个职责的修改可能会影响其他职责的实现,导致代码的复杂性增加、可维护性下降。

  • 开闭原则(Open Closed Principle, OCP)
    原则 软件实体(类、模块、函数等)应该对扩展开放,对修改封闭。
    理解 开闭原则要求不要修改现有的代码,只允许增加扩展。这就要求在设计初要考虑清楚当前模块业务功能,保证每个接口独立可复用,一旦项目闭环,此接口就不应该再有调整,避免引入新的问题。(个人理解,这是比较理想的状态。在实际开发中为了兼容新增的功能,同时避免增加功能类似的多余接口,往往会调整现有的接口)

  • 里氏替换原则(Liskov Substitution Principle, LSP)
    原则 一个父类的实例应该能够被其子类所替换,而不影响程序的正确性。
    理解 里氏替换原则的关键在于正确使用继承。子类需要符合父类所定义的行为,同时子类可以在保持父类行为的基础上增加新的行为。父类是为派生类提供功能定义,至于怎么实现,不同的子类有不同的方案。(例如一套中间件可运行在不同的平台上,就源于各个平台(子类)按照自己的方式实现了中间件一套标准的父类接口)

  • 依赖倒置原则(Dependence Inversion Principle, DIP)
    原则 高层模块不应该依赖于低层模块,它们都应该依赖于抽象。
    理解 高层模块应该依赖于抽象接口或抽象类,而不是具体的低层模块。如此设计,方便了抽象,同时也能定义出一套职责清晰的功能接口。接口实现也不用担心高层的逻辑,只用专注自身的功能。

  • 接口隔离原则(Interface Segregation Principle, ISP)
    原则 客户端不应该依赖它不需要的接口
    理解 在设计对外接口时,功能应尽可能的单一和细微。避免客户端在调用一个接口时,接口的内部又调用了其他无关功能。(举个例子,打开电视,我只想看CCTV直播,但是开机界面总是推荐的付费电视剧,为此我要通过遥控器点击一系列的按键才能进入CCTV直播。应该单独定义付费电视剧和直播的快捷入口,需要时我会选择;而并非想看直播,必须要先看一堆不喜欢的推荐页面。当然这是一种引导消费的手段,无可厚非)

  • 迪米特法则(Law of Demeter, LoD)
    原则 如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一类的某一个方法的话,可以通过第三者转发这个调用。
    理解 应该减少对象之间的直接交互,另外交互的方式也应该基于通用的接口。例如,租户、中介和房东三者之间的关系,租户有事情只需要找中介,房东有事情也只找中介。如此一来,租户有事情不需要又联系中介,又联系房东;房东也是一样。中介本来就是两者的桥梁,减少租户和房东的对外耦合,对外的交互也单一。

设计模式总览

将之前输出的23种设计模式罗列出来,按需访问:

创建型模式

结构型模式

行为型模式

相关文章
|
6月前
|
设计模式 消息中间件 监控
并发设计模式实战系列(5):生产者/消费者
🌟 ​大家好,我是摘星!​ 🌟今天为大家带来的是并发设计模式实战系列,第五章,废话不多说直接开始~
186 1
|
6月前
|
设计模式 监控 Java
并发设计模式实战系列(8):Active Object
🌟 大家好,我是摘星!🌟今天为大家带来的是并发设计模式实战系列,第8章,废话不多说直接开始~
112 0
并发设计模式实战系列(8):Active Object
|
2月前
|
设计模式 人工智能 算法
基于多设计模式的状态扭转设计:策略模式与责任链模式的实战应用
接下来,我会结合实战案例,聊聊如何用「策略模式 + 责任链模式」构建灵活可扩展的状态引擎,让抽奖系统的状态管理从「混乱战场」变成「有序流水线」。
|
6月前
|
设计模式 负载均衡 监控
并发设计模式实战系列(2):领导者/追随者模式
🌟 ​大家好,我是摘星!​ 🌟今天为大家带来的是并发设计模式实战系列,第二章领导者/追随者(Leader/Followers)模式,废话不多说直接开始~
163 0
|
6月前
|
设计模式 监控 Java
并发设计模式实战系列(1):半同步/半异步模式
🌟 ​大家好,我是摘星!​ 🌟今天为大家带来的是并发设计模式实战系列,第一章半同步/半异步(Half-Sync/Half-Async)模式,废话不多说直接开始~
151 0
|
6月前
|
设计模式 运维 监控
并发设计模式实战系列(4):线程池
需要建立持续的性能剖析(Profiling)和调优机制。通过以上十二个维度的系统化扩展,构建了一个从。设置合理队列容量/拒绝策略。动态扩容/优化任务处理速度。检查线程栈定位热点代码。调整最大用户进程数限制。CPU占用率100%
396 0
|
6月前
|
设计模式 消息中间件 监控
并发设计模式实战系列(3):工作队列
🌟 ​大家好,我是摘星!​ 🌟今天为大家带来的是并发设计模式实战系列,第三章,废话不多说直接开始~
136 0
|
6月前
|
设计模式 存储 安全
并发设计模式实战系列(7):Thread Local Storage (TLS)
🌟 大家好,我是摘星! 🌟今天为大家带来的是并发设计模式实战系列,第七章Thread Local Storage (TLS),废话不多说直接开始~
188 0
|
6月前
|
消息中间件 设计模式 监控
并发设计模式实战系列(9):消息传递(Message Passing)
🌟 大家好,我是摘星!🌟今天为大家带来的是并发设计模式实战系列,第九章,废话不多说直接开始~
108 0
|
6月前
|
设计模式 安全 NoSQL
并发设计模式实战系列(10):Balking(犹豫模式)
🌟 大家好,我是摘星!🌟今天为大家带来的是并发设计模式实战系列,第10章,废话不多说直接开始~
60 0