深入了解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）
原则如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一类的某一个方法的话，可以通过第三者转发这个调用。
理解应该减少对象之间的直接交互，另外交互的方式也应该基于通用的接口。例如，租户、中介和房东三者之间的关系，租户有事情只需要找中介，房东有事情也只找中介。如此一来，租户有事情不需要又联系中介，又联系房东；房东也是一样。中介本来就是两者的桥梁，减少租户和房东的对外耦合，对外的交互也单一。