C++ CRTP场景下调用派生类重写initialize方法的实现问询

需求完全可以实现，你当前的奇异递归模板（CRTP）骨架结合非虚接口（NVI）设计模式就能完美匹配需求，同时保留多态能力。

核心问题分析 #

你当前的写法会出现循环调用问题：如果派生类重写了initialize虚函数，基类system中调用派生类initialize时会触发虚函数动态分发，又跑回基类的initialize实现，导致无限递归。
解决方案是拆分接口：把多态入口和用户扩展点分离，用NVI模式固定执行流程。

可运行实现代码 #

1. 修正基类定义（统一你代码中的service_base/system_base笔误） #

struct service_base {
  virtual ~service_base() = default;
  // 多态入口纯虚函数
  virtual void initialize() = 0;
};

2. 重构中间CRTP基类system #

template<typename Derived>
class system : public service_base {
public:
  ~system() override = default;

  // 实现基类纯虚接口，加final禁止派生类重写，避免流程被破坏
  void initialize() override final {
    // 先执行派生类自定义初始化逻辑
    static_cast<Derived*>(this)->initialize_impl();
    // 派生类逻辑执行完成后，处理基类内部状态
    // 此处填写你的system基类通用状态处理代码
  }
};

3. 用户派生类实现 #

用户只需要实现非虚的扩展点initialize_impl，不需要关心基类流程和多态接口实现：

class my_system final : public system<my_system> {
public:
  ~my_system() override = default;

  // 用户自定义初始化逻辑写在这里即可
  void initialize_impl() {
    // 业务自定义代码
  }
};

方案验证 #

• 多态能力完全保留：所有派生自service_base的实例都可以存入std::vector<std::unique_ptr<service_base>>容器，调用initialize()时自动执行完整流程
• 执行顺序符合要求：永远先跑用户自定义的initialize_impl，再跑基类的内部状态处理逻辑
• 编译期安全：如果用户没有实现initialize_impl，编译阶段就会报错，不会出现运行期问题

适用设计模式说明 #

• 奇异递归模板模式（CRTP）：你原本使用的模式，在编译期绑定派生类类型，静态调用派生类方法，没有虚函数额外开销
• 非虚接口（NVI）模式：把固定的执行流程封装在基类的接口实现中，仅暴露扩展点给派生类，保证核心流程不会被派生类修改

替代方案 #

如果不想使用CRTP，仅用NVI模式也可以实现：

struct service_base {
  virtual ~service_base() = default;
  // 公共多态入口，固定执行流程
  void initialize() {
    initialize_impl();
    // 基类内部状态处理代码
  }
protected:
  // 派生类扩展点，纯虚函数
  virtual void initialize_impl() = 0;
};

该方案不需要模板，更简洁，但是无法实现编译期的派生类类型检查和静态绑定，适合简单场景使用。

内容的提问来源于stack exchange，提问作者Symlink