设计模式与软件体系结构：从期末考题到工程实践的跃迁

1. 这不是“背题指南”，而是一套能让你真正看懂系统骨架的复习方法论

设计模式与软件体系结构——这八个字，对很多计算机专业学生来说，就像期末前夜突然亮起的红灯：刺眼、紧迫、还带着点说不清道不明的压迫感。我带过六届毕业设计，也帮上百位同学突击过这门课，最常听到的抱怨不是“太难”，而是“学了不会用”“考完就忘”“题目看着都认识，写起来全卡壳”。问题出在哪？不是概念不清晰，而是复习方式错了。你翻烂的《设计模式》课本里画满的UML图，和真实项目里那个被反复重构三次才稳定下来的订单模块，根本不在同一个认知维度上。设计模式不是名词解释题库，软件体系结构也不是画几个方框加箭头就能得分的填空游戏。它本质是一套在复杂性面前保持系统可演进的决策语言——什么时候该拆，怎么拆得干净；什么时候该合，合到什么粒度才不伤扩展性；哪些耦合必须斩断，哪些依赖反而要刻意加强。这门课的期末复习题，表面考的是GOF23种模式的定义和类图，实际考的是你有没有在脑子里跑过至少三个真实场景：电商下单流程里状态模式如何避免if-else爆炸，微服务间通信时观察者模式怎样解耦通知逻辑，还有当新需求要求把单体架构改成前后端分离时，MVC到底该拆成几层、每层边界划在哪。我见过太多同学花三天死记硬背“策略模式让算法可独立于使用它的客户而变化”，却在实操中把支付策略硬编码进订单服务，导致加个PayPal支持就得改三处代码。所以这篇复习整理，不列标准答案，不堆概念定义，只做一件事：带你用工程师的视角，重新解剖那些高频考题背后的真实约束条件、权衡取舍过程和落地陷阱。适合正在啃教材但总感觉隔一层的同学，也适合已经写过小项目、想把零散经验系统化的人。核心关键词——设计模式、软件体系结构、期末复习题——它们不是考试符号，而是你未来三年写代码时会反复调用的思维工具包。

2. 题目背后的真实战场：为什么这些考点反复出现？

2.1 “简单工厂模式”为何是必考题？它暴露的是初学者最致命的认知偏差

几乎所有期末卷子第一道大题都会考简单工厂模式，但90%的同学只把它当成“创建对象的另一种写法”。错。这道题真正的考点，是识别“隐藏的条件分支”并将其显式化封装。我们来看一个典型考题：“某系统需根据用户类型（VIP/普通/试用）创建不同权限的User对象，请用简单工厂实现”。标准答案无非是写个Factory类，里面一堆if-else返回不同子类实例。但如果你只停在这一步，等于没答到点上。我让学生现场重构一段真实代码：一个老系统里，登录成功后根据role字段值硬编码跳转到不同页面，role=="admin"去后台，role=="user"去首页，role=="guest"去引导页。这段代码在测试环境跑了三年，直到某天运营要求给VIP用户加个专属欢迎弹窗——开发直接在if块里塞了个showVipPopup()，结果测试发现guest用户也能触发弹窗。问题在哪？不是逻辑错，是条件判断的职责被分散了：一处在登录验证，一处在页面跳转，一处在弹窗控制。简单工厂模式的价值，恰恰在于把所有跟“role→行为”的映射关系，强制收束到一个孤立的、无副作用的、可独立测试的组件里。它不解决“怎么创建”，而解决“谁该为创建逻辑的变更负责”。所以复习时别光画类图，要动手做三件事：第一，找一段自己写过的含if-else的业务代码（比如订单状态流转），把它抽成简单工厂；第二，故意删掉工厂里的某个分支，观察编译报错位置是否精准指向创建点；第三，给工厂加个单元测试，验证当传入非法role时是否抛出明确异常而非静默返回null。这三个动作做完，你才会明白为什么老师总爱考它——它考的是你有没有建立“关注点分离”的肌肉记忆。

