设计模式一词在软件工程领域具有精确的学术定义。1994年，Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides合著了《设计模式：可复用面向对象软件的基础》一书，四位作者被业界尊称为"四人组"（Gang of Four，缩写GoF）。该书系统总结了面向对象软件设计中反复出现的二十三套解决方案，并按各自解决的核心问题将其划分为三大类别——创建型模式、结构型模式和行为型模式。这便是软考中反复考查的"GoF 23种设计模式"的学科起源。
设计模式的本质不是代码模板，而是一套经过验证的命名约定和设计经验。每一个设计模式包含四个基本要素：模式名称、问题描述、解决方案和效果评估。模式名称提供开发者之间沟通的共享词汇；问题描述指明适用场景和前置条件；解决方案给出参与类的角色分工与协作关系；效果评估分析使用该模式后在灵活性、可扩展性和可维护性等维度的得失。理解这四个要素比记住某种模式的具体类图更为关键，因为软考命题人极少让你手绘完整类图，而是倾向于考察模式识别、分类归属以及场景选型能力。
在软考考纲体系中，设计模式同时出现在软件设计师（中级）和系统架构设计师（高级）两个科目的上午选择题和下午案例题中。中级侧重单种设计模式的意图识别和简单场景匹配，高级在此基础上增加模式组合运用、模式与架构风格的关系以及模式在特定质量属性场景下的选型论证。一个知识点跨越中高级两套试卷，足以说明其在软考知识体系中的枢纽地位。
很多人把设计模式当作孤立的知识点去背，效率低下。设计模式的底层驱动力是面向对象设计的七大原则——单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、合成复用原则和迪米特法则。每一个设计模式本质上都是这些原则在特定场景下的具体实现。策略模式是对开闭原则的直接体现——通过定义策略接口，新增算法无需修改原有代码；装饰器模式则同时贯彻了单一职责原则（每个装饰器只负责一种增强）和合成复用原则（通过对象组合而非继承来扩展功能）。备考设计模式的最佳策略不是孤立记忆二十三种模式的类图和意图，而是首先理解七大设计原则的核心思想，然后逐一追问：这种模式解决的是哪一条原则在哪个场景下的落地问题？这样，二十三套方案就不再是二十三座孤岛，而是由共同原则串联起来的有机体系。
从近五年软考真题统计来看，设计模式是上午选择题的稳定考点，平均每套卷出现二至四道设计模式相关题目，总分值四至八分。中级软件设计侧重：给定一段场景描述，判断该用哪一种设计模式；或给出类图和模式名称，判断属于创建型、结构型还是行为型。高级系统架构设计师则更多地考察模式在架构层面的组合运用，比如"在基于管道-过滤器风格的系统中，每个过滤器内部适合采用哪种设计模式来解耦算法与调用者"，这类题目要求你不仅知道一种模式的定义，还要理解模式与架构风格之间的适配关系。无论中级还是高级，三大分类的归属判断永远是最基础的得分点——你可以不知道桥接模式和适配器模式的具体区别，但你必须知道它们都属于结构型模式，否则后续的模式选型判断几乎不可能做对。
设计模式之所以被分为三大类，不是GoF随意拍脑袋的产物，而是基于一个清晰且可验证的分类标准：该模式解决的核心矛盾落在面向对象设计的哪一个维度上。理解这个标准，是区分三大分类的唯一可靠路径。
创建型模式的核心矛盾是"谁来创建对象、在什么时机创建对象、创建出来的对象长什么样子"。在面向对象编程中，用new关键字直接实例化具体类带来了两个根本性问题：第一，调用方与具体类之间形成编译期强耦合，任何具体类的变更都会波及所有调用方；第二，复杂对象的构建过程分散在调用方各处，缺乏统一管理和复用机制。
创建型模式的五套方案——单例模式、工厂方法模式、抽象工厂模式、建造者模式和原型模式——各自从不同角度切入了同一套底层矛盾。单例模式控制实例数量，确保全局只有一个对象实例；工厂方法模式将实例化决策推迟到子类，使调用方依赖抽象接口而非具体产品类；抽象工厂模式进一步扩展这个思路，将一组相关产品的创建集中到一个工厂接口中，确保产品族的一致性；建造者模式将复杂对象的构建过程从对象本身的类定义中分离出来，使同一套构建流程可以产出不同表示的产品；原型模式完全绕开构造函数的调用路径，通过克隆原型实例来创建新对象，适用于对象创建成本远高于复制成本的场景。五套方案的共同底层逻辑都是"解耦对象的创建与使用"，只不过各自的边界条件不同。
结构型模式的核心矛盾是"如何将现有的类或对象组合成更大的结构，同时保持灵活性和可维护性"。如果说创建型模式关注的是对象的"生"，那么结构型模式关注的是对象之间的"关系"——继承关系、组合关系、聚合关系和依赖关系。在大型面向对象系统中，类的数量成百上千，它们之间的依赖关系如果管理不善，很快就会演变成一张无法维护的网状依赖图。
结构型模式的七套方案——适配器模式、桥接模式、组合模式、装饰器模式、外观模式、享元模式和代理模式——本质上是对类与类之间依赖关系的七种优化策略。适配器模式解决接口不兼容问题，通过引入适配器类将现有不兼容接口转换为客户端期望的接口。桥接模式的核心贡献在于将抽象部分与实现部分分离，使两者可以独立变化，直接回应了"继承层次横向膨胀"的经典设计困境。组合模式提供将对象组织为树形结构的统一方式，使客户端可以一致地处理单个对象和组合对象。装饰器模式通过对象组合而非继承动态地为对象添加职责，在运行时灵活性和编译期安全性之间取得精妙平衡。外观模式为复杂子系统提供统一高层接口，降低客户端与子系统的耦合度。享元模式通过共享细粒度对象支持大规模对象的高效使用。代理模式为另一个对象提供替身或占位符以控制对该对象的访问。
行为型模式是三大分类中数量最多的，共十一套方案。这不仅是数量上的偶然，更深层的原因是：对象之间的交互协作是面向对象设计中最复杂、变化最频繁的维度，需要最丰富的设计工具箱来应对。
行为型模式关注的核心矛盾是"算法、职责和通信如何在对象之间分配"。在面向对象系统中，完成一个业务功能往往需要多个对象协作。如果不加设计地随意分配职责，就会出现两个极端：要么职责过度集中形成"上帝类"，单个类承担过多不相关的职责；要么职责过度分散，一个简单的业务逻辑被肢解到十几个类中。行为型模式的十一套方案——责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式和访问者模式——就是十一套经过验证的职责分配与算法封装策略。从底层机制来看，行为型模式可进一步分为基于继承的（如模板方法模式）和基于对象组合的（如策略模式）两类，理解这一层区分有助于从更底层把握模式的本质。
创建型模式共五种。单例模式确保一个类只有一个实例，并提供一个全局访问点，软考考查重点是线程安全的懒汉式实现与饿汉式实现的区别。建造者模式将一个复杂对象的构建与它的表示分离，使同样的构建过程可以创建不同的表示，软考经常将它与抽象工厂模式放在一起辨析——关键区别在于建造者关注构建步骤的顺序和灵活性，抽象工厂关注产品族的一致性。工厂方法模式定义一个用于创建对象的接口，让子类决定实例化哪一个类。抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无需指定具体类。原型模式用原型实例指定创建对象的种类并通过拷贝原型创建新对象，软考中常与"深拷贝和浅拷贝的区别"绑定考查。
五种创建型模式的适用场景可以这样记忆：需要全局唯一实例时选单例；需要将对象的创建和使用解耦但产品类型单一确定时选工厂方法；产品类型会扩展成多个变体且存在一致性约束时选抽象工厂；对象构建过程本身很复杂需分步骤灵活配置时选建造者；创建成本远高于复制成本时选原型。
结构型模式共七种，是三大分类中"视觉上"最直观的一类，绝大多数结构型模式可通过类图清晰展示参与类之间的组合或继承关系，是软考命题人最偏爱的出题素材之一。
适配器模式将类接口转换成客户希望的另一个接口。桥接模式将抽象部分与实现部分分离，使两者都可以独立变化。组合模式将对象组合成树形结构以表示"部分—整体"的层次结构。装饰器模式动态地给对象添加额外职责，比生成子类更灵活。外观模式为子系统中的一组接口提供一致界面。享元模式运用共享技术有效支持大量细粒度对象。代理模式为其他对象提供一种代理以控制
本篇完！