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

本文涉及的产品
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
性能测试 PTS,5000VUM额度
简介: 《深入了解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种设计模式罗列出来,按需访问:

创建型模式

结构型模式

行为型模式

相关文章
|
设计模式 关系型数据库
【设计模式——学习笔记】设计模式简介+七大设计原则介绍(下)
【设计模式——学习笔记】设计模式简介+七大设计原则介绍
138 0
|
7月前
|
设计模式 XML Java
第五篇 设计模式的选择和应用 - 智慧选择与合理实践
第五篇 设计模式的选择和应用 - 智慧选择与合理实践
|
4月前
|
设计模式
设计模式简介
设计模式简介
|
7月前
|
设计模式 算法 Java
设计模式实战
**设计模式的应用与案例** 设计模式是解决常见软件设计问题的最佳实践,有助于提升代码质量和可维护性。有效利用设计模式的步骤包括:理解业务需求、识别问题、选择合适模式、学习研究和适时调整。在实际工作中,例如,通过结合工厂模式和策略模式,解决了多端页面配置筛选逻辑,避免接口爆炸;使用模板方法模式,将复杂业务逻辑拆分为可复用步骤,提高了代码扩展性。设计模式虽好,但应适度,避免过度复杂化。
60 1
|
设计模式 Java 程序员
【设计模式——学习笔记】设计模式简介+七大设计原则介绍(上)
【设计模式——学习笔记】设计模式简介+七大设计原则介绍
59 2
|
设计模式 开发框架 Java
设计模式简介【Java设计模式】
设计模式简介【Java设计模式】
86 0
|
设计模式 算法 关系型数据库
设计模式 | 开篇简介
模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案。
110 1
设计模式 | 开篇简介
|
设计模式 C++
设计模式简介
设计模式简介
83 0
|
设计模式 算法
设计模式入门
设计模式入门
设计模式入门
|
设计模式 JSON 资源调度
设计模式之实战(8-1)
设计模式之实战(8-1)
225 0