C++模板方法模式：算法骨架与定制实现

1. 模板方法模式：C++中的骨架与定制艺术

在C++的世界里，我们常常会遇到这样的场景：某个算法的整体流程是固定的，但其中某些步骤的具体实现可能因情况而异。这就好比制作一杯咖啡——无论是美式还是拿铁，都需要经过研磨咖啡豆、萃取、倒入杯子这几个基本步骤，但具体到每种咖啡，某些步骤的实现细节又各不相同。模板方法模式（Template Method Pattern）正是为解决这类问题而生的设计模式。

我第一次在真实项目中应用这个模式，是在开发一个跨平台的文件解析器时。不同平台的文件格式虽然差异很大，但解析流程却出奇地一致：打开文件、读取头部信息、验证签名、解析数据块、关闭文件。这时候如果为每个平台都写一套完整流程，不仅重复劳动，而且后期维护简直是噩梦。模板方法模式让我能够把不变的流程固定下来，把变化的细节交给子类实现，代码量直接减少了40%。

这个模式之所以在C++中如此重要，是因为它能完美契合C++的抽象特性。通过将算法的骨架定义在基类中，而将一些步骤延迟到子类中实现，它既保证了整体结构的稳定性，又提供了足够的灵活性。在STL和Boost这样的经典库中，你都能找到模板方法模式的身影。

2. 模式结构与C++实现剖析

2.1 经典UML结构解析

模板方法模式的核心结构其实相当直观。想象一个做菜的流程：准备食材、烹饪、装盘这三个步骤是固定的，但每个步骤的具体做法可能不同。在代码中，这表现为：

cpp复制class AbstractClass {
public:
    void TemplateMethod() {  // 这就是我们的"模板方法"
        PrimitiveOperation1();
        PrimitiveOperation2();
        ConcreteOperation();
    }
    
protected:
    virtual void PrimitiveOperation1() = 0;  // 纯虚函数，子类必须实现
    virtual void PrimitiveOperation2() = 0;  // 另一个纯虚函数
    
    void ConcreteOperation() {  // 已经实现好的公共操作
        // 这里是固定实现
    }
};

在C++中实现时，有几个关键点需要注意：

1. 模板方法（TemplateMethod）通常定义为非虚函数，这是为了防止子类意外修改算法骨架
2. 需要子类实现的步骤声明为纯虚函数（=0）
3. 可选的钩子方法（Hook）可以通过虚函数提供默认实现，子类可选择是否覆盖

2.2 实际C++代码示例

让我们看一个更具体的例子——跨平台窗口创建流程：

cpp复制class Window {
public:
    // 模板方法：定义创建窗口的标准流程
    void CreateWindow() {
        BeforeCreation();
        CreateOSWindow();  // 平台相关实现
        AfterCreation();
        RegisterWindow();
    }
    
    virtual ~Window() = default;

protected:
    // 以下为需要子类实现的步骤
    virtual void CreateOSWindow() = 0;
    virtual void RegisterWindow() = 0;
    
    // 钩子方法：子类可以选择性覆盖
    virtual void BeforeCreation() {}
    virtual void AfterCreation() {}
};

// Windows平台实现
class WindowsWindow : public Window {
protected:
    void CreateOSWindow() override {
        // 调用Win32 API创建窗口
        std::cout << "Creating window using Win32 API\n";
    }
    
    void RegisterWindow() override {
        // 注册窗口类
        std::cout << "Registering Windows window class\n";
    }
    
    void AfterCreation() override {
        // Windows特有的后处理
        std::cout << "Performing Windows-specific post-creation\n";
    }
};

这个例子展示了模板方法模式在实际中的典型应用。Window类定义了创建窗口的标准流程，而平台相关的具体实现则交给子类完成。这种结构使得新增一个平台支持变得非常简单——只需继承Window并实现那几个关键方法即可。

3. 模板方法模式在C++中的独特优势

3.1 与其他语言的实现对比

与Java或C#等语言相比，C++实现模板方法模式有几个显著特点：

1. 性能优势：C++的虚函数调用虽然比普通函数调用稍慢，但相比其他语言的反射或动态调用机制，仍然高效得多。在性能敏感的场合，甚至可以用CRTP（Curiously Recurring Template Pattern）这种编译期多态来替代运行时多态。

