c++ - 编译时接口(interface)定义的最佳实践

Question

假设我有以下我有机会改进的遗留代码:

class BaseInterfaceClass
{

#if( HAS_FEATURE_A == 1 )
    void doFeatureA1() = 0;
    void doFeatureA2() = 0;
#endif

#if( HAS_FEATURE_B == 1 )
    void doFeatureB1() = 0;
    void doFeatureB2() = 0;
    void doFeatureB3() = 0;
#endif

#if( HAS_FEATURE_C == 1 )
    void doFeatureC1() = 0;
#endif

    void doBaseFeature1() = 0;
    void doBaseFeature2() = 0;
};

有没有办法在不增加新设计的运行时大小的情况下取消在编译时定义接口(interface)的#ifdef 方法？换句话说，我需要保留这样一个事实，即仅使用 HAS_FEATURE_A 编译的派生类将不包含 HAS_FEATURE_B 或 HAS_FEATURE_C 的代码(与被链接的代码相比，只是因为运行时检查而没有实际使用)。

一些注意事项

1. 功能标志并不相互排斥。可以定义它们的任意组合。

2. 在我看来，为每个功能定义一个子类，然后使用多重继承将所需的接口(interface)组合在一起是不够的。请记住，派生类必须能够在编译时实现这些功能的任意组合，并且不包含未为该编译定义的功能。

3. 更改代码的政治成本意味着我必须能够摆脱所有指令，或者根本不这样做。换句话说，仅仅移动 #ifdef 定义来使基类更漂亮是不够的。

4. 有足够多的特征组合，任何蛮力方法都是不现实的。我不会制作成千上万的子类。

5. 我不知道模板，但如果这是关键，我愿意学习。

Answer 1

有办法。然而它们真的有用吗？

许多库使用 #if 条件编译来提出额外的选择加入功能。这是一个长期确立的做法。

您可以使用混入“消除”这一点，但不确定代码是否会因此变得更具可读性。相反，使用您的代码的人现在必须了解发生了什么，而以前很明显。

另一方面，由于我们谈论的是界面，您可能希望将界面分成几个组件(如果可能)，每个组件专用于多个功能。知道你是否可以需要更多关于这个类的复杂性的知识......但对我来说它看起来太像上帝对象了。