模板方法模式通过抽象类定义算法骨架，子类实现具体步骤。例如，DocumentProcessor 抽象类中，processDocument() 为 final 方法，确保流程固定；readData() 和 postProcessData() 为抽象方法，由子类实现；shouldPreProcess() 和 preProcessData() 为钩子方法，子类可选覆盖；processCoreData() 为共享逻辑。该模式基于继承，强调流程控制，适用于多类共用算法结构但细节不同的场景。与策略模式不同，模板方法侧重流程固定、局部可变，而策略模式通过组合实现算法整体替换。优点包括代码复用、流程可控、扩展灵活；挑战有继承僵化、子类冗余等。优化方式包括合理使用钩子方法、避免过度继承、结合工厂方法等。
在Java中实现模板方法模式，核心在于定义一个算法的骨架，并将一些步骤延迟到子类中去实现。这通常通过一个抽象类来完成，该抽象类包含一个
final修饰的模板方法（定义了算法的整体流程），以及一个或多个抽象方法或钩子方法（由子类具体实现或选择性覆盖）。
解决方案
模板方法模式的实现，我们通常会从一个抽象类开始。这个抽象类会定义一个固定的算法流程，其中一些步骤是通用的，另一些则留给具体的子类去实现。
让我们以一个处理不同类型文档的场景为例。假设我们需要读取数据、处理数据，然后保存数据。读取和保存的方式可能因文档类型而异，但“处理”的通用逻辑可以保持一致，或者也有一些特定的处理步骤。
// 抽象文档处理器
public abstract class DocumentProcessor {
// 模板方法：定义了处理文档的整体流程，通常设置为final，防止子类修改骨架
public final void processDocument() {
System.out.println("--- 开始处理文档 ---");
readData(); // 抽象方法，由子类实现
if (shouldPreProcess()) { // 钩子方法，子类可选覆盖
preProcessData();
}
processCoreData(); // 具体方法，通用逻辑
postProcessData(); // 抽象方法，由子类实现
System.out.println("--- 文档处理完成 ---");
}
// 抽象方法：读取数据，具体实现由子类决定
protected abstract void readData();
// 钩子方法：是否需要预处理，提供默认实现（不预处理）
protected boolean shouldPreProcess() {
return false;
}
// 钩子方法：预处理数据，提供默认空实现
protected void preProcessData() {
System.out.println("默认：执行文档预处理...");
}
// 具体方法：核心数据处理逻辑，所有子类共享
private void processCoreData() {
System.out.println("执行核心数据处理逻辑...");
// 模拟一些复杂的通用处理...
}
// 抽象方法：后处理数据，具体实现由子类决定
protected abstract void postProcessData();
// 示例：主方法演示
public static void main(String[] args) {
System.out.println("处理PDF文档：");
DocumentProcessor pdfProcessor = new PdfDocumentProcessor();
pdfProcessor.processDocument();
System.out.println("\n处理Word文档：");
DocumentProcessor wordProcessor = new WordDocumentProcessor();
wordProcessor.processDocument();
}
}
// 具体PDF文档处理器
class PdfDocumentProcessor extends DocumentProcessor {
@Override
protected void readData() {
System.out.println("从PDF文件读取数据...");
}
@Override
protected void postProcessData() {
System.out.println("将处理后的数据保存为新的PDF文件...");
}
// PDF文档不需要预处理，所以不覆盖shouldPreProcess()
}
// 具体Word文档处理器
class WordDocumentProcessor extends DocumentProcessor {
@Override
protected void readData() {
System.out.println("从Word文档读取数据...");
}
@Override
protected boolean shouldPreProcess() {
// Word文档需要进行预处理
return true;
}
@Override
protected void preProcessData() {
System.out.println("针对Word文档进行格式转换预处理...");
}
@Override
protected void postProcessData() {
System.out.println("将处理后的数据导出为Word文档...");
}
}在这个例子中，
DocumentProcessor是抽象类，
processDocument()是模板方法，它定义了整个处理流程。
readData()和
postProcessData()是抽象方法，必须由子类实现。
shouldPreProcess()和
preProcessData()是钩子方法，它们有默认实现，子类可以选择性地覆盖。
processCoreData()是一个具体方法，所有子类都共享其逻辑。通过这种方式，我们确保了算法的骨架不变，同时允许子类定制某些特定步骤。
立即学习“Java免费学习笔记（深入）”；
模板方法模式与策略模式有何区别？
这确实是很多人初学设计模式时会感到困惑的地方，因为它们看起来都有点像“算法的封装”。但实际上，它们的侧重点和实现方式截然不同。
模板方法模式，它关注的是一个算法的固定骨架。想象一下，你有一张详细的烹饪食谱，其中“准备食材”、“炒菜”、“装盘”是固定的大步骤，但“准备食材”具体是洗土豆还是切番茄，或者“炒菜”是放辣椒还是放酱油，这些细节是可以根据不同菜品（子类）来调整的。它的核心在于继承，通过抽象父类来定义流程，子类通过实现或覆盖父类的方法来完善细节。控制权在父类，父类决定了整个流程的走向（“好莱坞原则”：不要调用我，让我来调用你）。
而策略模式呢，它关注的是可替换的算法族。比如，你有多种支付方式：支付宝、微信支付、银行卡支付。每种支付方式都是一个独立的算法，它们之间可以互相替换，但它们都完成“支付”这个大目标。策略模式通常通过组合来实现，客户端代码持有策略接口的引用，并在运行时选择具体的策略实现。控制权在客户端，由客户端决定使用哪个策略。
简单来说：
模板采用响应式设计，自动适应手机，电脑及平板显示；满足单一店铺外卖需求。功能：1.菜单分类管理2.菜品管理：菜品增加，删除，修改3.订单管理4.友情链接管理5.数据库备份6.文章模块：如：促销活动，帮助中心7.单页模块：如：企业信息，关于我们更强大的功能在开发中……安装方法：上传到网站根目录，运行http://www.***.com/install 自动
- 模板方法： 算法的整体流程固定，局部步骤可变。强调继承。
- 策略模式： 算法的整体是可替换的，每种替换都是一个完整的算法。强调组合。
一个形象的比喻：模板方法是“一个生产线，但某些工位可以定制不同机器”；策略模式是“有多个完全不同的生产线，你可以选择用哪条”。
何时选择模板方法模式，它有哪些优点和潜在的挑战？
选择模板方法模式，通常是在你发现：
- 多个类有共同的算法结构，但某些步骤的实现不同。 比如前面提到的文档处理，或者数据导入导出、构建报告等。
-
希望控制算法的整体流程，防止子类随意修改核心逻辑。 通过将模板方法设为
final
，可以有效实现这一点。 - 想在父类中重用代码，避免在多个子类中重复编写相同的逻辑。
优点：
- 代码复用： 核心的、通用的算法逻辑可以在抽象父类中实现一次，避免子类重复编写。
- 控制反转（Hollywood Principle）： 父类调用子类的方法，而不是子类调用父类。这使得父类能够控制算法的整体结构，提高了代码的可维护性和一致性。
- 提高灵活性和可扩展性： 可以在不修改父类的情况下，通过添加新的子类来扩展算法的不同实现。
- 强制执行算法结构： 确保了所有实现都遵循相同的基本流程，这对于团队协作和代码规范非常有益。
潜在的挑战：
- 可能导致类层次结构僵化： 如果算法的骨架发生大的变化，可能需要修改抽象父类，这会影响所有子类。
- 子类可能需要实现不必要的方法： 如果抽象类定义了过多的抽象方法，而某些子类并不需要所有这些步骤，就可能导致子类中出现空实现或不相关的代码。这可以通过合理设计钩子方法来缓解。
- 调试可能变得复杂： 因为控制流在父类和子类之间跳转，理解和调试整个算法的执行过程可能需要更多精力。
- 违反单一职责原则： 抽象父类可能承担了定义流程和部分实现细节的双重职责，需要权衡。
如何通过钩子方法和抽象类设计优化模板方法模式？
优化模板方法模式，关键在于如何巧妙地设计抽象类和其中的方法，以达到既能保持算法骨架的稳定性，又能提供足够的灵活性。
-
善用钩子方法（Hook Methods）： 钩子方法是模板方法模式中的一个强大工具。它们通常是具有默认实现的（可以是空实现或提供一个默认行为）
protected
方法，子类可以选择性地覆盖它们。-
默认行为： 如果大多数子类都不需要某个可选步骤，或者有一个通用的默认行为，就给钩子方法一个默认实现。例如，
protected boolean shouldLog() { return false; }。这样，只有需要日志的子类才去覆盖它。 -
空实现： 对于某些可选但没有通用默认行为的步骤，可以提供一个空实现，例如
protected void preProcessData() {}。这避免了子类被迫提供一个无意义的实现。 -
条件判断： 钩子方法也可以用来控制模板方法中的某些步骤是否执行，比如我们例子中的
shouldPreProcess()
。这使得算法流程可以根据子类的具体需求进行调整。
-
默认行为： 如果大多数子类都不需要某个可选步骤，或者有一个通用的默认行为，就给钩子方法一个默认实现。例如，
-
抽象类的设计原则：
- 保持抽象类专注： 抽象类应该只包含定义算法骨架和共享逻辑所需的方法和字段。避免让它变得“臃肿”，承担过多不相关的职责。
-
使用
final
修饰模板方法： 这确保了算法的整体流程不会被子类修改，维护了模式的核心意图。 - 明确抽象方法和具体方法： 抽象方法是子类必须实现的，代表了算法中必须定制的部分。具体方法是所有子类共享的逻辑。
-
可见性控制： 大多数模板方法模式中的方法都应该是
protected
，这样子类可以访问和覆盖它们，但外部客户端无法直接调用，保持了封装性。 - 避免过深的继承链： 虽然模板方法模式基于继承，但过深的继承层次会增加复杂性。如果发现层次结构变得过于复杂，可能需要重新评估设计，考虑是否可以拆分或结合其他模式（如策略模式）。
-
引入工厂方法或构建器： 如果创建具体子类的过程很复杂，可以结合工厂方法模式来创建具体的
DocumentProcessor
实例，或者使用构建器模式来配置处理器的某些参数。
通过这些优化，我们可以让模板方法模式既保持其强大的结构化能力，又能在实际应用中更加灵活和易于维护。它不是一个完美的银弹，但当你的业务逻辑中存在明确的“固定流程，可变细节”的场景时，它往往是一个非常优雅的解决方案。