2. 灵活的控制粒度：C++允许我们精确控制哪些方法应该是纯虚的（必须实现），哪些有默认实现（可选择覆盖），哪些完全不允许修改（非虚）。这种细粒度的控制在很多高级语言中是不具备的。

3. 与模板的结合：C++的模板机制可以与模板方法模式产生奇妙的化学反应。比如，我们可以定义一个模板基类，其中某些步骤的实现甚至可以通过模板参数来定制。

3.2 与C++特性的协同效应

模板方法模式特别适合与以下C++特性配合使用：

1. RAII（资源获取即初始化）：模板方法常常用于资源管理场景，与RAII理念完美契合。比如在数据库访问中，我们可以把连接、执行、释放的流程固定下来，而让具体查询实现可变。

2. 智能指针：在涉及资源管理的模板方法中，使用智能指针可以避免资源泄漏，即使子类实现出现异常也能保证资源被正确释放。

3. 移动语义：对于需要传递大量数据的场景，模板方法模式可以与移动语义结合，减少不必要的拷贝。

4. 实战应用：从STL到现代C++项目

4.1 STL中的模板方法模式应用

虽然STL主要基于模板而非继承，但你仍然能找到模板方法模式的影子。一个典型的例子是STL算法中的自定义比较函数。比如std::sort：

cpp复制template<typename RandomIt, typename Compare>
void sort(RandomIt first, RandomIt last, Compare comp) {
    // 排序算法的骨架在这里实现
    // 但具体的比较逻辑由comp函数对象决定
}

这实际上是模板方法模式的一种变体，只不过使用的是编译时多态而非运行时多态。这种设计允许算法骨架保持不变，而关键步骤（在这里是比较操作）可以根据需要定制。

4.2 现代C++项目中的典型案例

在现代C++项目中，模板方法模式常见于以下场景：

1. 框架设计：如游戏引擎中的场景管理、GUI框架中的控件绘制等
2. 跨平台开发：如前文的窗口创建示例
3. 数据处理流水线：如ETL（提取-转换-加载）流程

以游戏引擎为例，一个典型的游戏循环可能这样实现：

cpp复制class Game {
public:
    void Run() {  // 模板方法
        Initialize();
        while (!IsGameOver()) {
            ProcessInput();
            Update();
            Render();
        }
        Cleanup();
    }
    
    virtual ~Game() = default;

protected:
    virtual void Initialize() = 0;
    virtual void ProcessInput() = 0;
    virtual void Update() = 0;
    virtual void Render() = 0;
    virtual bool IsGameOver() = 0;
    virtual void Cleanup() {}
};

每个具体游戏只需继承Game类并实现这些虚方法，就能获得一个完整的游戏循环，而无需关心主循环如何运转。

5. 高级技巧与常见陷阱

5.1 使用CRTP实现编译期多态

对于性能极其敏感的场合，我们可以使用CRTP来避免虚函数调用的开销：

cpp复制template <typename T>
class Base {
public:
    void TemplateMethod() {
        static_cast<T*>(this)->primitiveOperation1();
        static_cast<T*>(this)->primitiveOperation2();
        concreteOperation();
    }
    
    void concreteOperation() {
        // 实现细节
    }
};

class Derived : public Base<Derived> {
public:
    void primitiveOperation1() {
        // 具体实现
    }
    
    void primitiveOperation2() {
        // 具体实现
    }
};

这种技术的优点是零运行时开销，缺点是失去了真正的多态能力——你不能通过基类指针来统一管理不同的子类对象。

5.2 模板方法模式的陷阱与规避

在实践中，我遇到过几个常见的坑：

1. 过度分割步骤：把算法拆分成太多小步骤会导致类结构复杂化。经验法则是，只有当某个步骤确实需要变化时，才把它分离出来。

2. 忽视异常安全：在模板方法中，如果某些步骤可能抛出异常，要确保资源被正确释放。使用RAII对象管理资源是关键。

3. 错误使用虚函数：模板方法本身通常不应该声明为虚函数，否则子类可能意外改变算法结构，破坏设计初衷。

4. 忽略文档：模板方法模式中的哪些方法可以覆盖、哪些不应该覆盖，必须明确文档化，否则后续维护者可能误用。

提示：在设计模板方法时，我习惯用final关键字标记那些不希望子类改变的方法，比如：

