系统架构师模拟题冲刺 03:设计模式 11 道题

设计模式是软件架构长河里沉淀下来的工程哲思，绝非浅尝辄止的概念名词。欲内化其精髓、洞悉其取舍之道，唯有沉心研习、勤加演练习题，在一道道场景考题中辨析优劣、权衡取舍，方能把固化的范式融入思维，在复杂业务架构中游刃有余。

适配器模式把一个类的接口转换成客户所期望的另一个接口，使原本因接口不兼容而无法协同工作的类能够一起工作。它的实现有类适配器与对象适配器两种形态，前者依靠继承，后者依靠组合持有被适配对象，实践中以对象适配器更为常用。装饰器模式在不改变接口的前提下为对象动态添加职责，观察者模式建立一对多的通知依赖，建造者模式分离复杂对象的构造过程与表示，三者都不解决接口不匹配的问题。题干的核心诉求是把一种接口转换为另一种接口且不改动任一方，故选 C。

观察者模式定义对象之间的一对多依赖关系，当主题即被观察者的状态发生改变时，所有依赖它的观察者都会自动收到通知并更新自身。其价值在于把发布方与订阅方解耦：主题只维护一个抽象的观察者集合，无须了解各订阅方的具体类型与数量，新增或移除订阅方都不要求修改主题。选项 A 用于把对象之间的多对多交互收敛到一个中介对象，选项 B 用于让请求沿处理者链依次传递，选项 C 把请求封装为对象以支持排队与撤销，均与题干场景不符。故选 D。

命令模式把请求本身封装为一个对象，命令对象中保存请求的接收者、要执行的操作以及执行所需的参数。请求被对象化之后带来一整套能力：把命令存入列表或队列即可实现撤销与重做，每个命令记录执行前的状态或提供逆操作，按相反顺序调用就能回退；把命令持久化后可用于事务恢复与日志回放；把命令放入线程池即可实现任务的排队与调度。这正是编辑器撤销功能的标准实现方式。选项 A、B、D 均不提供请求的撤销语义。故选 C。

抽象工厂模式提供创建产品族的接口，一个抽象工厂中声明多个创建方法，每个方法负责创建族内的一个产品，每一组具体工厂对应一个具体的产品族。其关键价值在于约束产品之间的配套关系：客户端只持有抽象工厂，选定某一具体工厂后，所有创建请求都落在同一产品族内，因而不可能出现混用不同族产品导致的兼容问题，例如界面风格的一致性与数据库访问部件的同源。工厂方法模式只针对单一产品等级结构，建造者模式关注复杂对象的逐步构造，原型模式通过复制已有实例创建对象，均不保证产品族的配套。故选 A。

单例模式通过私有构造方法与静态方法保证类只有一个实例，并对外提供全局访问点，常用于配置对象、数据库连接池、线程池与日志器这类全系统共享一份的组件。它对单元测试并不友好：单例持有的是全局状态，测试用例之间会相互污染，前一个用例的修改会泄漏到后一个用例；同时由于实例的获取方式被写死在代码中，难以用桩对象或模拟对象替换，通常需要额外引入依赖注入或专门的测试钩子才能解耦。选项 A、C、D 均是对单例模式的正确描述。题干要求选出错误说法，故选 B。

工厂模式关注创建什么，其抽象工厂或工厂方法在收到一次调用后即返回成品，隐藏的是产品的具体类型；建造者模式关注如何创建，把复杂对象的构造拆解为若干步骤，由指挥者按统一顺序调用这些步骤，具体建造者决定每一步的实现与最终组装结果。正因为构造过程与最终表示相互分离，同一套构造流程配合不同的具体建造者即可产出不同的产品，例如同一份套餐配置流程可以产出纸质餐卡或电子餐卡。选项 A、C、D 的描述均不成立。故选 B。

当系统中存在两个或多个独立变化的维度时，若采用继承实现，类的数量会随维度的乘积增长。例如图形形状有圆形与矩形，绘制平台有 Windows 与 Linux，二者组合需要四个类，每增加一个形状或一个平台都要成倍扩展。桥接模式把抽象部分与实现部分分离，抽象侧持有实现侧的引用，两者各自形成独立的继承体系，因而可以分别扩展而互不影响。选项 A 是享元模式，选项 B 是外观模式，选项 C 是职责链模式。故选 D。

职责链模式把多个处理者连成一条链，每个处理者持有后继者的引用，请求从链首进入，各处理者自行决定是自行处理请求、处理后继续传递，还是直接把请求转交后继者。发送者无须了解请求最终由谁处理，因而发送者与接收者之间实现了解耦。其典型应用包括审批流程、异常处理与日志级别的分级过滤。选项 B 与模式的本意相反，选项 C 描述的是状态模式，选项 D 描述的是外观模式。故选 A。

两者的静态结构几乎一致，都是上下文持有一个抽象接口的引用，并可在运行期替换为不同实现，因此常被混淆。差别在于由谁驱动替换以及替换之后是否影响彼此的可用性。状态模式中，上下文的行为随其内在状态而改变，状态之间的转换由业务规则决定，各状态往往需要知道后继状态并主动触发迁移，客户端通常不直接指定下一状态。策略模式中，算法的选择由客户端显式决定，各策略之间互不感知，可以在运行期自由替换。故选 C。

访问者模式把作用于元素的操作从元素类中抽离出来，封装为独立的访问者对象。元素类只提供一个接收访问者的方法，访问者为每一种元素类型提供对应的处理逻辑。这样一来，新增一种操作只需增加一个新的访问者实现，无须改动元素类，因而适合元素类型体系稳定而操作种类不断增多的场景，例如编译器对抽象语法树进行类型检查、代码生成与静态分析。其代价是元素类型体系一旦新增元素，所有访问者都要同步修改。选项 A 是工厂模式，选项 B 是享元模式，选项 D 是外观模式。故选 C。

策略模式把一系列可互换的算法各自封装成独立的策略类，让它们实现同一抽象接口，再由上下文对象持有一个策略引用并在运行期替换。它适合的正是题目描述的形态：多种处理方式、调用方按需选择、将来可能扩展新方式，新增策略类即可，无需修改上下文。策略模式的收益是消除了大量的条件分支语句，并让算法的变化独立于使用算法的客户端。单例解决实例唯一性问题，适配器解决接口不兼容问题，组合解决部分与整体树形结构问题，均与多种可互换算法的诉求不符。故选 D。