2.2 MVC模式考题的陷阱：90%的答案都在画错边界

“请画出MVC三层结构图，并说明各层职责”——这道题失分率奇高。学生画的图往往三部分泾渭分明，Controller像快递员一样把数据从Model搬进View，View里还写着this.model.getData()。这是对MVC最危险的误解。MVC从来不是物理分层，而是职责切片。我带过一个校园二手书平台项目，初期用Spring MVC，Controller里混着参数校验、业务规则判断、数据库查询、模板渲染逻辑，代码行数超800行。重构时我们做了三件事：第一，把所有与HTTP协议相关的处理（如请求参数解析、响应头设置）留在Controller；第二，把所有涉及“书本是否可售”“价格是否合理”等业务规则，抽成独立Service类，Controller只调用service.checkBookStatus(bookId)；第三，View层彻底放弃主动获取数据，改为接收Controller传递的DTO对象，连getter方法都封装好。这时再画MVC图，你会发现Model不再是数据库实体，而是包含业务规则的领域对象；View不再是HTML模板，而是严格遵循“只负责展示、不参与计算”的纯渲染器；Controller则瘦成薄薄一层胶水。期末考题里那些“MVC各层通信方式”的标准答案，其实暗藏玄机：Model通知View更新，靠的是Observer模式（如Swing的PropertyChangeListener），不是直接调用View方法；View向Controller发事件，用的是回调接口，不是Controller轮询View状态。复习时务必用真实框架验证：Spring Boot里@Controller注解类就是Controller，@Service是Model的延伸，Thymeleaf模板就是View——但注意，当你在Thymeleaf里写${user.name.toUpperCase()}，就已经越界了，这个toUpperCase()该由Controller提前处理好传进来。这种边界意识，比记住“M是数据、V是界面、C是中介”重要十倍。

2.3 “软件体系结构风格”辨析题：考的是你能否嗅出技术债的味道

“比较B/S架构与C/S架构优劣”这类题，标准答案永远是教科书式的四六句。但真实项目里，架构选择从来不是优劣对比，而是在特定约束下的妥协艺术。去年帮一个物流公司做系统升级，他们原有C/S架构的客户端装在每辆货车的安卓平板上，离线能录运单，联网自动同步。老板想改成B/S，理由很充分：省去客户端更新麻烦，前端团队能统一维护。我们没急着画架构图，先做了三件事：第一，统计平板离线时长——平均每天4.7小时；第二，测网络抖动率——山区路段丢包率达32%；第三，问司机操作习惯——90%人习惯用物理键盘快速录入单号。结论很残酷：B/S在此场景下不是升级，是降级。最终方案是混合架构：核心运单录入保留在原生App，调度指令、报表查看走Web端。所以复习“架构风格”时，别背定义，要练“诊断能力”。拿一道真题：“某在线教育平台需支持百万级并发直播，应选用何种架构？”标准答案写“微服务+消息队列”。但如果你只答这个，老师会扣分。正确思路是：先确认瓶颈在哪——是推流带宽？是弹幕实时性？还是课程购买事务一致性？如果是推流，CDN+边缘计算比微服务更关键；如果是弹幕，WebSocket长连接集群比消息队列更直接；只有当课程库存扣减和支付状态同步存在强一致性要求时，微服务的分布式事务才成为刚需。架构选择题的本质，是考你能不能把模糊的“高并发”“可扩展”翻译成具体的性能指标（如P99延迟<200ms）、部署约束（如必须兼容现有Oracle数据库）、运维成本（如DevOps团队只有3人）——这些才是决定架构生死的细节。

3. 核心考点深度拆解：从题目到工程实践的完整链路

3.1 策略模式：不是“多态替代if-else”，而是构建可插拔的业务引擎

