当策略模式遇上模板：C++中灵活性与性能的优雅结合
大家好，今天我想和大家聊聊C++设计模式中一个非常经典且实用的组合：策略模式与模板的结合。在我多年的项目开发中，尤其是在构建需要高性能和灵活算法的库时，这种组合拳帮我解决了不少棘手的问题。它既保留了策略模式的运行时灵活性，又通过模板在编译期优化了性能，可以说是“鱼与熊掌兼得”的典范。
一、回顾经典策略模式及其痛点
我们先快速回顾一下经典的策略模式。它的核心思想是将算法族（一组相关的算法）封装起来，让它们可以相互替换，并且算法的变化独立于使用算法的客户端。通常我们会定义一个抽象的策略接口，然后派生出不同的具体策略类。
下面是一个简单的排序策略示例：
// 抽象策略接口
class SortStrategy {
public:
virtual ~SortStrategy() = default;
virtual void sort(std::vector& data) const = 0;
};
// 具体策略A：冒泡排序
class BubbleSortStrategy : public SortStrategy {
public:
void sort(std::vector& data) const override {
// 冒泡排序实现...
std::cout << "Using Bubble Sortn";
for (size_t i = 0; i < data.size(); ++i) {
for (size_t j = 0; j data[j + 1]) {
std::swap(data[j], data[j + 1]);
}
}
}
}
};
// 具体策略B：快速排序
class QuickSortStrategy : public SortStrategy {
public:
void sort(std::vector& data) const override {
// 快速排序实现...
std::cout << "Using Quick Sortn";
if (data.empty()) return;
quickSort(data, 0, data.size() - 1);
}
private:
void quickSort(std::vector& data, int low, int high) const {
// 递归实现略...
}
};
// 上下文类
class Sorter {
std::unique_ptr strategy_;
public:
explicit Sorter(std::unique_ptr strategy)
: strategy_(std::move(strategy)) {}
void setStrategy(std::unique_ptr strategy) {
strategy_ = std::move(strategy);
}
void executeSort(std::vector& data) {
strategy_->sort(data);
}
};
这种实现很清晰，但有一个明显的性能痛点：虚函数调用开销。每次调用 sort 方法都需要经过虚函数表（vtable）查找，这在性能敏感的循环或高频调用场景下会成为瓶颈。此外，动态多态要求策略对象必须通过指针或引用操作，可能带来额外的内存分配和间接访问成本。
二、引入模板：编译期策略绑定
为了解决运行时多态的开销，我们可以引入模板，将策略的选择从运行时转移到编译期。这样，编译器就能为每种策略组合生成特化的代码，并进行内联等优化。
我们将上面的例子用模板重写：
// 策略作为模板类型参数
template
class BubbleSortStrategy {
public:
void operator()(std::vector& data) const {
std::cout << "Using Bubble Sort (Template)n";
for (size_t i = 0; i < data.size(); ++i) {
for (size_t j = 0; j data[j + 1]) {
std::swap(data[j], data[j + 1]);
}
}
}
}
};
template
class QuickSortStrategy {
public:
void operator()(std::vector& data) const {
std::cout << "Using Quick Sort (Template)n";
if (data.empty()) return;
quickSort(data, 0, data.size() - 1);
}
private:
void quickSort(std::vector& data, int low, int high) const {
// 实现略...
}
};
// 上下文类也变为模板类
template
class Sorter {
SortStrategy strategy_; // 策略作为成员变量，编译期确定类型
public:
// 构造函数可以接受策略实例，也可以默认构造
explicit Sorter(SortStrategy strategy = SortStrategy{})
: strategy_(std::move(strategy)) {}
void executeSort(std::vector& data) {
strategy_(data); // 直接调用，可能是内联的！
}
// 注意：策略类型在编译期固定，无法在运行时动态改变
};
实战提示： 这里我让策略类重载了 operator()，使其成为函数对象（Functor）。这样做的好处是语法统一（像调用函数一样使用策略），并且与C++标准库算法（如 std::sort）的风格一致。
使用方式如下：
int main() {
std::vector data = {5, 2, 8, 1, 9};
// 编译期确定使用冒泡排序
Sorter<int, BubbleSortStrategy> bubbleSorter;
bubbleSorter.executeSort(data);
// 编译期确定使用快速排序
Sorter<int, QuickSortStrategy> quickSorter;
quickSorter.executeSort(data);
return 0;
}
看到了吗？策略类型 BubbleSortStrategy 是作为模板参数传入的。这意味着在编译时，编译器就已经知道 Sorter 内部使用的是哪种策略，并可以针对性地进行优化，很可能将 strategy_(data) 直接内联展开。性能测试中，这种方式的调用开销几乎为零，与直接调用函数对象无异。
三、结合两种方式的优势：策略 Traits 与模板特化
纯模板方法有一个明显的局限：策略无法在运行时动态切换。有时候，我们既想要编译期优化的性能，又希望保留一定的运行时灵活性。这时，我们可以采用一种折中方案：使用“策略特征”（Policy Traits）和模板特化。
假设我们有一个数据处理器，它根据数据规模选择不同的算法：小数据用简单算法（开销小），大数据用复杂算法（效率高）。我们可以这样设计：
// 策略特征类，默认策略
template
struct ProcessingPolicy {
using Strategy = QuickSortStrategy; // 默认使用快速排序
};
// 特化：当处理小数据时，使用冒泡排序
template
struct ProcessingPolicy { // 阈值设为100
using Strategy = BubbleSortStrategy;
};
// 上下文类，根据阈值选择策略
template
class DataProcessor {
using StrategyType = typename ProcessingPolicy::Strategy;
StrategyType strategy_;
public:
void process(std::vector& data) {
std::cout << "Data size: " << N << ", ";
strategy_(data);
}
};
使用方式：
int main() {
std::vector smallData(50); // 小于100
std::vector largeData(5000); // 大于1000
// 编译器根据模板参数N（这里是50）选择ProcessingPolicy的特化版本
DataProcessor processorForSmall;
processorForSmall.process(smallData); // 会使用BubbleSortStrategy
// 编译器根据模板参数N（这里是5000）选择默认的ProcessingPolicy
DataProcessor processorForLarge;
processorForLarge.process(largeData); // 会使用QuickSortStrategy
return 0;
}
踩坑提示： 这里的 N 是编译期常量（模板参数），它代表的是你预期或典型的数据规模，而不是运行时实际的 data.size()。如果你需要根据运行时实际大小动态选择，那么可能还需要结合一点传统的多态，或者使用 if constexpr（C++17）在编译期分支。
四、更高级的玩法：策略作为模板模板参数
有时候，策略本身也可能是模板类（比如我们的排序策略都模板化了）。为了让上下文类更通用，我们可以使用“模板模板参数”。
// 上下文类接受一个模板模板参数
template <typename T, template class SortPolicy>
class GenericSorter {
SortPolicy policy_; // 用类型T实例化策略模板
public:
void sort(std::vector& data) {
policy_(data);
}
};
// 使用
int main() {
std::vector values = {3.14, 2.71, 1.41};
GenericSorter sorter; // 注意这里传的是模板名，不是实例
sorter.sort(values);
return 0;
}
这种写法让 GenericSorter 的接口非常干净，它只关心策略模板，而不关心策略模板具体是用什么类型实例化的（由 GenericSorter 自己的模板参数 T 决定）。这在设计通用库组件时非常有用。
五、总结与选择建议
回顾一下我们的探索历程：
- 经典策略模式（虚函数）：优点在于运行时动态替换策略，非常灵活，符合开闭原则。缺点是虚函数调用开销和对象生命周期管理成本。
- 模板化策略：优点是无虚函数开销，编译期优化潜力大，性能高。缺点是策略在编译期绑定，失去了运行时动态切换的能力，可能导致代码膨胀（每个特化都会生成一份代码）。
- 混合方法（Traits、模板特化）：试图在两者间取得平衡，通过编译期条件选择策略，保留了一定灵活性同时优化了性能。
我的实战经验建议：
- 如果你的策略在程序运行后就不会改变，或者性能是首要考虑因素（如图形渲染、数值计算、高频交易核心路径），请优先考虑模板化策略。
- 如果你的应用需要频繁地在运行时切换策略（比如根据用户配置选择算法），或者策略对象本身状态复杂，需要多态，那么经典策略模式更合适。
- 不要害怕混合使用。在一个大型系统中，你完全可以在底层模块使用模板化策略保证性能，在高层控制模块使用经典策略模式提供灵活性。C++的强大之处就在于它提供了多层次、多维度的抽象工具，让我们可以针对不同的问题选择最合适的武器。
希望这篇结合我个人踩坑经验的文章，能帮助你更好地理解和运用C++中策略模式与模板这对强大组合。记住，没有最好的模式，只有最合适的场景。多思考，多实践，你一定能找到那个优雅的平衡点。
评论(0)