特定于客户端的自定义的条件编译与运行时检查?

时间:2013-09-24 07:27:46

标签: c++ conditional-compilation maintainability

作为供应商,我们需要将应用程序发送到许多客户端,有时我们需要为特定客户端自定义应用程序,例如通过启用或禁用某些功能,或为该客户端设置适当的默认值。

我已经看到在一些开源项目中,这是用这种模式完成的:

#define ENABLE_FEATURE_XYZ 0

#if ENABLE_FEATURE_XYZ
void featureXyzImpl()
{
    ...
}
#endif

void main()
{
#if ENABLE_FEATURE_XYZ
    featureXyzImpl();
#endif
}

这里通过将ENABLE_FEATURE_XYZ定义为0或1来打开或关闭该功能。好处是不需要的代码不存在。

但有些同事认为,在现实世界中,您需要通过查看配置文件或注册表设置在运行时执行自定义,而不是使用此模式:

void featureXyzImpl()
{
    ...
}

void main()
{
    if (configFileValue("Enable Feature XYZ") == true) {
        featureXyzImpl();
    }
}

他们的理由是它更容易维护和测试软件,因为您不需要重新编译来启用或禁用某个功能,您不需要保留库或可执行文件的多个版本,而您只能向测试人员发送一个版本,测试人员可以在运行时启用或禁用功能。

是否有指导或方法来决定哪种方法对特定情况更好?或者,我们只需在硬币投掷之间做出选择,还是出于个人喜好?

2 个答案:

答案 0 :(得分:1)

如果您为每个客户系统单独编译应用程序,我会说您可以将其作为"条件编译"。 如果你有一些客户群,你也应该这样做,而且你不希望任何人都可以" hack"你的程序滥用他不付钱的功能。 但在任何其他情况下,我可以想象在运行时禁用它也是更好的解决方案。

修改

根据您的运行时示例:这是您拥有的唯一选择,如果您是第三方提供商,客户必须自己打开功能,而您只需将客户的内容记录下来使用过。

答案 1 :(得分:1)

我认为这取决于“有时”多少。 如果您通过为每个客户构建单独的版本来启用/禁用功能,那么您需要仔细跟踪您向客户提供的内容,因为您需要支持特殊版本的应用程序。 使用配置文件时,聪明的客户可能有机会启用他没有支付的功能,但维护更容易。 我会尽可能长时间地使用配置文件,因为它们更容易维护。