cpp复制void TemplateMethod() final { ... }

这样可以防止子类意外覆盖模板方法本身。

6. 模式变体与现代C++演进

6.1 策略模式与模板方法模式的抉择

初学者常常困惑于何时使用模板方法模式，何时使用策略模式。关键在于变化的维度：

• 如果整个算法结构固定，只有某些步骤需要变化，用模板方法模式
• 如果整个算法都需要灵活替换，用策略模式

在现代C++中，这两种模式常常结合使用。比如，可以使用策略对象作为模板方法中的某些步骤的实现方式。

6.2 C++20带来的新可能

C++20引入的concept和range等特性为模板方法模式带来了新的实现方式。例如，我们可以用concept来约束模板方法中的某些步骤：

cpp复制template<typename T>
concept Drawable = requires(T t) {
    { t.draw() } -> std::same_as<void>;
};

class Renderer {
public:
    template<Drawable T>
    void Render(const T& obj) {
        PreRender();
        obj.draw();  // 要求T必须满足Drawable概念
        PostRender();
    }
    
private:
    void PreRender() { /*...*/ }
    void PostRender() { /*...*/ }
};

这种实现方式结合了模板的灵活性和接口的明确性，是传统模板方法模式的一种现代化演进。

7. 性能考量与优化实践

7.1 虚函数调用的开销分析

虚函数调用通常比普通函数调用慢，因为需要额外的指针解引用操作。在极端性能敏感的场景中，这种开销可能变得显著。以下是一些实测数据（在我的i7-11800H上测试）：

从数据可以看出，虚函数调用确实有可测量的开销，但在大多数应用中，这种开销是可以接受的。只有当你的模板方法被调用得非常频繁（比如在游戏的主循环中），才需要考虑使用CRTP等零开销方案。

7.2 缓存友好性优化

模板方法模式的一个潜在问题是可能导致代码分散，影响CPU缓存利用率。为了优化这一点，可以考虑：

1. 热路径内联：将频繁执行的简单操作标记为inline
2. 数据局部性：确保模板方法中连续访问的数据在内存中也连续存储
3. 避免虚函数连环调用：不要在模板方法的紧循环中调用虚函数

举个例子，在游戏引擎的渲染循环中，我通常会这样优化：

cpp复制void Render() {
    // 非虚调用，可以内联
    PrepareRenderState();  
    
    for (auto& object : renderQueue_) {
        // 虚函数调用移出内层循环
        object->Prepare();  
        
        // 实际渲染是非虚调用
        RenderObjectInternal(object);  
    }
}

8. 测试与维护考量

8.1 单元测试策略

测试模板方法类需要特殊考虑，因为部分功能在基类中，部分在子类中。我的经验是：

1. 测试基类：创建用于测试的桩子类（Test Double），验证模板方法的正确流程
2. 测试子类：重点测试子类实现的各个步骤，确保它们满足基类约定的前置后置条件
3. 集成测试：验证整个继承体系是否协同工作

使用Google Test框架的一个例子：

cpp复制class TestableTemplate : public AbstractClass {
protected:
    void PrimitiveOperation1() override { /* 测试实现 */ }
    void PrimitiveOperation2() override { /* 测试实现 */ }
};

TEST(TemplateMethodTest, CorrectOrder) {
    TestableTemplate testObj;
    testing::InSequence seq;  // 确保调用顺序正确
    
    EXPECT_CALL(testObj, PrimitiveOperation1());
    EXPECT_CALL(testObj, PrimitiveOperation2());
    
    testObj.TemplateMethod();
}

8.2 长期维护建议

在大型项目中长期使用模板方法模式时，我总结了以下经验：

1. 文档化契约：明确记录每个可覆盖方法的前置条件、后置条件和不变式
2. 版本兼容性：基类演化时要考虑二进制兼容性，避免破坏现有子类
3. 模式识别：当发现多个子类以相似方式覆盖相同方法时，考虑引入新的中间抽象层
4. 性能分析：定期检查模板方法的热路径，确保没有意外的性能退化

一个实用的技巧是使用override关键字（C++11引入）来明确标记覆盖的方法，这可以防止因签名不匹配导致的意外行为：

cpp复制class Derived : public Base {
protected:
    void PrimitiveOperation1() override { /* 明确表示这是覆盖 */ }
};

