功能相同但变量、方法名不同的两个C++类如何重构避免代码重复？

你描述的场景完全可以通过模板机制实现逻辑复用，普通非模板继承因为和两个类的业务设计存在语义冲突，并不适配该场景。

适配场景的核心实现方案 #

1. CRTP 模板基类抽公共逻辑（最适合长链路重复操作） #

核心思路是将所有重复的操作逻辑抽到一个模板基类中，基类不直接持有类成员，而是通过子类的轻量访问接口获取对应业务命名的私有成员，全程不需要修改两个类原本的成员命名、对外方法的业务语义。
针对示例代码的重构实现如下：

// 公共操作模板基类，模板参数为具体的业务子类类型
template <typename Derived>
class CommonOperation
{
public:
    // 所有重复逻辑统一维护在这里，后续修改只需要改这一份代码
    float calcSum() const {
        const Derived& self = static_cast<const Derived&>(*this);
        // 通过子类提供的内部访问器获取对应业务的成员值，不要求成员名一致
        return self.getMember1() + self.getMember2();
    }

    // 实际开发中，其他所有需要重复实现的复杂计算、状态更新逻辑都可以写在这里
};

class A : public CommonOperation<A>
{
private:
    float m; // 类A自己业务语义的成员命名
    float n; // 类A自己业务语义的成员命名
    // 仅给公共基类提供访问入口，不对外暴露私有成员
    float getMember1() const { return m; }
    float getMember2() const { return n; }
    friend CommonOperation<A>;
public:
    // 对外业务方法直接调用基类的公共逻辑即可
    float foo() { return calcSum(); }
};

class B : public CommonOperation<B>
{
private:
    float p; // 类B自己业务语义的成员命名，和A的m类型、作用完全一致
    float q; // 同上
    // 同样提供访问入口，不需要修改自己的业务命名
    float getMember1() const { return p; }
    float getMember2() const { return q; }
    friend CommonOperation<B>;
public:
    // 对外业务方法保持自己的命名，直接调用公共逻辑
    float bar() { return calcSum(); }
};

该方案的特性：

• 无运行时开销，所有成员访问都是编译期确定的，和直接在类内部写逻辑的性能完全一致
• 完全保留两个类各自的业务命名语义，不需要为了复用代码强行统一成员名、方法名
• 重复逻辑只维护一份，后续调整操作流程时不需要同步修改两个类的代码，避免漏改
• 不存在A、B两个类之间的继承耦合，模板实现的基类和子类的关联是编译期独立的

2. 独立工具类组合调用（适合改造侵入性低的场景） #

如果不想引入继承关系，可以把所有重复的操作逻辑抽成独立的无状态工具类，两个业务类在自己的方法内部，将对应的业务成员传入工具类执行逻辑，全程不修改原有类的继承结构。
针对示例代码的重构实现如下：

// 独立的公共逻辑工具，不依赖任何业务类
struct CommonCalcUtil
{
    // 所有重复操作以泛型静态方法实现，接收需要操作的成员作为入参
    static float sum(float a, float b) {
        // 实际开发中所有复杂的计算、转换、状态校验逻辑都可以写在这里
        return a + b;
    }
};

class A
{
private:
    float m;
    float n;
public:
    float foo() {
        // 调用公共工具，传入自己的业务成员
        return CommonCalcUtil::sum(m, n);
    }
};

class B
{
private:
    float p;
    float q;
public:
    float bar() {
        // 调用同一个公共工具，传入自己对应的业务成员
        return CommonCalcUtil::sum(p, q);
    }
};

该方案的特性：

• 完全无继承耦合，类之间的依赖关系最轻
• 复用粒度更细，后续其他类如果有相同的操作需求，可以直接调用这个工具类
• 改造成本极低，只需要把原有类内部的重复逻辑替换成工具类调用即可，不需要调整类的私有成员权限、友元关系

为什么普通公共继承不适配该场景 #

很多人第一反应会抽一个非模板的公共基类，把公共成员、公共方法放到基类中，这种方式在你的场景下存在明显的问题：

• 基类需要统一成员命名，会直接破坏两个类原本的业务语义——为了复用代码，必须把A的m和B的p改成同一个基类成员名，和最初的业务设计冲突
• 子类的对外方法是各自的业务命名（比如A的foo、B的bar），没法通过基类的统一接口满足不同的对外命名需求，最终还是要在每个子类里重写一遍方法实现，达不到减少重复代码的效果
• 强耦合的is-a继承会让两个类和基类深度绑定，后续修改其中一个类的逻辑时，很容易意外影响到另一个类的行为

选型参考 #

• 如果重复逻辑和类的内部状态深度绑定、操作链路很长（需要访问多个私有成员、跨多个步骤完成计算），优先选CRTP模板基类的方案，代码结构更清晰
• 如果重复逻辑是相对独立的计算、转换类操作，优先选独立工具类组合的方案，改造的侵入性最低

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