工程模式有哪些

工程模式是指软件开发中用于解决常见设计问题的可复用方案，它涵盖了创建型、结构型和行为型三大类别，具体包括工厂方法、单例、适配器、观察者等二十多种经典模式，掌握这些模式能帮助开发者构建更灵活、可维护的代码系统。

       在软件开发的世界里，你是否曾面对过复杂的代码结构而感到无从下手？或者，你是否希望找到一种经过验证的方法，来让你的程序设计更加优雅和高效？今天，我们就来深入探讨一个在编程领域至关重要的话题：工程模式有哪些。理解并运用这些模式，就像是获得了一张精心绘制的地图，它能引导你在构建软件时避开常见的陷阱，直达清晰、可维护的设计彼岸。

       工程模式有哪些？

       要回答“工程模式有哪些”这个问题，我们首先需要明确，这里所说的“工程模式”通常指的是在软件工程领域被广泛认可和使用的设计模式。它们不是具体的代码片段，而是一种高级的、可复用的解决方案模板，用于应对在软件设计中反复出现的特定问题。这些模式经过数十年的实践提炼，由“四人帮”（Gang of Four）在其经典著作中系统归纳，主要分为三大类：创建型模式、结构型模式和行为型模式。每一类都包含多个具体的模式，共同构成了一个强大的工具箱。接下来，我们将逐一展开，详细解读这些模式的内涵、应用场景以及它们如何在实际项目中大放异彩。

       第一基石：创建型模式——掌控对象的诞生

       创建型模式的核心关注点是如何创建对象，它们将对象的创建过程封装起来，使得系统在创建对象时具有更大的灵活性和可控制性，从而降低代码之间的耦合度。这类模式就像是负责“生产”的智能工厂，它决定了产品以何种方式、在何时、由谁来制造。

       首先，工厂方法模式定义了一个用于创建对象的接口，但让子类决定实例化哪一个类。这意味着，当你需要增加新的产品类型时，无需修改现有的客户端代码，只需添加新的工厂子类即可。例如，在一个图形编辑器中，你可能有一个“形状”抽象类和“圆形”、“矩形”等具体类。工厂方法模式允许你通过一个“形状工厂”接口来创建这些形状，而具体的创建逻辑则由“圆形工厂”、“矩形工厂”来实现。这种做法极大地增强了系统的可扩展性。

       其次，抽象工厂模式提供了一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。这比工厂方法模式更进一步，它关注的是产品家族。设想你在开发一款支持多种视觉主题的应用程序，比如“暗黑模式”和“明亮模式”。抽象工厂模式可以定义一个“界面主题工厂”接口，然后由“暗黑主题工厂”和“明亮主题工厂”分别负责创建一套配套的按钮、文本框、对话框等界面元素。这样，切换整个主题就变得异常简单。

       再者，建造者模式将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。它特别适用于构建过程复杂、步骤繁多，且最终产品可能有多种表现形式的场景。以制作一份复杂的套餐订单为例，订单包含主食、饮料、甜点等多个部分，且每种部分都有多种选择。建造者模式允许你通过一个“订单建造者”来一步步添加这些部件，最终返回一个完整的订单对象。这种方式使得创建过程清晰，并且可以轻松地构造出不同配置的订单。

       接着，原型模式通过复制现有的原型实例来创建新的对象，而不是通过新建类的方式。当直接创建对象的成本较高（例如，需要复杂的数据库操作或网络请求来初始化），或者系统需要动态地配置运行时对象时，原型模式就非常有用。在游戏开发中，创建一个拥有复杂属性和状态的游戏角色可能非常耗时。如果游戏中需要大量相似但略有差异的角色，使用原型模式，先创建一个基础角色作为原型，然后通过克隆并微调属性的方式来快速生成新角色，效率会高得多。

       最后，单例模式确保一个类只有一个实例，并提供一个全局访问点。这是最广为人知的模式之一，常用于管理共享资源，如数据库连接池、线程池、应用程序的配置管理器或日志记录器。通过严格控制实例数量，单例模式可以避免资源冲突和浪费，保证状态的一致性。然而，它也需谨慎使用，过度依赖单例可能导致代码的全局状态难以测试和维护。

       第二支柱：结构型模式——搭建对象的骨架

       如果说创建型模式关注的是对象的“出生”，那么结构型模式关注的就是对象如何“组合”在一起，形成更大、更复杂的结构。它们通过识别简单对象之间简单而有效的关系，来简化设计，提升系统的灵活性和可复用性。

       适配器模式就像是一个电源转接头，它允许接口不兼容的类能够一起工作。它通过将一个类的接口转换成客户期望的另一个接口来实现这一点。例如，你有一个新的日志系统，但其接口与旧系统中期望的日志接口不同。这时，你可以编写一个适配器类，它实现旧系统期望的接口，但在内部调用新日志系统的功能。这样，旧系统的代码无需任何修改就能无缝使用新系统。

       桥接模式将抽象部分与其实现部分分离，使它们可以独立地变化。这解决了在多层继承结构中可能出现的类爆炸问题。考虑一个图形渲染的例子，你有多种形状（圆形、方形）和多种渲染方式（矢量渲染、光栅渲染）。如果为每一种“形状-渲染方式”组合都创建一个子类，类数量会急剧膨胀。使用桥接模式，你可以将“形状”作为抽象部分，将“渲染器”作为实现部分，两者通过一个桥接接口关联。这样，新增一种形状或一种渲染方式，都只需要增加一个类，系统结构变得非常清晰。

       组合模式允许你将对象组合成树形结构来表示“部分-整体”的层次结构，使得客户端可以统一地对待单个对象和组合对象。文件系统是组合模式的经典例子。文件和文件夹都可以被视为“文件系统条目”。文件夹可以包含文件，也可以包含其他文件夹。通过组合模式，无论是针对单个文件执行操作（如删除），还是对整个文件夹及其所有内容执行操作，客户端都可以使用同一套接口，这极大地简化了客户端代码。

       装饰器模式动态地给一个对象添加一些额外的职责，它提供了一种比继承更灵活的扩展功能的方式。想象一下，你有一杯基础的咖啡。你可以通过添加“加糖装饰器”、“加奶装饰器”、“加奶油装饰器”来动态地组合出摩卡、拿铁等不同口味的咖啡，而无需为每一种可能的组合创建单独的子类。装饰器模式保持了类的单一职责原则，同时提供了无限的功能组合可能性。

       外观模式为子系统中的一组接口提供了一个统一的高层接口，使得子系统更容易使用。它相当于一个接待前台，将内部复杂的业务流程封装起来，对外提供一个简单的入口。例如，启动一台计算机涉及加载引导程序、初始化硬件、启动操作系统服务等一系列复杂步骤。对于普通用户，他们只需要按下电源键（调用外观接口），而无需关心内部具体发生了什么。这降低了系统与外界的耦合度。

       享元模式运用共享技术来有效地支持大量细粒度的对象。其核心是分离对象的内部状态（可共享）和外部状态（不可共享）。在文本编辑器中，每个字符对象如果都包含字体、大小、颜色等信息，内存消耗会非常大。享元模式可以创建一个“字符享元工厂”，它共享字符的字体、大小等内部状态，而字符在文本中的位置（行、列）则作为外部状态在使用时传入。这样，无论文档多长，相同字体的‘A’字在内存中只存在一份。

       代理模式为另一个对象提供一个替身或占位符以控制对这个对象的访问。代理可以在客户端和目标对象之间起到中介作用，用于实现延迟加载（虚拟代理）、访问控制（保护代理）、远程通信（远程代理）或智能引用等。例如，在加载一个高清大图时，可以先显示一个低分辨率的占位符（虚拟代理），同时后台线程加载真实图片，加载完成后再替换，从而提升用户体验。

       第三维度：行为型模式——协调对象的交互

       行为型模式专注于对象之间的职责分配和通信方式。它们定义了对象之间如何交互，以及如何将算法或行为在对象间进行分配，从而使得系统在对象交互层面保持灵活和可维护。

       责任链模式使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。审批流程是典型的例子：一个报销申请可能依次经过组长、部门经理、财务总监的审批，每个审批者只处理自己权限范围内的金额，如果超出则传递给下一级。这使审批逻辑可以灵活地增减或调整顺序。

       命令模式将请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化，支持请求的排队、记录、撤销等操作。在图形用户界面中，每一个菜单项（如“复制”、“粘贴”）背后都可以关联一个命令对象。当用户点击菜单时，并不是直接执行操作，而是执行该命令对象的“执行”方法。这使得实现“撤销/重做”功能变得简单：只需记录下执行过的命令对象序列，撤销时调用其“撤销”方法即可。

       解释器模式给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。它适用于需要解释执行简单语言的场景，如正则表达式、SQL语句解析、数学公式计算器等。虽然应用场景相对特定，但在这些领域内，它能提供非常优雅的解决方案。

       迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。这是现代编程语言中集合遍历的基础。通过提供统一的迭代器接口，客户端可以用相同的方式遍历数组、链表、树等不同结构的集合，极大地增强了代码的通用性。

       中介者模式用一个中介对象来封装一系列对象之间的交互，使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。在一个复杂的对话框窗体中，可能有多个复选框、文本框、按钮相互关联（例如，勾选某个复选框会禁用另一个文本框）。如果让每个控件都直接引用和操作其他控件，关系会错综复杂。引入一个“对话框中介者”来集中管理这些交互逻辑，可以使每个控件只与中介者通信，大大简化了依赖网络。

       备忘录模式在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便以后可以将该对象恢复到原先保存的状态。文本编辑器的“撤销”功能、游戏的存档功能都是备忘录模式的体现。它有效地实现了状态备份与恢复，且保持了原对象的数据封装性。

       观察者模式定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这是实现事件驱动系统的核心模式。例如，在数据模型（被观察者）和多个用户界面视图（观察者）之间，当模型数据变化时，所有相关的视图都会自动刷新以显示最新数据。消息队列、发布订阅系统都可视为观察者模式的延伸。

       状态模式允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。它将与特定状态相关的行为局部化，并将不同状态的行为分割开来。自动售货机是一个好例子：它有“等待投币”、“已投币”、“售出货物”、“缺货”等多种状态。使用状态模式，可以为每一种状态定义一个类，售货机的行为（如按按钮）会根据当前状态对象的不同而执行不同的逻辑，避免了在代码中使用大量的条件判断语句。

       策略模式定义了一系列算法，并将每一个算法封装起来，使它们可以相互替换。策略模式让算法的变化独立于使用算法的客户。在支付系统中，你可能支持支付宝、微信支付、银行卡等多种支付方式。通过策略模式，将每种支付的具体算法封装成独立的策略类，支付上下文对象只需持有一个当前策略的引用。当需要新增一种支付方式或更换支付方式时，变得非常灵活和方便。

       模板方法模式在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些特定步骤。这提供了很好的代码复用平台。例如，一个数据报表生成流程可能包含“获取数据”、“处理数据”、“格式化输出”三个固定步骤。模板方法模式可以在父类中固定这个流程，而子类可以分别实现从数据库、从文件或从网络“获取数据”的具体细节。

       访问者模式表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。当需要对一个复杂对象结构（如由多种节点组成的语法树）执行多种不相关的操作（如类型检查、代码优化、生成文档）时，访问者模式非常有用。它将操作与对象结构分离，新增一种操作只需新增一个访问者类，而无需修改原有的各个节点类。

       综上所述，从对象的创建、组合到交互，这二十多种经典的工程模式为我们提供了一套完整的、经过实战检验的解决方案库。它们不是僵化的教条，而是启发设计灵感的工具。真正掌握这些模式，不在于死记硬背其定义，而在于理解其背后“封装变化”、“面向接口编程”、“组合优于继承”等核心设计原则，并在适当的场景下灵活运用。当你下次面对设计难题时，不妨想一想：在丰富的工程模式宝库中，是否有哪一把钥匙，能够优雅地开启眼前这把锁？这将使你的软件设计之旅更加从容和高效。