9. 与其他设计模式的协同

9.1 与工厂方法模式的结合

模板方法模式经常与工厂方法模式一起使用。比如，在模板方法中可能需要创建某些对象，而具体的创建逻辑可以交给工厂方法：

cpp复制class DataProcessor {
public:
    void Process() {  // 模板方法
        auto reader = CreateReader();  // 工厂方法
        auto data = reader->Read();
        ProcessData(data);
        auto writer = CreateWriter();  // 工厂方法
        writer->Write(data);
    }
    
protected:
    virtual std::unique_ptr<DataReader> CreateReader() = 0;
    virtual std::unique_ptr<DataWriter> CreateWriter() = 0;
    virtual void ProcessData(const Data& data) { /* 默认实现 */ }
};

这种组合非常灵活，既控制了处理流程，又允许各个步骤的具体实现变化。

9.2 与观察者模式的联动

另一个常见组合是与观察者模式一起使用，让模板方法的关键步骤可以被外部监控：

cpp复制class ObservableProcessor : public DataProcessor {
public:
    void AddObserver(ProcessorObserver* observer) {
        observers_.push_back(observer);
    }
    
protected:
    void ProcessData(const Data& data) override {
        NotifyObservers(ProcessingStarted{data});
        // 实际处理...
        NotifyObservers(ProcessingFinished{data});
    }
    
private:
    std::vector<ProcessorObserver*> observers_;
};

这样既保持了模板方法的核心结构，又增加了扩展性。

10. 从简单示例到复杂系统

10.1 简单示例：排序算法模板

让我们从一个简单的排序算法模板开始：

cpp复制class Sorter {
public:
    void Sort(std::vector<int>& data) {
        if (data.empty()) return;
        
        PreProcess(data);
        DoSort(data);  // 这是子类需要实现的核心排序算法
        PostProcess(data);
    }
    
    virtual ~Sorter() = default;

protected:
    virtual void DoSort(std::vector<int>& data) = 0;
    
    virtual void PreProcess(std::vector<int>& data) {
        // 默认不做任何预处理
    }
    
    virtual void PostProcess(std::vector<int>& data) {
        // 默认不做任何后处理
    }
};

这个简单的框架可以轻松扩展为各种具体排序算法：

cpp复制class QuickSorter : public Sorter {
protected:
    void DoSort(std::vector<int>& data) override {
        std::sort(data.begin(), data.end());
    }
};

class BubbleSorter : public Sorter {
protected:
    void DoSort(std::vector<int>& data) override {
        // 实现冒泡排序...
    }
};

10.2 复杂系统：游戏引擎架构

在更复杂的系统中，比如游戏引擎，模板方法模式可以用于构建整个框架：

cpp复制class GameSystem {
public:
    void RunFrame() {
        StartFrame();
        UpdatePhysics();
        UpdateAI();
        RenderScene();
        EndFrame();
    }
    
    virtual ~GameSystem() = default;

protected:
    virtual void UpdatePhysics() = 0;
    virtual void UpdateAI() = 0;
    virtual void RenderScene() = 0;
    
    virtual void StartFrame() {
        // 默认实现：收集性能数据
    }
    
    virtual void EndFrame() {
        // 默认实现：交换缓冲区
    }
};

这种架构允许不同的游戏重用相同的框架，同时定制特定的物理、AI和渲染实现。

11. C++特有的实现技巧

11.1 使用非虚接口（NVI）惯用法

C++社区发展出一种称为"非虚接口"（Non-Virtual Interface, NVI）的惯用法，它是模板方法模式的一种强化形式：

cpp复制class NVIExample {
public:
    void Execute() {  // 非虚公有接口
        DoExecute();  // 调用私有虚函数
    }
    
    virtual ~NVIExample() = default;

private:
    virtual void DoExecute() = 0;  // 真正的实现细节
};

NVI惯用法的优点包括：

1. 更好的接口控制（公有接口完全固定）
2. 可以在调用虚函数前后添加公共逻辑（如日志、锁等）
3. 更安全的析构行为

11.2 使用type_traits进行编译时定制

现代C++允许我们使用类型特征（type traits）在编译时定制模板方法的行为：