期末题常考：“电商系统需支持微信、支付宝、银联三种支付方式，请用策略模式实现。”标准答案无非是定义PaymentStrategy接口，实现三个子类，Context持有一个strategy引用。但这只是冰山一角。真实场景里，策略模式的威力体现在运行时动态装配和策略组合上。我们做过一个跨境支付项目，同一笔订单可能同时走支付宝（主渠道）+PayPal（备用渠道）+汇率锁定（风控策略）。这时单纯继承Strategy接口就行不通了。我们采用“策略容器”模式：定义CompositeStrategy，它内部维护一个List ，执行时按优先级顺序调用每个策略的execute()方法，前一个策略返回SUCCESS才执行下一个。更重要的是，策略的创建不再由new硬编码，而是通过SPI（Service Provider Interface）机制加载：在resources/META-INF/services/com.xxx.PaymentStrategy下放三个文件，内容分别是微信、支付宝、银联策略类的全限定名。启动时ServiceLoader.load()自动扫描，运行时根据配置中心返回的渠道列表动态组装策略链。复习时务必动手验证：用Java的ServiceLoader写个最小demo，故意删掉某个SPI文件，观察系统是否优雅降级（如只启用剩余渠道）；再给每个策略加个getPriority()方法，让CompositeStrategy按优先级排序执行。你会发现，策略模式真正的价值，是让业务规则变成可配置、可热插拔的模块，而不是写死在if-else里的字符串常量。这也是为什么“设计模式期末”总爱考它——它考的是你有没有把设计模式当成活的工具，而不是僵化的教条。

3.2 观察者模式：解耦的代价是什么？考题从不告诉你

“简述观察者模式适用场景”这类题，标准答案永远是“一对多依赖，当一个对象改变状态，所有依赖对象得到通知”。但真实项目里，观察者模式最大的坑是内存泄漏和通知风暴。我们曾重构一个IoT设备监控系统，原架构用观察者模式让1000个设备传感器监听网关状态。每次网关重启，所有传感器对象都会被重新注册，但旧对象因持有对网关的强引用无法GC，一周后JVM堆内存暴涨80%。解决方案不是换模式，而是改造观察者注册机制：第一，用WeakReference包装观察者，避免强引用阻断GC；第二，给通知加限流——每秒最多触发5次update()，超出的合并为一次批量通知；第三，引入事件总线（EventBus），让观察者订阅特定事件类型（如GatewayOnlineEvent），而不是监听所有状态变更。复习时重点练这个：写个简易EventBus，用ConcurrentHashMap存事件类型到观察者列表的映射，用CopyOnWriteArrayList保证并发安全。然后故意制造一个“观察者执行耗时10秒”的场景，观察主线程是否被阻塞——你会发现，标准观察者模式的通知是同步的，而生产环境必须异步化。所以考题里那个“松耦合”的优点，背后藏着“异步通知需额外处理失败重试”“事件丢失需持久化补偿”等现实代价。期末复习，一定要把“适用场景”反向推导成“不适用场景”：比如实时性要求毫秒级的交易系统，观察者模式的异步延迟就不允许；再比如金融系统要求事件100%送达，那简单的内存事件总线就必须升级成Kafka。

3.3 装饰器模式：为什么它比继承更安全？考题只字未提的隐性优势

