有多少种设计模式

设计模式是软件工程中解决常见问题的经典方案，其数量并非一成不变。本文将系统梳理设计模式的核心分类与具体数量，涵盖创建型、结构型、行为型三大经典类别及其包含的二十三种模式。同时，文章将深入探讨模式数量的动态性，包括特定领域模式、架构模式以及现代框架中的模式演变，旨在为开发者提供一个全面、权威且实用的设计模式认知框架。

       在软件开发的宏大世界里，我们常常会遇到一些似曾相识的问题。无论是创建对象时遇到的复杂依赖，还是组织类与对象时面临的僵化结构，亦或是对象间交互时的复杂通信，总有一些挑战会反复出现。经验丰富的开发者们发现，针对这些反复出现的问题，存在着一些经过时间考验、优雅且高效的解决方案。这些解决方案，就是我们今天要深入探讨的主题——设计模式。

       那么，一个最直接的问题便是：到底有多少种设计模式？这个看似简单的问题，答案却并不简单。它不是一个固定的数字，而是一个随着软件工程思想演进、技术领域拓展而不断丰富的知识体系。要理清这个问题，我们需要从设计模式的起源、经典分类以及后续发展等多个维度来构建一个完整的认知图景。

一、设计模式的起源与核心价值

       设计模式的概念并非凭空产生。其思想根源可以追溯到建筑领域。上世纪七十年代，建筑学家克里斯托弗·亚历山大在其著作《建筑的永恒之道》中提出，城镇、建筑乃至房间的构造，都可以通过一系列描述问题和解决方案核心的模式来指导。这一思想深深影响了计算机科学界。

       真正将设计模式概念引入并系统化到软件工程领域的，是埃里希·伽玛、理查德·赫尔姆、拉尔夫·约翰逊和约翰·弗利赛德斯四位学者，他们常被合称为“四人组”。他们在1994年出版的著作《设计模式：可复用面向对象软件的基础》中，系统性地总结了二十三种面向对象设计模式，并为其建立了完整的描述框架。这本书被誉为软件设计模式的里程碑，其中定义的二十三种模式也成为了最经典、最广为人知的核心集合。这些模式的价值在于，它们命名、抽象并记录了面向对象设计中专家们的经验与智慧，使得开发者能够使用一种共通的“语言”来讨论和设计软件结构，极大地提升了代码的可复用性、可维护性和可理解性。

二、经典二十三种模式：三大支柱的分类体系

       “四人组”提出的二十三种模式，根据其目的被清晰地划分为三大类别：创建型模式、结构型模式和行为型模式。这种分类方式逻辑清晰，至今仍是理解设计模式的主干框架。

       第一类：创建型模式。这类模式专注于对象创建机制，旨在将对象的创建与使用分离，使系统在创建何种对象、何时创建以及如何创建方面更具灵活性。它包含了五种具体模式。工厂方法模式定义了一个创建对象的接口，但由子类决定实例化哪一个类。抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。建造者模式将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。原型模式用原型实例指定创建对象的种类，并通过复制这个原型来创建新的对象。单例模式确保一个类只有一个实例，并提供一个全局访问点。

       第二类：结构型模式。这类模式关注如何组合类或对象以形成更大、更复杂的结构。它们通过继承或组合的方式，简化了不同部分之间的依赖关系，提升了系统的可扩展性。这类模式共有七种。适配器模式将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。桥接模式将抽象部分与它的实现部分分离，使它们都可以独立地变化。组合模式将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。装饰器模式动态地给一个对象添加一些额外的职责，就增加功能来说，它比生成子类更为灵活。外观模式为子系统中的一组接口提供一个一致的界面，定义了一个高层接口，使得这一子系统更加容易使用。享元模式运用共享技术有效地支持大量细粒度的对象。代理模式为其他对象提供一种代理以控制对这个对象的访问。

       第三类：行为型模式。这类模式专注于对象之间的职责分配与通信方式。它们不仅描述对象或类的模式，还描述它们之间的通信模式，旨在使对象间的交互更灵活、更高效。这类模式数量最多，共有十一种。责任链模式使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。命令模式将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化。解释器模式给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。迭代器模式提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。中介者模式用一个中介对象来封装一系列的对象交互，使各对象不需要显式地相互引用。备忘录模式在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。观察者模式定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。状态模式允许一个对象在其内部状态改变时改变它的行为。策略模式定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。模板方法模式定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。访问者模式表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