cpp复制template<typename T>
class Processor {
public:
    void Process(const T& value) {
        if constexpr (std::is_arithmetic_v<T>) {
            ProcessNumeric(value);
        } else {
            ProcessGeneric(value);
        }
    }

private:
    void ProcessNumeric(T value) { /* 数值特化处理 */ }
    void ProcessGeneric(const T& value) { /* 通用处理 */ }
};

这种技术可以在保持统一接口的同时，针对不同类型提供最优实现。

12. 设计原则与最佳实践

12.1 遵循开闭原则

模板方法模式是开闭原则（对扩展开放，对修改关闭）的完美体现。基类定义了不可更改的算法骨架（关闭修改），同时通过虚方法允许扩展具体步骤（开放扩展）。

在实践中，这意味着：

1. 模板方法本身通常应该声明为final
2. 需要仔细设计哪些方法应该是纯虚的，哪些应该提供默认实现
3. 基类的修改应该极其谨慎，以免破坏现有子类

12.2 控制继承深度

虽然模板方法模式基于继承，但过深的继承层次会带来维护困难。我的经验法则是：

1. 继承层次不超过3层（基类→中间类→具体类）
2. 对于更复杂的情况，考虑使用策略对象组合代替部分继承
3. 使用接口继承而非实现继承

一个反模式示例：

code复制BaseClass → MiddleClass1 → MiddleClass2 → MiddleClass3 → ConcreteClass

这种情况下，应该考虑重构，可能将部分功能分解为独立的策略类。

13. 实际项目经验分享

13.1 性能敏感场景的优化

在一个高频交易系统的开发中，我们使用模板方法模式处理订单流水线。最初的实现使用了传统虚函数：

cpp复制class OrderProcessor {
public:
    void Process(Order& order) {
        Validate(order);
        Transform(order);
        Route(order);
    }
    
protected:
    virtual void Validate(Order&) = 0;
    virtual void Transform(Order&) = 0;
    virtual void Route(Order&) = 0;
};

性能测试发现虚函数调用成为了瓶颈。最终我们改用CRTP实现：

cpp复制template<typename Derived>
class OrderProcessor {
public:
    void Process(Order& order) {
        static_cast<Derived*>(this)->validate(order);
        static_cast<Derived*>(this)->transform(order);
        static_cast<Derived*>(this)->route(order);
    }
};

class FastOrderProcessor : public OrderProcessor<FastOrderProcessor> {
public:
    void validate(Order& order) { /* 内联实现 */ }
    void transform(Order& order) { /* 内联实现 */ }
    void route(Order& order) { /* 内联实现 */ }
};

这种改变使得处理吞吐量提高了约15%，在极端性能要求的场景中非常值得。

13.2 跨平台开发的实践

在开发一个跨平台移动应用时，我们使用模板方法模式处理平台特定的功能。一个典型的例子是通知系统：

cpp复制class Notifier {
public:
    void ShowNotification(const string& title, const string& message) {
        if (!PlatformCheck()) return;
        
        PrepareNotification();
        PlatformShowNotification(title, message);  // 平台特定实现
        LogNotification();
    }
    
    virtual ~Notifier() = default;

protected:
    virtual bool PlatformCheck() = 0;
    virtual void PlatformShowNotification(const string&, const string&) = 0;
    
    virtual void PrepareNotification() {
        // 默认准备逻辑
    }
    
    void LogNotification() {
        // 公共日志逻辑
    }
};

这种设计让我们能够为iOS和Android提供不同的实现，同时保持核心逻辑和日志等辅助功能的一致性。

14. 反模式与误用警示

14.1 模板方法模式的常见误用

在实践中，我见过几种典型的误用情况：

1. 过度使用：不是所有需要子类实现的场景都适合模板方法模式。如果算法步骤经常需要重新排列，这个模式可能不适用。

2. 步骤粒度过细：把算法拆分成太多微小步骤会导致类难以理解和维护。每个步骤应该有明确的语义和独立存在的理由。

3. 忽视LSP：里氏替换原则（LSP）要求子类不应该破坏基类定义的行为契约。在模板方法模式中，子类实现的方法应该遵守基类定义的前置后置条件。

14.2 何时不应该使用模板方法模式

在以下情况下，应考虑其他模式：

1. 算法步骤需要频繁重新排列：考虑策略模式或函数对象组合
2. 大多数步骤都需要变化：考虑桥接模式或策略模式
3. 需要运行时动态改变算法结构：考虑访问者模式或解释器模式

