C++ 中函数模板常被看作泛型编程的核心工具，与强调继承、封装和多态的面向对象设计似乎分属两条路线。但两者并非互斥，函数模板可以在类层次结构中承担很多实际职责。比如把虚函数调用替换为编译期绑定、让接口接受更广泛的类型、把重复的工厂代码抽象成可复用函数，甚至在保留面向对象接口的同时隐藏具体实现类型。这些场景并不需要彻底放弃继承体系，而是用函数模板补齐纯虚函数方案的不足。
一、编译期多态与奇异递归模板模式
传统面向对象设计通过虚函数获得运行时多态，基类声明 virtual 函数，派生类重写，调用时经由虚表间接跳转。这种机制灵活，但每次调用都需要额外寻址，而且编译器难以对虚调用做内联优化。如果调用方在编译期就能确定对象的具体类型，函数模板可以生成针对该类型的特化版本，直接调用具体成员函数，消除间接开销。例如定义一个模板函数 render，它接收任意具备 draw 方法的类型，调用时编译器根据实参类型实例化对应代码。
奇异递归模板模式进一步把静态多态应用到继承体系内部。基类模板以派生类作为模板参数，通过 static_cast 获取派生类型，从而在基类中调用派生类的方法。这样既保留了基类提供公共逻辑的能力，又避免了虚函数表的运行时分发。下面是一个使用 CRTP 的图形绘制示例。
#include <iostream>
template <typename Derived>
class ShapeBase {
public:
void draw() const {
static_cast<const Derived*>(this)->drawImpl();
}
};
class Circle : public ShapeBase<Circle> {
public:
void drawImpl() const {
std::cout << "Drawing circle" << std::endl;
}
};
class Square : public ShapeBase<Square> {
public:
void drawImpl() const {
std::cout << "Drawing square" << std::endl;
}
};
template <typename Shape>
void render(const Shape& shape) {
shape.draw();
}
int main() {
Circle c;
Square s;
render(c);
render(s);
return 0;
}
ShapeBase 本身不包含虚函数，却为所有派生类提供了统一的 draw 接口。基类中的 draw 通过向下转型调用 drawImpl，编译器可以在编译期解析这段调用，因此函数体通常可以被直接内联。相较虚函数方案，这种方式在性能敏感场景中更有优势。需要注意的是，CRTP 无法把不同派生类放进同一个基类指针容器，因为 ShapeBase<Circle> 和 ShapeBase<Square> 是两个不同的类型。它适合编译期类型明确的场景，而运行时统一容器仍应交由虚函数或类型擦除处理。
函数模板与 CRTP 结合后，还可以把通用的比较、克隆、打印等逻辑放在基类，派生类只需实现少量钩子函数。这样既减少了重复代码，又保持了各派生类的独立类型信息。模板函数可以把这些 CRTP 类型当作普通类型处理，在算法层面继续复用编译期多态。
二、函数模板配合类型擦除统一接口
类型擦除是另一种让函数模板与面向对象设计协作的方式。它的目标是把具有相同行为但类型不同的对象包装成同一个非模板类型，从而可以存入容器或作为统一接口使用。标准库中的 std::function 就是典型例子：它可以持有任意可调用对象，而调用方只需要面对一个稳定的类类型。类型擦除的核心通常是一个抽象基类，以及一个模板派生类，后者用具体类型实例化并实现虚函数转发。构造函数模板在这里起到关键作用，它让外部可以自然地把任意类型转换为统一接口。
下面实现一个简化的 Task 类，将带有 run 方法的任意对象擦除为同一接口。
#include <iostream>
#include <memory>
#include <utility>
class Task {
private:
struct Concept {
virtual ~Concept() = default;
virtual void run() = 0;
};
template <typename T>
struct Model : Concept {
T obj;
explicit Model(T t) : obj(std::move(t)) {}
void run() override {
obj.run();
}
};
std::unique_ptr<Concept> impl;
public:
template <typename T>
explicit Task(T t) : impl(std::make_unique<Model<T>>(std::move(t))) {}
void run() {
impl->run();
}
};
struct Printer {
void run() const {
std::cout << "Printer task" << std::endl;
}
};
struct Logger {
void run() const {
std::cout << "Logger task" << std::endl;
}
};
int main() {
Task t1 = Printer{};
Task t2 = Logger{};
t1.run();
t2.run();
return 0;
}
这里 Task 的构造函数是一个模板函数，接收任意类型 T，并在内部生成对应的 Model<T> 适配器。对外部来说，Printer 和 Logger 都被转换为同一个 Task 类型，可以赋值、传入同一个函数参数，甚至放入 vector<Task> 中。函数模板负责在对象构造阶段完成编译期到运行时的桥接，面向对象的多态接口在运行时仍然有效。通过这种方式，函数模板让类接口具备了泛型扩展能力，调用者无需手动编写多个重载。
类型擦除的代价是仍然存在一次虚函数调用，但它的优势是接口统一且类型信息被隐藏。函数模板在这里不是替代虚函数，而是作为入口把多样性压缩到固定的继承接口之后。对库设计者来说，这种模式可以显著降低用户代码与具体类型之间的耦合。比如回调管理、事件监听、任务队列等场景都可以受益于模板构造函数加抽象基类的组合。
三、泛型工厂与策略注入中的模板函数
工厂模式在面向对象设计中常用于解耦对象创建与使用，但传统工厂方法容易为每一种产品类型写出结构相似的重载函数。函数模板可以把创建逻辑参数化，用同一个模板函数处理所有可构造类型。例如 create 模板接收构造参数包，返回 unique_ptr 对象。这种方式不仅减少了代码量，还能与 std::make_unique 的完美转发配合，确保参数值类别得到保留。
策略模式的传统实现也依赖继承和虚函数，通过基类接口切换不同算法。然而当策略在编译期已经确定时，使用模板参数传递策略类型可以避免虚函数调用，并允许编译器对算法代码进行更积极的优化。模板函数可以接受一个策略类型参数，在函数体内部调用该策略的静态方法。如果说继承策略适合运行时切换，那么模板策略更适合配置相对固定、性能要求较高的场景。
#include <iostream>
#include <memory>
#include <utility>
#include <vector>
#include <algorithm>
template <typename T, typename... Args>
std::unique_ptr<T> create(Args&&... args) {
return std::make_unique<T>(std::forward<Args>(args)...);
}
struct AscendingSort {
static void sort(std::vector<int>& data) {
std::sort(data.begin(), data.end());
}
};
struct DescendingSort {
static void sort(std::vector<int>& data) {
std::sort(data.rbegin(), data.rend());
}
};
template <typename SortPolicy>
void processData(std::vector<int>& data) {
SortPolicy::sort(data);
}
int main() {
auto ptr = create<std::vector<int>>();
ptr->push_back(3);
ptr->push_back(1);
ptr->push_back(2);
processData<AscendingSort>(*ptr);
for (int v : *ptr) {
std::cout << v << " ";
}
std::cout << std::endl;
processData<DescendingSort>(*ptr);
for (int v : *ptr) {
std::cout << v << " ";
}
std::cout << std::endl;
return 0;
}
在面向对象设计中，模板函数还可以作为类的成员函数，使同一个类能够处理不同类型而无需重载。比如一个 Processor 类提供模板成员函数 execute，调用方可以传入不同策略或不同数据类型。与在类外定义自由模板函数相比，成员模板函数可以直接访问 this 指针，方便把策略与对象状态结合起来。这种设计在插件系统、配置驱动应用和算法框架中很常见。
需要注意，函数模板虽然灵活，但过度使用可能导致代码膨胀和编译时间增加。每次使用新的模板实参都会生成新的代码实例。因此在实际设计中应当权衡编译期多态与运行时多态的使用边界：如果类型数量有限且编译期已知，优先考虑模板；如果类型需要动态扩展或统一存储，则保留虚函数接口。函数模板在面向对象设计中的拓展价值，正是让这两种机制在合适的层级上互补，而不是互相替代。