美文网首页
23种设计模式总览

23种设计模式总览

作者: 拂去尘世尘 | 来源:发表于2024-03-17 23:30 被阅读0次

    深入了解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种设计模式罗列出来,按需访问:

    创建型模式

    结构型模式

    行为型模式

    相关文章

      网友评论

          本文标题:23种设计模式总览

          本文链接:https://www.haomeiwen.com/subject/ueyazdtx.html