1. 模板方法模式的核心思想在软件开发中我们经常会遇到这样的情况多个子类中存在着几乎相同的算法流程但其中某些步骤的具体实现又各不相同。这种场景下模板方法模式就能大显身手了。模板方法模式是一种行为型设计模式它定义了一个操作中的算法骨架将某些步骤延迟到子类中实现。这样可以在不改变算法结构的情况下让子类重新定义某些特定步骤的实现方式。关键提示模板方法模式的核心在于不变与可变的分离——将不变的算法结构放在父类中将可变的具体实现延迟到子类中。1.1 模式的基本结构一个典型的模板方法模式包含以下几个关键部分抽象父类(AbstractClass)定义算法骨架包含模板方法和基本方法具体子类(ConcreteClass)实现父类中定义的基本方法完成特定步骤的具体实现模板方法通常被声明为final以防止子类重写算法结构。而需要子类实现的方法通常被声明为abstract强制子类必须实现它们。1.2 模式的应用场景模板方法模式特别适用于以下场景多个类有相同的方法且逻辑基本相同但某些具体步骤的实现不同需要控制子类扩展的点只允许在特定步骤进行扩展存在一系列相关操作需要定义一个固定流程但允许某些步骤灵活变化在实际开发中框架设计、算法实现、流程控制等场景都能看到模板方法模式的身影。2. 为什么需要抽取通用代码到父类2.1 代码重复的问题假设我们有一个电商系统需要处理不同类型的订单支付流程class AlipayOrderProcessor { public void process() { validate(); deductFromAccount(); createTransaction(); notifyUser(); } private void validate() { /* Alipay特有验证逻辑 */ } private void deductFromAccount() { /* Alipay扣款逻辑 */ } private void createTransaction() { /* 通用交易记录创建逻辑 */ } private void notifyUser() { /* 通用通知逻辑 */ } } class WechatPayOrderProcessor { public void process() { validate(); deductFromAccount(); createTransaction(); notifyUser(); } private void validate() { /* WechatPay特有验证逻辑 */ } private void deductFromAccount() { /* WechatPay扣款逻辑 */ } private void createTransaction() { /* 通用交易记录创建逻辑 */ } private void notifyUser() { /* 通用通知逻辑 */ } }可以看到两个处理器类中有大量重复代码特别是createTransaction()和notifyUser()方法几乎完全相同。这种重复不仅增加了维护成本也违反了DRY(Dont Repeat Yourself)原则。2.2 维护性问题当我们需要修改通用逻辑时比如在notifyUser()中添加新的通知渠道必须在所有处理器类中进行相同的修改。这不仅容易遗漏也增加了出错的可能性。2.3 扩展性问题如果现在要新增一个ApplePay支付方式我们需要从头实现整个流程即使大部分代码与其他支付方式相同。这大大降低了系统的可扩展性。3. 使用模板方法模式重构代码3.1 创建抽象父类我们可以将通用流程和通用方法抽取到一个抽象父类中abstract class OrderProcessor { // 模板方法定义算法骨架 public final void process() { validate(); deductFromAccount(); createTransaction(); notifyUser(); } // 需要子类实现的基本方法 protected abstract void validate(); protected abstract void deductFromAccount(); // 通用实现 private void createTransaction() { // 通用交易记录创建逻辑 } private void notifyUser() { // 通用通知逻辑 } }3.2 实现具体子类现在具体的支付处理器只需要关注自己特有的逻辑class AlipayOrderProcessor extends OrderProcessor { Override protected void validate() { // Alipay特有验证逻辑 } Override protected void deductFromAccount() { // Alipay扣款逻辑 } } class WechatPayOrderProcessor extends OrderProcessor { Override protected void validate() { // WechatPay特有验证逻辑 } Override protected void deductFromAccount() { // WechatPay扣款逻辑 } }3.3 重构后的优势消除重复代码通用逻辑只存在于父类中一处易于维护修改通用逻辑只需修改父类一处易于扩展新增支付方式只需实现差异部分控制扩展点子类只能重写指定的方法无法修改算法流程4. 模板方法模式的进阶应用4.1 钩子方法(Hook Method)有时我们希望在算法流程中提供一些可选步骤这时可以使用钩子方法abstract class OrderProcessor { public final void process() { validate(); deductFromAccount(); createTransaction(); if (needNotify()) { notifyUser(); } } // 钩子方法默认实现 protected boolean needNotify() { return true; } // 其他方法... }子类可以通过重写needNotify()方法来控制是否执行通知步骤class SilentOrderProcessor extends OrderProcessor { Override protected boolean needNotify() { return false; } // 其他实现... }4.2 模板方法模式与策略模式的区别初学者常常混淆模板方法模式和策略模式它们的区别在于控制层面模板方法父类控制算法流程子类实现特定步骤策略完全由具体策略类控制算法代码复用模板方法通过继承实现代码复用策略通过组合实现行为变化运行时变化模板方法编译时确定算法结构策略运行时可以切换算法4.3 在框架设计中的应用许多框架都使用了模板方法模式来定义扩展点。例如Servlet生命周期init(),service(),destroy()方法构成了一个模板JUnit测试setUp(),testXXX(),tearDown()方法序列Spring初始化afterPropertiesSet()方法作为模板的一部分5. 实际开发中的注意事项5.1 避免过度使用虽然模板方法模式很有用但也要避免过度使用继承的代价Java是单继承过度使用会占用宝贵的继承机会灵活性限制一旦模板方法确定修改算法结构会比较困难5.2 命名约定为了提高代码可读性建议采用以下命名约定模板方法通常命名为doXXX()或processXXX()基本方法(需要子类实现的)通常命名为performXXX()或executeXXX()钩子方法通常以should,need,can等开头5.3 文档注释由于模板方法模式定义了父类和子类之间的契约良好的文档注释非常重要/** * 订单处理模板类 * * p子类必须实现以下方法 * ul * li{link #validate()} - 执行订单验证/li * li{link #deductFromAccount()} - 执行账户扣款/li * /ul * * p可选重写方法 * ul * li{link #needNotify()} - 控制是否发送通知/li * /ul */ abstract class OrderProcessor { // 类实现... }5.4 单元测试策略测试模板方法模式时需要注意测试抽象父类时可以创建匿名测试子类测试具体子类时要验证它是否正确实现了所有抽象方法测试模板方法流程时可以使用Mock对象验证方法调用顺序Test public void testProcessFlow() { OrderProcessor processor new OrderProcessor() { Override protected void validate() {} Override protected void deductFromAccount() {} }; processor.process(); // 验证流程是否正确执行 }6. 在不同语言中的实现差异6.1 Java实现Java中的实现如前面示例所示主要依赖抽象类和final方法public abstract class Game { // 模板方法 public final void play() { initialize(); startPlay(); endPlay(); } abstract void initialize(); abstract void startPlay(); abstract void endPlay(); }6.2 Python实现Python中没有抽象类的强制约束通常使用ABC模块或raise NotImplementedErrorfrom abc import ABC, abstractmethod class Game(ABC): # 模板方法 def play(self): self.initialize() self.start_play() self.end_play() abstractmethod def initialize(self): pass abstractmethod def start_play(self): pass abstractmethod def end_play(self): pass或者更Pythonic的方式class Game: def play(self): self.initialize() self.start_play() self.end_play() def initialize(self): raise NotImplementedError def start_play(self): raise NotImplementedError def end_play(self): raise NotImplementedError6.3 JavaScript实现JavaScript中没有类的概念(ES6之前)可以通过函数和原型链实现function Game() { if (this.constructor Game) { throw new Error(Cannot instantiate abstract class); } } Game.prototype.play function() { this.initialize(); this.startPlay(); this.endPlay(); }; Game.prototype.initialize function() { throw new Error(Must implement initialize); }; Game.prototype.startPlay function() { throw new Error(Must implement startPlay); }; Game.prototype.endPlay function() { throw new Error(Must implement endPlay); };ES6之后可以使用class语法class Game { play() { this.initialize(); this.startPlay(); this.endPlay(); } initialize() { throw new Error(Must implement initialize); } startPlay() { throw new Error(Must implement startPlay); } endPlay() { throw new Error(Must implement endPlay); } }7. 模板方法模式的变体与相关模式7.1 工厂方法与模板方法工厂方法模式可以看作是模板方法模式的一个特例它专门用于对象创建场景。工厂方法定义了创建对象的框架将具体创建逻辑延迟到子类。7.2 模板方法与回调在某些语言(如JavaScript)中回调函数可以实现类似模板方法模式的效果function processOrder(validate, deduct) { validate(); deduct(); createTransaction(); notifyUser(); } // 使用 processOrder( () { /* Alipay验证逻辑 */ }, () { /* Alipay扣款逻辑 */ } );这种方式的优点是更灵活缺点是缺乏结构约束。7.3 模板方法与AOP面向切面编程(AOP)可以实现类似模板方法的效果通过定义切点和通知来插入通用逻辑Aspect public class OrderProcessingAspect { Around(execution(* com.example..process*(..))) public Object aroundProcess(ProceedingJoinPoint pjp) { validate(); Object result pjp.proceed(); createTransaction(); notifyUser(); return result; } private void validate() { /* 通用验证逻辑 */ } private void createTransaction() { /* 通用交易逻辑 */ } private void notifyUser() { /* 通用通知逻辑 */ } }这种方式更适合横切关注点的处理。8. 实际项目中的经验分享在多年的开发实践中我总结了以下关于模板方法模式的经验何时使用当多个类有相同的行为模式但具体实现不同时当你想控制子类的扩展点只允许修改特定部分时当你想避免重复代码特别是流程性代码时何时避免当算法步骤经常变化时考虑策略模式当子类需要大幅度修改算法流程时当语言本身提供了更好的替代方案时如函数式语言的高阶函数常见错误忘记将模板方法声明为final导致子类可能破坏算法结构在父类中提供过多的钩子方法导致设计过于复杂没有清晰文档说明哪些方法需要/可以被子类实现性能考虑模板方法模式通常不会引入明显的性能开销方法调用是直接的没有额外的间接层在性能关键路径上可以考虑将模板方法内联测试技巧为抽象父类创建测试专用的具体子类使用Mock对象验证方法调用顺序测试所有可能的钩子方法组合我在一个电商支付系统中应用模板方法模式时最初的设计过于复杂包含了太多可选的钩子方法。后来通过重构减少了钩子方法的数量使设计更加清晰。这个经验告诉我模板方法模式应该保持简单只提供真正必要的扩展点。