一个简单的判断方法是：如果发现自己在模板方法中写了大量条件逻辑来处理不同子类的特殊情况，很可能这个模式不适合当前场景。

15. C++未来演进的影响

15.1 概念（Concepts）的引入

C++20的概念（Concepts）特性为模板方法模式带来了新的可能性。我们可以定义更精确的接口约束：

cpp复制template<typename T>
concept Drawable = requires(T t) {
    { t.draw() } -> std::same_as<void>;
    { t.bounds() } -> std::convertible_to<Rect>;
};

class Renderer {
public:
    template<Drawable T>
    void Render(const T& obj) {
        SetupRenderState();
        obj.draw();
        CleanupRenderState();
    }
};

这种方式结合了模板的灵活性和接口的明确性，是传统模板方法模式的有力补充。

15.2 协程与异步模板方法

C++20引入的协程为异步场景下的模板方法模式开辟了新天地：

cpp复制class AsyncOperation {
public:
    Task<void> Execute() {
        co_await Begin();
        co_await DoWork();  // 子类实现的核心操作
        co_await End();
    }
    
    virtual ~AsyncOperation() = default;

protected:
    virtual Task<void> DoWork() = 0;
    
    virtual Task<void> Begin() { co_return; }
    virtual Task<void> End() { co_return; }
};

这种模式非常适合需要异步处理的操作序列，如网络请求处理流水线。

16. 工具与IDE支持

16.1 CLion等IDE的模板方法支持

现代C++ IDE如CLion提供了对模板方法模式的特殊支持：

1. 自动识别虚函数：IDE会明确标记哪些方法是需要子类实现的纯虚函数
2. 生成覆盖函数：可以自动生成子类中需要覆盖的函数骨架
3. 导航：方便在基类模板方法和子类实现之间跳转

例如，在CLion中创建子类时，可以按Alt+Insert选择"Override Methods"，IDE会列出所有需要实现的虚函数。

16.2 文档生成工具集成

使用Doxygen等工具时，可以通过特殊标记明确模板方法的结构：

cpp复制/**
 * @class AbstractClass
 * @brief 定义算法骨架
 * 
 * 使用模板方法模式，子类需要实现primitiveOperation1和primitiveOperation2
 */
class AbstractClass {
public:
    /// 模板方法 - 定义算法骨架
    void TemplateMethod() {
        PrimitiveOperation1();
        PrimitiveOperation2();
    }
    
protected:
    /// @name 需要子类实现的操作
    /// @{
    virtual void PrimitiveOperation1() = 0;
    virtual void PrimitiveOperation2() = 0;
    /// @}
};

这种文档化方式让模式结构一目了然。

17. 模板方法模式的教育价值

17.1 教学中的常见示例

在教授设计模式时，模板方法模式通常是最早介绍的模式之一，因为它：

1. 直观展示了继承和多态的应用
2. 体现了"好莱坞原则"（"不要调用我们，我们会调用你"）
3. 展示了如何控制子类的扩展点

一个经典的教学示例是咖啡与茶制作：

cpp复制class Beverage {
public:
    void Prepare() {  // 模板方法
        BoilWater();
        Brew();
        PourInCup();
        AddCondiments();
    }
    
    virtual ~Beverage() = default;

protected:
    virtual void Brew() = 0;
    virtual void AddCondiments() = 0;
    
    void BoilWater() { /* 公共实现 */ }
    void PourInCup() { /* 公共实现 */ }
};

class Coffee : public Beverage {
protected:
    void Brew() override { /* 冲泡咖啡 */ }
    void AddCondiments() override { /* 加糖和牛奶 */ }
};

这个简单例子清晰地展示了模式的核心思想。

17.2 从模板方法到设计原则

通过模板方法模式，可以自然引出几个重要的面向对象设计原则：

1. 单一职责原则：模板方法将不变的部分与可变部分分离
2. 开闭原则：对扩展开放，对修改关闭
3. 好莱坞原则：高层组件控制流程，低层组件实现细节

这些原则构成了良好面向对象设计的基础。

18. 行业应用案例分析

18.1 金融领域的应用

在金融软件开发中，模板方法模式广泛应用于：

