夜雨聆风
1 从奶茶店说起
想象一下,你开了一家连锁奶茶店🧋
北京店要做珍珠奶茶 上海店要做水果茶 深圳店要做柠檬茶
问题来了: 每开一家新店,都要重新培训员工从头学起吗?
聪明的老板会这样做:
制定一个标准配方模板📝 每种奶茶都遵循: 准备原料 → 调制 → 加冰 → 封杯→ 出餐 不同奶茶只是原料不同,流程完全一样!
这就是模板方法模式的精髓! 🎯
而我们今天要看的支付系统,就用了一招"奶茶店秘籍"!
2 什么是模板方法模式?
2.1 通俗解释
模板方法模式就像做菜菜谱👨🍳
菜谱(父类)规定了固定步骤:
准备食材 热锅倒油 下锅翻炒 调味出锅
不同厨师(子类)可以:
用不同的食材(西红柿vs土豆) 但不能改变做菜顺序!
核心思想: 流程固定,细节可变
3 支付系统的"奶茶店"架构
3.1 业务背景
我们有一个聚合支付系统,需要对接6个支付渠道:
盛付通 海科融通 拉卡拉 易生支付 乐刷 嘉联支付
每个渠道都要实现相同的业务功能:
✅ 商户进件(入驻) ✅ 商户信息修改 ✅ 审核状态查询 ✅ 微信/支付宝认证 ✅ APPID绑定
问题来了: 6个渠道 × 5个功能 = 30套代码? 😱
NO! 我们用模板方法模式,一套代码搞定! 🎉
4 核心架构:三层"奶茶店"模式
4.1 📊 架构图
┌─────────────────────────────────────────────┐│ 🏪 业务应用层(前台点餐) ││ 商户提交申请、运营人员查询状态 │└──────────────────┬──────────────────────────┘│ 点单▼┌─────────────────────────────────────────────┐│ 🎭 渠道策略层(服务员) ││ 盛付通服务员 │ 海科融通服务员 │ 拉卡拉服务员 ││ 职责: 接待客户、识别渠道需求 │└──────────────────┬──────────────────────────┘│ 转交后厨▼┌─────────────────────────────────────────────┐│ 👨🍳 模板方法层(标准菜谱) ││ AbstractHandleProvider ││ 7个标准流程:进件、修改、查询、认证... ││ 678行代码,定义所有业务骨架 │└──────────────────┬──────────────────────────┘│ 准备食材▼┌─────────────────────────────────────────────┐│ 🔄 数据适配层(食材转换) ││ convertRequest() - 50+字段转换 ││ 内部数据 ↔ 支付渠道SDK格式 │└──────────────────┬──────────────────────────┘│ 呼叫供应商▼┌─────────────────────────────────────────────┐│ 🏭 外部服务层(食材供应商) ││ DTPayService - 聚合支付中台 ││ 盛付通SDK │ 海科融通SDK │ 拉卡拉SDK │└─────────────────────────────────────────────┘
4.2 各层职责(用奶茶店比喻)
层级 | 奶茶店角色 | 技术职责 | 代码量 |
业务应用层 | 前台点餐员 | 接收HTTP请求、返回响应 | 约500行 |
渠道策略层 | 服务员 | 识别客户要哪个渠道 | 约800行(6个类) |
模板方法层 | 标准菜谱 | 定义业务流程骨架 | 678行 |
数据适配层 | 食材准备员 | 数据格式转换 | 约350行 |
外部服务层 | 食材供应商 | 调用支付渠道API | 外部依赖 |
5 📖 七大"标准菜谱"(模板方法)
📋 菜谱清单
我们的"后厨大师傅"(AbstractHandleProvider)掌握了7道标准菜谱
createStore() | ||||
| ||||
getStoreProcess() | ||||
| ||||
| ||||
| ||||
|
6 时序图:商户进件的"八步烹饪法"
🎯 八步烹饪法详解
1️⃣ 记录日志 | 接单记账 | log.info("进件开始") | ❌ 固定 |
2️⃣ 准备食材 | 按配方准备原料 |
转换50+字段 | ✅可定制 |
3️⃣下锅烹饪 | 调用SDK创建商户 |
| ❌ 固定 |
4️⃣ 记录结果 | 记录烹饪完成 |
| ❌ 固定 |
5️⃣ 装盘出餐 | 组装响应对象 | 创建 | ❌ 固定 |
6️⃣ 质量检查 | 检查商户状态 | 判断NORMAL/ABNORMAL | ❌ 固定 |
7️⃣ 通知取餐 | 发送MQ消息 | mqSendService.send() | ❌ 固定 |
8️⃣ 后续处理 | 业务系统更新 | 异步更新数据库、通知用户 | ❌ 固定 |
关键发现: 8步中只有第2步(准备食材)可以定制,其他7步完全固定!
这就是模板方法的威力:流程不变,食材可变! 🎉
7 🔄 时序图:商户审核状态查询
🎯 查询逻辑亮点
一个接口,三个渠道状态:
微信认证: ✅ 已通过(商户号wx001) 支付宝认证: ⏳ 审核中(预计1-2个工作日) 银联认证: ❌ 已驳回(原因:资料不完整,请重新提交)
设计巧妙之处:
使用Stream API过滤三个渠道状态 每个渠道独立转换,互不影响 使用Optional避免空指针异常
8 💡 为什么要用模板方法模式?
8.1 痛点场景:没有模板方法的痛苦
假设我们不用模板方法模式,每个渠道都自己写:
盛付通渠道:- 进件: 200行代码- 修改: 180行代码- 查询: 250行代码- 认证: 200行代码- 绑定: 150行代码小计: 980行海科融通渠道: (重复写一遍)小计: 980行易生渠道: (再重复一遍)小计: 980行... (6个渠道)总计: 980 × 6 = 5880行代码! 😱
而且:
❌ 修改一个bug要改6个地方 ❌ 新增一个功能要写6遍 ❌ 代码重复率高达90%
8.2 爽点场景:用了模板方法的快乐
AbstractHandleProvider(模板方法层):- 进件模板: 120行- 修改模板: 100行- 查询模板: 150行- 认证模板: 130行- 绑定模板: 80行- 数据转换: 350行- 辅助方法: 200行小计: 1130行6个渠道策略类:- 每个只需实现support()方法: 5行- 小计: 5 × 6 = 30行总计: 1130 + 30 = 1160行代码! 🎉
代码量减少80%! 📉
而且:
✅ 修改一个bug只改一处,6个渠道同时生效 ✅ 新增一个功能只写一次,所有渠道自动拥有 ✅ 代码重复率降到10%以下
9 🚀 扩展性:新增渠道只需3步
9.1 传统方式(痛苦模式)
新增一个渠道:
复制一个渠道的代码 修改所有硬编码的渠道标识 修改工厂配置 修改路由逻辑 测试所有功能 耗时: 3天😫
9.2 模板方法方式(快乐模式)
新增一个渠道:
第1步: 创建新策略类
@Componentpublic class NewChannelProvider extends AbstractHandleProvider {@Overridepublic boolean support(String channelCode) {return "NEW".equalsIgnoreCase(channelCode);}}
第2步: 添加渠道编码常量
String NEW = "NEW";第3步: 重启应用
耗时: 0.5天 🎉
工厂自动发现新策略,无需任何配置!
10 📊 业务架构全景图
┌──────────────────────────────────────────────────┐│ 🏪 业务应用层 ││ BossController / UserController / 定时任务 ││ 功能: 商户进件、商户更新、状态查询、认证绑定 │└────────────────────┬─────────────────────────────┘│ HTTP请求▼┌──────────────────────────────────────────────────┐│ 🎭 渠道策略层 ││ SFTHandleProvider │ HKRTHandleProvider ││ LKLHandleProvider│ LSHandleProvider ││ YSHandleProvider│ JLHandleProvider ││ 职责: 渠道路由判断、特殊逻辑重写 │└────────────────────┬─────────────────────────────┘│ 调用模板方法▼┌──────────────────────────────────────────────────┐│ 👨🍳 模板方法层(核心) ││ AbstractHandleProvider ││ 7个模板方法: 进件/修改/查询/认证/绑定 ││ 12个适配器方法: 数据转换(50+字段) ││ 678行核心代码,定义所有业务流程 │└────────────────────┬─────────────────────────────┘│ SDK调用▼┌──────────────────────────────────────────────────┐│ 🏭 外部服务层 ││ DTPayService - 聚合支付中台SDK ││ MqSendService - 消息队列服务 │└──────────────────────────────────────────────────┘
11 🎯 总结:模板方法模式的五大优势
1️⃣ 代码复用率高达90%
6个渠道共享同一个convertRequest方法 50+字段转换逻辑只写一次 异常处理、日志记录、MQ发送全部复用
2️⃣ 扩展性极强
新增渠道只需3步,0.5天搞定 无需修改现有代码 符合开闭原则
3️⃣ 流程标准化
所有渠道遵循相同的处理流程 便于新员工快速理解 避免遗漏关键步骤
4️⃣ 可维护性强
修改转换规则只需改一处 Bug修复影响范围可控 代码量减少80%
5️⃣ 业务价值巨大
提升开发效率: 新增渠道从3天→0.5天 降低维护成本: 代码量减少60% 提高系统稳定性: 统一的异常处理机制
12 🎊 结语
模板方法模式,就像奶茶店的标准配方模板:
📝 流程固定: 所有奶茶都遵循相同的步骤 🎨细节可变: 每种奶茶的原料可以不同 🚀易于扩展: 新增奶茶口味,只需添加新配方
我们的支付系统,就是靠这套"奶茶店秘籍":
✅ 6个渠道,统一流程 ✅ 50+字段转换,代码复用 ✅ 新增渠道,3步搞定
设计模式不是炫技,而是解决实际问题的利器! 💪
13📚 延伸思考
如果你的业务系统也有以下场景,可以考虑模板方法模式:
✅ 多渠道接入(支付、短信、物流等) ✅多类型处理(订单、用户、商品等) ✅ 流程固定但细节可变的场景 ✅ 需要高度复用代码的场景
记住一句话:流程固定,细节可变,就用模板方法!🎯
点赞❤️ 收藏⭐ 转发🔄 让更多开发者看到!
关注我,获取更多设计模式实战解析! 🚀
聚合支付系统里，究竟藏了多少种设计模式
