那个让我栽了3年的面试题： senior dev 追问的"设计模式"到底是什么

2023年某次技术面试，Pavan Sriram 被问到面向对象编程，答得还行。对方接着抛出一个问题："你知道设计模式吗？"他愣在当场——这个看似基础的追问，后来让他花了整整4年才真正吃透。

这不是某个人的黑历史，是行业通病。Stack Overflow 2023年开发者调查显示，67%的受访者在工作中频繁遇到需要设计模式的场景，但系统学习过的不到三分之一。更多人是在代码 review 时被 senior 用"这里应该用单例"砸懵，才被动补课。

设计模式不是 npm install 能解决的问题

Pavan 在复盘里打了个比方：设计模式不是库，不是框架，没法一行命令装到项目里。它们是反复出现的软件设计问题的可复用解决方案——更像建筑蓝图，你得根据地形改图纸，不能直接复印粘贴。

这个区分很关键。新手常犯的错误是搜到一段"工厂模式"代码，原封不动拷进项目，结果工厂套工厂，复杂度爆炸。Pavan 早期踩的坑更典型：把策略模式（Strategy Pattern）和状态模式（State Pattern）混着用，代码逻辑像 spaghetti，自己三个月后都看不懂。

他的转折点来自一本书。《设计模式：可复用面向对象软件的基础》——GoF（Gang of Four，四人组）1994年的经典。但 Pavan 警告：别一上来就硬啃。他推荐的入门路径是先理解"为什么"，再记"是什么"。

从23种模式里，他提炼出3个高频场景

Pavan 没有罗列全部 GoF 模式，而是按实际工作场景分类。第一类是对象创建：单例（Singleton）控制唯一实例，工厂（Factory）封装创建逻辑。他在一个支付系统里用工厂模式处理多种渠道（微信、支付宝、银行卡），新增渠道时只改一处代码，review 时 senior 第一次没皱眉。

第二类是结构组织：适配器（Adapter）解决接口不兼容，装饰器（Decorator）动态加功能。Pavan 印象最深的是接手一个老系统，第三方 API 版本迭代三次，他用适配器模式把新旧接口包成统一层，上层业务代码零改动。

第三类是行为协作：观察者（Observer）处理事件订阅，策略（Strategy）封装算法族。他在这里摔过最狠的一跤——早期把策略模式写成 if-else 地狱的面向对象版，后来才明白核心是把变化的部分抽出来，让客户端决定用哪个策略，而不是在策略内部判断。

一个反直觉的发现：设计模式学得越多，代码反而越简单。Pavan 观察到一个现象——初级开发者倾向于用模式"证明"自己，一个功能叠三四个模式； senior 的代码看起来平平无奇，但点开才发现模式藏得很深，只解决真问题。

学习路径：他花了4年验证的笨办法

Pavan 的学习曲线分三段。第一年，他背模式名称和 UML 图，面试能聊，写代码想不起来用。第二年，他开始在重构时主动找模式，经常过度设计，被同事吐槽"为了用模式而用模式"。

第三年出现质变。他不再问"这里该用哪个模式"，而是先描述问题——"我需要动态改变对象行为，同时让客户端无感知"——然后模式名自然浮现。第四年，他能一眼看出同事代码里的模式误用，比如把简单工厂和抽象工厂混用，导致扩展时不得不改工厂类。

他现在的判断标准是：如果去掉模式，代码会不会更差？不是"能不能用模式"，而是"不用模式会不会更乱"。这个视角转换，让他从"模式收集者"变成"问题解决者"。

Pavan 最后提到一个细节。他现在面试别人时，也会问那个让他栽了的问题。但追问方式变了——不是考"列举23种模式"，而是给一个具体场景，看对方能不能识别出重复代码的坏味道，再讨论有没有更干净的组织方式。

设计模式的价值，从来不在模式本身。

那个 senior dev 当年真正想问的，大概是：你能不能看出代码里的重复结构，并找到更优雅的表达方式？Pavan 花了4年才听懂这个问题——你现在会在哪个阶段卡住？