三、超越二十三种：设计模式体系的动态扩展

       如果认为设计模式的世界仅有这二十三种模式，那便是管中窥豹。经典模式是坚实的基础，但绝非边界。随着软件技术的发展，新的模式不断被识别和总结，设计模式的数量始终处于一个开放和增长的状态。

       首先，在特定的问题领域或技术栈中，会涌现出针对性的设计模式。例如，在企业级应用开发中，马丁·福勒在其著作《企业应用架构模式》中系统总结了数据源架构、对象关系映射、领域逻辑组织、Web表现层等众多模式，如数据映射器、工作单元、领域模型、远程外观等。这些模式专门解决了业务系统开发中的常见架构难题，极大地丰富了设计模式的宝库。

       其次，架构层面的模式与代码层面的模式相辅相成。架构模式处理的是子系统、模块和组件级别的宏观设计问题，例如模型-视图-控制器模式、分层模式、微内核模式、事件驱动架构等。虽然它们与“四人组”的代码设计模式处于不同的抽象层次，但同属“模式”这一伟大思想的范畴，共同构成了软件设计的完整方法论。

       再者，并发编程领域也有一套成熟的设计模式。多线程和并行计算带来了资源竞争、死锁、线程协作等全新挑战。针对这些问题，开发者们总结出了诸如领导者-追随者、线程池、生产者-消费者、读写锁等并发模式，它们是构建高性能、高可靠性并发系统的关键工具。

四、模式与反模式：硬币的两面

       在探讨“有多少种”时，一个有趣且重要的延伸概念是“反模式”。如果说设计模式是常见问题的优秀解决方案，那么反模式则是那些看似有效、实则会导致更多问题的常见糟糕解决方案。了解反模式与了解设计模式同等重要，它能帮助我们识别和避免实践中常见的陷阱。例如，“上帝对象”指一个类承担了过多职责，“硬编码”指将可能变化的配置或数据直接写入代码逻辑，“面条式代码”指程序结构混乱、逻辑纠缠不清。认识这些反模式，能让我们在设计中保持警惕，从而更倾向于选择那些经过验证的正向模式。

五、现代框架与库中的模式实践

       今天，当我们使用各种流行的开发框架和库时，实际上每天都在与设计模式打交道。这些框架本身往往就是多种设计模式的集大成者，同时它们也促使了新模式的形成或经典模式的变体。例如，在Java的Spring框架中，控制反转容器本质上是工厂模式和单例模式的强大实现；其面向切面编程能力体现了代理模式和装饰器模式的思想。在前端领域，React等框架倡导的组件化开发，可以看作是组合模式与观察者模式的深度融合。函数式编程的兴起，也带来了诸如函数组合子、单子等源自函数式范式的模式。因此，学习设计模式，也是深入理解和使用现代开发工具的一把钥匙。

六、设计模式的学习与应用哲学

       面对如此众多的设计模式，初学者很容易陷入“为用模式而用模式”的误区。牢记设计模式的根本目的是解决问题，而非炫耀技巧。模式是工具，不是教条。在应用时，需要深刻理解其意图、动机和适用场景，而不是生搬硬套其结构。一种常见的最佳实践是“重构到模式”，即先编写简单、可工作的代码，然后在识别出代码中的“坏味道”（如重复、僵化、脆弱）时，再考虑引入合适的设计模式进行重构优化。这种从实际问题出发的方式，比直接套用模式更能产生优雅的设计。

七、模式语言的未来演进

       软件技术仍在飞速发展，云计算、人工智能、物联网、区块链等新领域不断提出新的设计挑战。可以预见，在这些领域中，新的模式将持续被挖掘和总结。例如，在微服务架构中，服务发现、熔断器、API网关、事件溯源等已成为公认的架构与设计模式。在机器学习流水线中，数据验证、特征工程、模型评估等步骤也形成了特定的模式化实践。设计模式作为一种记录和传播实践智慧的语言，其词汇库必将随着技术的演进而不断扩充。

八、一种动态发展的智慧结晶

       回到最初的问题：有多少种设计模式？我们现在可以给出一个更全面的回答。其核心基石是“四人组”定义的二十三种经典模式，它们分为创建型、结构型、行为型三大类。然而，这仅仅是开始。数量会随着企业应用模式、并发模式、架构模式以及特定技术领域模式（如反应式模式、云设计模式）的加入而大幅增加。此外，认识反模式也是这个知识体系不可或缺的一部分。

       因此，设计模式的数量不是一个需要死记硬背的静态数字，而是一个代表着软件开发共同体最佳实践不断积累的动态集合。对于开发者而言，重要的不是穷尽所有模式的数量，而是理解模式思维的精髓：识别常见问题，应用经过验证的解决方案，并以一种可共享的语言进行交流和设计。掌握经典模式，保持对新模式的敏感，并懂得在合适的时机灵活运用，这才是设计模式带给我们的真正财富。它让我们的软件设计从一种偶然的艺术，走向一门可以学习、可以交流、可以持续优化的工程学科。