如何使用Java模板方法模式规范多步审批流程的骨架与实现

先说说模板方法模式在审批流程中的定位——它确实是个好东西，尤其适合那种步骤固定但每步逻辑千差万别的场景。你想想，一个审批流程无非就是提交、初审、复审、终审、归档这几个环节，但不同业务的审批规则、权限和条件差异巨大。模板方法模式正好拿捏这个点：它把流程的骨架固化在抽象类里，保证步骤不被跳过或颠倒，同时把每步的具体判断逻辑留给子类来实现。这样一来，像请假、报销、采购这类流程就能各自定制，互不干扰。

定义抽象审批骨架

怎么保证流程不走样？关键就在抽象类里声明一个final的模板方法，这个方法按顺序调用钩子方法和抽象方法。钩子方法通常提供默认行为，比如isNeedFinalReview()默认返回true，子类可以根据需要重写它来跳过某些步骤；抽象方法则强制子类实现核心逻辑，像doFirstReview()。有几个点值得注意：

• 模板方法必须声明为final，这一点没商量——不然子类一重写，流程顺序就乱套了。
• 容易变化的逻辑，比如审批人查找、通过条件，全部提取成protected abstract方法，让子类去操心。
• 通用操作，比如记录日志、更新状态，用protected final方法封装起来，子类直接调用就行，避免重复代码。

子类专注实现业务细节

每个具体的审批类型，比如Lea veApprovalProcess或ExpenseApprovalProcess，继承这个抽象类，只覆盖需要差异化的抽象方法。举个例子：请假流程可能是“直属领导初审 + HR复审”两步就够了，而采购流程往往需要“部门负责人 + 财务 + 法务”三级会签。具体怎么实现？

• 初审逻辑只需实现doFirstReview()：查一下申请人直属上级、检查年假余额，返回审批结果。
• 复审逻辑在doSecondReview()中编写：调用组织架构服务获取HR角色、校验单据金额是否超阈值。
• 钩子方法，比如shouldEscalateToManager()，可以被子类重写，用于特殊场景自动升级审批——比如金额超过某个数时，自动升级到总经理。

运行时动态选择审批流程

到了运行时，怎么动态选择走哪个流程？用工厂或策略模式来解耦是个好办法。比如根据申请单类型（type = "lea ve"）返回对应的子类实例，然后统一调用execute()模板方法。整个流程对调用方是透明的，新增一种审批类型，只需要添加一个新子类，不用修改原有的骨架代码。这里还有几个实践小技巧：

• 避免在模板方法内硬编码if-else分支判断类型，那样就破坏了开闭原则。
• 可以在抽象类构造器中注入一个审批上下文对象（比如ApprovalContext），供各个步骤共享数据。
• 如果结合Spring，可以用@Qualifier按名称注入不同的审批Bean，配合ApplicationContext实现动态装配。

增强健壮性与可观测性

最后，别忘了给流程加点“抗体”和“监控”。在模板方法的关键节点插入统一的异常处理和审计日志。比如在每一步执行前后记录时间戳、操作人、输入参数；捕获ApprovalRejectedException后统一回滚状态；对超时步骤主动中断并通知。一些具体的做法：

• 用try-catch包裹每一步的抽象方法调用，防止某一步异常导致整个流程中断。
• 定义标准的审批事件（比如ApprovalStepStartedEvent），发布到事件总线供监控系统消费。
• 在抽象类中预留beforeStep()和afterStep()钩子，方便子类插入前置校验或后置清理逻辑。