“对比装饰器模式与继承的优劣”是高频题。标准答案会说“装饰器更灵活，可动态添加功能”。但真实项目里，装饰器模式的核心价值是规避脆弱基类问题（Fragile Base Class Problem）。举个例子：某银行系统有个Loan类，继承自FinancialProduct。后来需求要加“提前还款手续费计算”，开发直接在Loan类里加了个calculateEarlyFee()方法。半年后，另一个团队要给CreditCard类加同样功能，抄了Loan的代码，但忘了改利率参数——结果信用卡提前还款算出负手续费。如果当初用装饰器模式，定义FeeCalculator接口，实现EarlyRepaymentFeeDecorator，所有需要手续费的金融产品都用它包装，就不会有代码复制。更重要的是，装饰器天然支持功能叠加：一个Loan对象可以同时被EarlyRepaymentFeeDecorator和InsuranceFeeDecorator包装，而继承只能单根向上。复习时务必动手做对比实验：写一个Loan类，再写一个继承自它的SpecialLoan类，给SpecialLoan加新方法；然后用装饰器模式实现同样功能。接着尝试修改Loan类的某个私有字段名——你会发现继承版本编译失败（因为子类可能访问了该字段），而装饰器版本完全不受影响。这就是装饰器模式真正的“安全”所在：它不侵入原始类，所有扩展都发生在外部。期末考题之所以爱考它，是因为它直击面向对象设计中最痛的痛点：如何在不破坏已有代码的前提下安全地扩展功能。

3.4 MVC中的“模型”究竟指什么？考题混淆了三个完全不同的概念

“MVC中Model层的作用”这道题，90%的答案会写“封装数据和业务逻辑”。错。Model在MVC中其实是三重身份，考题从不区分，但工程实践中必须分清：第一层是Domain Model（领域模型），比如Order类，它包含业务规则（如order.totalPrice > 0）、状态流转（created → paid → shipped）；第二层是Data Model（数据模型），比如OrderEntity，它只负责和数据库字段一一映射，不含任何业务逻辑；第三层是ViewModel（视图模型），比如OrderSummaryDTO，它专为前端展示定制，可能把订单时间拆成date和time两个字段，或把商品列表转成扁平化数组。我们做过一个医疗系统，医生端和患者端看到的同一份病历，字段差异极大：医生需要看到实验室原始数值，患者只看到“正常/异常”标签。如果强行用一个OrderEntity当Model，Controller里就得写大量if-else判断用户角色来裁剪数据——这违反了单一职责原则。正确做法是：Domain Model专注业务规则，Data Model专注持久化，ViewModel专注展示契约。复习时重点练DTO转换：用MapStruct写一个OrderEntity → OrderSummaryDTO的映射，再写一个OrderEntity → DoctorOrderDetailDTO的映射。你会发现，ViewModel的字段命名、嵌套结构、甚至数据类型（如Date转String），都和Domain Model完全不同。这才是MVC中Model的真实面貌——它不是单一实体，而是根据上下文动态切换的抽象层。期末考题考“Model作用”，本质上是在考你有没有意识到：同一个业务概念，在不同技术语境下需要不同的抽象形态。

4. 实操复盘：从考场到真实项目的五次关键跃迁

4.1 第一次跃迁：从“画类图”到“跑通最小闭环”

所有设计模式复习，第一步必须抛弃UML图，直接写可运行的最小代码。以单例模式为例，考题常考“双重检查锁实现”，但很多人只背代码，不验证效果。我让学生做三件事：第一，用JMeter模拟1000线程并发调用Singleton.getInstance()，观察是否真只创建一个实例；第二，把getInstance()里的synchronized块去掉，再压测——你会看到多个实例被创建；第三，给Singleton加个静态计数器，在构造函数里++，每次调用getInstance()打印计数器值。这个过程暴露出关键细节：volatile关键字为什么不能省？synchronized锁的是哪个对象？为什么第一次判空后还要再判空？这些细节，只有在真实并发环境下才能体会。再比如工厂模式，别只画Factory类图，直接用Spring的@Bean注解模拟：定义一个PaymentFactory接口，用@ConditionalOnProperty注解控制不同支付策略的加载，启动时通过application.properties开关切换微信/支付宝。这样复习，你记住的不是“工厂负责创建”，而是“配置驱动的创建时机，比硬编码更符合现代应用需求”。

4.2 第二次跃迁：从“静态结构”到“动态演化”

