面经策

谈谈你了解的最常见的几种设计模式，说说他们的应用场景 ​

  • 标签：设计模式

🏛 业务架构师 ​

我只讲在真实业务里反复兑现价值的几个：

  • 策略模式：营销规则（满减、折扣、秒杀价）、支付渠道路由。新上渠道或活动只加一个实现类，主流程零改动——把"经常变的部分"封进策略，是给业务迭代提速；
  • 责任链：风控前置检查（黑名单→限频→额度）、网关过滤器链、审批流。规则顺序可配置编排，让业务专家能参与调整流程而不改代码；
  • 工厂 + 模板方法：不同物流商/支付渠道接入，骨架固定（下单、回调、对账三段），差异细节子类实现。新渠道接入从周降到天；
  • 观察者/事件：下单成功后积分、短信、推荐各自订阅事件，核心域与支撑域解耦；
  • 代理：AOP 承载事务、审计日志、监控，让业务代码只表达业务规则。

我的判断标准是围绕业务变化点用模式：哪里经常变（规则、渠道、流程顺序），就在哪里建抽象。反过来的教训也真实：给一年不变的场景套一堆模式，新人接手要先上三天课，这是负资产。

所以面试里我更想强调后半句——模式是手段，业务变化点的识别才是架构能力。用对了，扩展点是资产；用错了，是团队的认知税。

🏗 系统架构师 ​

我按"框架里真实出现"的顺序讲最常用的几个：

  • 单例：Spring Bean 默认作用域，连接池、配置中心客户端都是单例管理共享资源；
  • 工厂 + 策略：干掉 if-else 的黄金组合。我做过支付路由：定义 PaymentStrategy 接口，各渠道实现类注册进 Spring 容器，运行时按渠道码从 Map 里取策略执行，新渠道加类不改主流程，符合开闭原则；
  • 责任链：网关过滤器链、风控规则引擎、Interceptor/Filter 体系。每个节点只关心自己的校验逻辑，链的组装由配置驱动，增删规则不动代码；
  • 代理：AOP 的基石，事务、日志、监控全靠动态代理织入；RPC 客户端也是代理，把网络调用伪装成本地接口；
  • 观察者：Spring 事件机制，订单创建后发布事件，发券、通知各自监听，业务解耦；
  • 模板方法：JdbcTemplate、AbstractList，固定算法骨架留扩展点。

我的态度：设计模式的价值是"管理变化"——把易变部分封装成可替换单元，而不是炫技。面试我一般拿支付/风控两个真实系统各讲一个组合模式的落地。

💻 全栈开发专家 ​

我按"项目里真正高频使用"来讲六个，都能给出代码级场景：

  • 策略模式：支付渠道/优惠计算。Map<Channel, PayStrategy> 注入，新增渠道加实现类，替代 if-else 大分支。
  • 责任链：网关过滤器、风控规则链。Netty pipeline、Spring Interceptor、MyBatis 插件全是它，按序传递、可中断。
  • 模板方法：流程骨架固定、步骤可变。JdbcTemplate、导出任务（校验→查数据→生成→上传 OSS，子类只实现查数据）。
  • 观察者：事件解耦。Spring ApplicationEvent，下单后发 OrderCreatedEvent，短信/积分监听各自处理，主流程不感知下游。
  • 代理：AOP 的基础。日志、事务、监控全靠动态代理织入。
  • 工厂：按条件产出对象。Spring BeanFactory 体系；业务里按 type 拿 handler。
java
// 策略 + Spring 的经典写法
private final Map<PayType, PayStrategy> strategies; // 构造注入 List<PayStrategy> 转 map
PayStrategy s = strategies.get(payType);

我的态度：设计模式的价值在"变化点"——先识别哪里会变，再用模式把变和不变隔开；为了模式而模式的抽象是负资产，不如直接写 if-else 等重构时机。