C++无侵入式接口重构：提取公共逻辑的最优方案探讨

你的抽象类方案完全合理 #

这是模板方法模式的标准用法，完美匹配你的需求：

• 原FooInterface接口完全不受影响，满足"不污染原接口"的要求
• 把Method1里重复的分支逻辑抽到抽象类FooAbstractClass中固定下来，只把可变的具体操作（Method2/Method3）留给子类实现
• 用final修饰Method1还能避免子类篡改核心流程，保证逻辑一致性

优化后的代码示例 #

先明确原接口（保持不变，补全必要的访问权限）：

class FooInterface {
public:
    virtual void Method1(bool method) = 0;
};

抽象基类封装公共逻辑（修正继承权限和访问控制）：

class FooAbstractClass : public FooInterface {
public:
    void Method1(bool method) final override {
        if (method) {
            Method2();
        } else {
            Method3();
        }
    }

protected: // 将虚方法设为protected，防止外部直接调用
    virtual void Method2() = 0;
    virtual void Method3() = 0;
};

子类实现具体逻辑：

class BarClass1 : public FooAbstractClass {
protected:
    void Method2() final override { /* BarClass1 专属业务逻辑 */ }
    void Method3() final override { /* BarClass1 专属业务逻辑 */ }
};

class BarClass2 : public FooAbstractClass {
protected:
    void Method2() final override { /* BarClass2 专属业务逻辑 */ }
    void Method3() final override { /* BarClass2 专属业务逻辑 */ }
};

预期使用方式不变：

BarClass1 bar1;
bar1.Method1(true);

BarClass2 bar2;
bar2.Method1(false);

有没有更优的替代方案？ #

如果未来需要更灵活的逻辑组合（比如不同的分支判断逻辑搭配不同的具体操作），可以考虑策略模式：把Method2/Method3抽象成独立策略接口，让实现类持有策略对象。但就当前场景而言，模板方法模式已经是最简洁、最贴合需求的选择，策略模式会额外增加类的数量，属于过度设计。

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