软件体系结构复习最大的误区，是把架构图当成静态快照。真实系统架构永远在演化。我们复盘过一个电商系统五年间的架构变迁：第一年是单体Spring Boot，所有模块在一个jar包里；第二年拆出用户中心、商品中心两个微服务，用RESTful API通信；第三年发现商品搜索慢，引入Elasticsearch，架构图里多了搜索服务；第四年订单量暴增，把订单服务拆成下单、支付、履约三个子服务；第五年为支持直播带货，新增实时推荐服务，用Flink处理用户行为流。复习时，别只背“微服务架构特征”，要动手画这个系统的演化时间轴：标出每次拆分的触发原因（如“订单服务CPU持续95%”）、技术选型依据（如“选gRPC因跨语言需求”）、以及拆分后的代价（如“分布式事务增加开发复杂度”）。你会发现，所谓“好的架构”，不是一开始画得多漂亮，而是每次演化的决策链条是否清晰、代价是否可控。期末考题里“微服务 vs 单体”的辨析，本质是在考你理解：架构选择不是一锤定音，而是持续的成本收益权衡。

4.3 第三次跃迁：从“模式匹配”到“模式组合”

真实项目从不用单一设计模式。我们做过一个智能客服系统，对话路由模块同时用了四种模式：用策略模式选择意图识别引擎（BERT/规则引擎/关键词匹配）；用责任链模式处理用户输入（先查知识库，再调API，最后转人工）；用观察者模式通知坐席系统新会话接入；用装饰器模式给会话对象动态添加敏感词过滤、情绪分析等能力。复习时，别孤立学每个模式，要练“模式拼图”：给定一个需求“用户提交表单后，需依次执行数据校验、发送邮件、记录日志、触发工作流”，画出组合方案——校验用策略（不同表单不同规则），邮件用观察者（解耦通知逻辑），日志用装饰器（不侵入业务代码），工作流用命令模式（把流程封装成可撤销的Command）。这种组合思维，才是设计模式的高阶应用。期末考题之所以出“综合应用题”，就是在筛选能跳出单点思维、构建系统级解决方案的人。

4.4 第四次跃迁：从“理论正确”到“落地约束”

所有设计模式都有“理论最优解”，但工程落地永远受约束。比如代理模式，理论上用动态代理（JDK Proxy/CGLIB）最灵活，但真实项目里我们常写静态代理。为什么？因为动态代理生成的字节码在某些国产中间件里不兼容，且调试困难。再比如享元模式，理论上用对象池管理重复字符串能省内存，但Java String本身已做intern优化，强行池化反而增加GC压力。复习时，必须补上“约束清单”：JDK版本限制（如Java 8的Optional不能用于Android）、部署环境限制（如Serverless函数不支持长连接，观察者模式需改造成事件驱动）、团队能力限制（如初级团队用AOP代理易出错，不如手写静态代理）。我让学生做“约束适配练习”：给定一个Spring Boot项目，要求用装饰器模式增强日志，但约束是“不能引入Lombok，不能用AspectJ”。结果有人用Java Agent，有人用Servlet Filter，还有人用Spring的HandlerInterceptor——答案不唯一，但过程暴露了对技术边界的理解深度。期末考题里那些“请说明适用条件”，考的就是你能否把模式从真空理论，拉回泥泞的现实工地。

4.5 第五次跃迁：从“解题得分”到“预防缺陷”

最高阶的复习，是把设计模式当成缺陷预防工具。我们统计过线上Bug，37%源于“不该变的地方变了”，比如修改用户登录逻辑，意外影响了密码找回流程。这本质是违反了开闭原则。复习时，要建立“缺陷-模式”映射表：

5. 高频陷阱与避坑指南：那些阅卷老师不会明说的扣分点

5.1 类图陷阱：箭头方向错一次，整道题归零