1. 交易验证流程：固定验证步骤，不同产品有不同验证规则
2. 风险计算引擎：统一计算框架，特定风险模型可变
3. 报表生成系统：固定数据收集流程，不同报表格式可变

一个交易验证的示例：

cpp复制class TradeValidator {
public:
    ValidationResult Validate(const Trade& trade) {
        if (!ValidateBasic(trade)) return InvalidBasic;
        if (!ValidateProductSpecific(trade)) return InvalidProduct;
        if (!ValidateCounterparty(trade)) return InvalidCounterparty;
        return Valid;
    }
    
    virtual ~TradeValidator() = default;

protected:
    virtual bool ValidateProductSpecific(const Trade&) = 0;
    
    bool ValidateBasic(const Trade& trade) {
        // 基础验证逻辑
    }
    
    bool ValidateCounterparty(const Trade& trade) {
        // 交易对手验证
    }
};

18.2 游戏开发中的应用

游戏引擎中随处可见模板方法模式：

1. 实体组件系统：固定更新顺序，具体组件行为可变
2. AI行为树：固定行为评估流程，具体行为实现可变
3. 渲染管线：固定渲染阶段，具体着色器可变

一个AI决策的简单示例：

cpp复制class AIBehavior {
public:
    void Update(float deltaTime) {
        GatherInformation();
        EvaluateSituation();
        ExecuteDecision(deltaTime);
        Cleanup();
    }
    
    virtual ~AIBehavior() = default;

protected:
    virtual void GatherInformation() = 0;
    virtual void EvaluateSituation() = 0;
    virtual void ExecuteDecision(float deltaTime) = 0;
    
    void Cleanup() {
        // 公共清理逻辑
    }
};

19. 模板方法模式的局限性

19.1 继承带来的耦合

模板方法模式最大的局限来自于它对继承的依赖。继承在C++中会带来：

1. 紧耦合：子类与基类紧密绑定，基类变化可能影响所有子类
2. 脆弱基类问题：基类的修改可能导致子类行为意外改变
3. 多重继承复杂性：当需要结合多个模板方法时，可能导致钻石继承等问题

19.2 现代C++的替代方案

对于这些局限，现代C++提供了几种替代方案：

1. 策略对象：将变化的部分封装为策略对象，使用组合而非继承
2. 函数对象：使用std::function等传递定制行为
3. 类型擦除：如std::any或自定义类型擦除容器

例如，使用策略对象重写之前的排序示例：

cpp复制class Sorter {
public:
    using SortStrategy = std::function<void(std::vector<int>&)>;
    
    Sorter(SortStrategy strategy) : strategy_(std::move(strategy)) {}
    
    void Sort(std::vector<int>& data) {
        PreProcess(data);
        strategy_(data);
        PostProcess(data);
    }

private:
    SortStrategy strategy_;
    
    void PreProcess(std::vector<int>& data) { /*...*/ }
    void PostProcess(std::vector<int>& data) { /*...*/ }
};

// 使用示例
Sorter quickSorter([](auto& data) { std::sort(data.begin(), data.end()); });
Sorter bubbleSorter([](auto& data) { /* 冒泡排序实现 */ });

这种方式更灵活，但失去了编译时检查的优势。

20. 个人经验与建议

20.1 何时选择模板方法模式

基于多年实践，我认为模板方法模式最适合以下场景：

1. 算法结构稳定：主流程不太可能改变
2. 变化点明确：只有少数几个步骤需要定制
3. 需要严格控制流程：如事务处理、资源管理等
4. 扩展点有限：不希望子类随意改变算法结构

一个典型的适用场景是协议处理——协议帧结构固定，但不同版本可能有不同的字段解析方式。

20.2 实际项目中的教训

从实际项目中，我总结了几个重要教训：

1. 文档化扩展点：明确记录哪些方法可以覆盖、如何覆盖，避免维护者误用
2. 考虑二进制兼容性：在动态库中使用时，虚函数表布局变化可能导致兼容性问题
3. 性能热点分析：虚函数调用在性能关键路径上可能成为瓶颈
4. 测试覆盖：确保测试所有可能的子类实现组合

最后，记住设计模式是工具而非目标。模板方法模式是一个强大的工具，但并非所有问题都适合用它解决。理解其适用场景和局限，才能做出最佳设计决策。