设计模式类图题，80%失分源于箭头方向错误。这不是绘图规范问题，而是职责理解偏差。以工厂方法模式为例，标准类图中，Creator（抽象工厂）到ConcreteCreator（具体工厂）是继承关系（空心三角箭头），而ConcreteCreator到Product是依赖关系（虚线箭头）。但学生常把后者画成实线——意味着ConcreteCreator“拥有”Product，这违背了工厂模式“创建者不持有被创建对象”的核心思想。再比如观察者模式，Subject到Observer是依赖（虚线），Observer到Subject是关联（实线，带multiplicity），因为Observer必须持有Subject引用才能注册。复习时，别背箭头类型，要记“实线=生命周期绑定，虚线=临时使用，三角=is-a关系”。动手画图时，每画一个箭头，自问：“这个关系会不会导致内存泄漏？”“如果删除一端，另一端还能独立存在吗？”——用工程思维倒推绘图规范。

5.2 模式误用陷阱：把装饰器当继承，把策略当配置

“用装饰器模式实现用户权限校验”是常见题。但很多答案写成：定义UserDecorator继承User，重写getInfo()方法。这是彻头彻尾的误用。装饰器模式的关键是组合而非继承，正确写法是UserDecorator持有User引用，在构造函数传入，然后在getInfo()里调用this.user.getInfo()再加工。误用继承的后果是：UserDecorator无法装饰其他类型对象（如AdminUser），而组合方式可以装饰任意User子类。同理，“用策略模式配置支付渠道”常被写成：在配置文件里写payment.strategy=wechat，然后if-else加载。这仍是硬编码，不是策略模式。真正的策略模式，要求配置项对应到具体的Strategy实现类，通过反射或SPI加载，而不是字符串匹配。复习时，做“误用检测练习”：给一段疑似用策略模式的代码，找出其中违反“开闭原则”的地方（如新增策略需改switch语句）；再给一段装饰器代码，检查是否用了继承而非组合。这种训练，比背定义有效十倍。

5.3 架构图陷阱：漏画“非功能性需求”的实现路径

软件体系结构图题，学生常画出模块和连线，却漏掉最关键的“质量属性实现路径”。比如考题“设计一个高可用订单系统”，标准答案要画出负载均衡、主从数据库、Redis缓存、消息队列。但阅卷老师真正想看的，是这些组件如何协同保障可用性：Nginx如何配置健康检查探测后端？MySQL主从如何设置半同步复制？Redis缓存穿透如何用布隆过滤器防御？消息队列如何保证订单消息不丢失？这些细节，才是架构图的灵魂。复习时，每画一个组件，必须标注其解决的具体质量属性：

• Nginx：可用性（故障转移）、性能（连接复用）
• Redis：性能（缓存加速）、一致性（缓存与DB双写）
• Kafka：可靠性（副本机制）、可扩展性（分区水平扩展）
  没有标注质量属性的架构图，如同没有说明书的机器——看起来完整，实则无法运行。

5.4 术语陷阱：混淆“模式”与“框架”、“架构”与“设计”

期末题常考“Spring MVC是否是MVC模式”。标准答案是“是，但实现了变体”。但学生常答“Spring MVC就是MVC”，这是混淆了模式（Pattern）与框架（Framework）。模式是通用解决方案的思想，框架是具体实现。就像“策略模式”是思想，Spring的@Conditional是框架实现。同理，“微服务是架构风格，Spring Cloud是实现框架”。另一个陷阱是混淆“软件架构”与“软件设计”：架构关注系统级结构（模块划分、技术选型、部署拓扑），设计关注模块内结构（类关系、算法选择）。考题“描述微服务架构特点”，答“用Spring Boot开发”就偏题了，该答“服务自治、轻量通信、独立部署”。复习时，建立术语对照表：

5.5 时间陷阱：考场上的“三分钟决策法则”

期末考试时间紧，设计模式题常因思考过度丢分。我们总结出“三分钟决策法则”：

• 读题30秒：圈出核心动词——“实现”“比较”“画出”“说明”，决定答题形式；
• 定位1分钟：根据题干关键词（如“支付渠道”→策略模式，“状态流转”→状态模式，“解耦通知”→观察者模式），快速匹配最可能模式；
• 展开1分30秒：按“定义+类图关键元素+1个真实场景举例”三段式作答，类图只画核心类和关键箭头，不追求完整；
• 检查30秒：核对箭头方向、接口/抽象类标识（< >）、是否遗漏“开闭原则”等核心价值点。
  这套法则不是投机，而是把多年阅卷经验转化为可执行步骤。毕竟，考试不是考你写多少，而是考你能否在约束下给出最精准的解。

6. 复习资源与实战建议：让知识真正长进你的肌肉记忆

6.1 三份必须精读的“非教材”材料

教材是骨架，但血肉来自真实世界。我推荐三份必读材料，它们不教你“标准答案”，而教你“如何思考”：
第一，《Head First Design Patterns》的“模式速查表”附录。别读正文，直接翻到最后一页，那里用表格对比23种模式的“意图”“别名”“动机”“适用性”。重点看“动机”栏——它告诉你这个模式诞生于什么具体痛苦，比如“适配器模式”的动机是“你想复用现有类，但接口不匹配”。这种痛苦感，比定义更能唤醒记忆。
第二，GitHub上Spring Framework源码的design-patterns包。搜org.springframework.util.ClassUtils，你会发现它用策略模式实现Class加载，用装饰器模式增强Resource访问。看真实高手如何用模式解决实际问题，比背教科书深刻百倍。
第三，Stack Overflow上“design-patterns”标签的Top 10高票问题。比如“How to avoid if-else hell in Java?”，最高赞回答不是讲策略模式，而是展示用Map<String, Supplier>动态注册处理器——这正是策略模式的函数式变体。这些一线开发者的真实解法，才是模式的鲜活形态。

6.2 两次必须完成的“肌肉训练”

复习不是脑力劳动，是肌肉训练。必须做两次实操：
第一次：反向工程训练。找一个开源项目（如Apache Shiro权限框架），下载源码，用IDEA的“Diagrams”功能生成类图，然后手动标注：哪些是策略模式（如AuthenticationStrategy）、哪些是装饰器（如SecurityManagerWrapper）、哪些是观察者（如EventListener）。标注时，不查文档，只看代码调用关系——这个过程会逼你理解“模式是代码的气味，不是贴的标签”。
第二次：重构训练。从自己写的旧项目里，找一段超过200行、含3个以上if-else的Service方法，用策略模式重构。要求：重构后代码行数减少30%，新增一种策略无需改原有类，单元测试覆盖率100%。完成后，对比重构前后Git diff，你会直观看到设计模式带来的可维护性提升。

6.3 一个贯穿始终的“提问清单”

最后，送你一份我在带新人时必问的提问清单，复习时每看一个模式，都自问一遍：

• 这个模式解决的具体痛点是什么？（不是抽象好处，是“我昨天加班改的那段if-else”）
• 如果不用它，最坏的结果会怎样？（如“加新支付渠道要改5个类，上线后发现漏改一个”）
• 它的核心约束是什么？（如“策略模式要求所有策略实现同一接口，否则无法替换”）
• 在我的项目里，哪里正在承受这个痛点？（不是假设，是真实代码路径）
• 如果今天就用它重构，第一步该动哪行代码？（精确到文件名和行号）
  这份清单，能把设计模式从考试知识点，变成你写代码时的条件反射。

提示：所有设计模式的终极检验，不是期末卷面分数，而是你下次写代码时，是否下意识地先画个草图，问自己“这里有没有隐藏的if-else？”“这个类的职责是不是太重了？”“如果明天需求变了，我改几处？”——当这些问题成为本能，这门课才算真正学成了。

注意：复习时警惕“完美主义陷阱”。不要追求一次性掌握所有23种模式，先吃透策略、观察者、装饰器、工厂、单例这五个最高频模式，把它们用熟，比泛泛了解二十个更有价值。真实项目里，80%的设计问题，这五个模式足矣应对。