使用功能切换和 IoC 代替分支代码——好主意还是坏主意？答案

【问题标题】：Using Feature Toggling and IoC in lieu of Branching Code -- Good or Bad Idea?使用功能切换和 IoC 代替分支代码——好主意还是坏主意？
【发布时间】：2012-03-22 02:24:09
【问题描述】：

我们的客户可以选择何时升级。因此，我的团队实际上必须维护和支持我们软件产品的几十个版本。正如您可以想象的那样，这会导致大量的分支和合并，因为热修复和服务包必须在所有这些风格中传播。我对这种情况不满意。显而易见的解决方案就是不维护我们产品的这么多不同版本，但我无法使用这种显而易见的解决方案。所以，我正在探索创造性的选择来降低团队的维护工作。我正在考虑使用功能切换和 IoC 的组合来实现我们软件产品的 n 个版本。我的想法是我可以为我的产品使用单个代码库，并通过配置管理来管理行为和功能。这将代替必须跨多个分支传播代码。这是一种合理的方法，还是我只是用一个问题换另一个问题？

【问题讨论】：

听起来很合理。您将为单个代码库交易多个分支，打开和关闭功能。从理论上讲，您可以通过配置打开或关闭功能。如果您确实需要运行不同的代码，则可以使用具有不同代码实现的 IoC 容器。如果您的问题更具体，并举例说明您当前的风格与建议的风格，您的问题会更容易回答。
感谢 RaulG，您总结得很好，利用 IoC 处理不同的实现正是我的想法。我不确定如何回答您关于样式的问题。该应用程序已有十多年的历史，因此它不反映任何单一风格。我可能会将上述策略应用于重新设计的组件。听起来，拟议的战略并未引发任何危险信号。 -- 谢谢。

标签： inversion-of-control featuretoggle

【解决方案1】：

这听起来很合理，因为这将是我在新建环境中解决此类问题的方式。

不过，我们不要将其称为功能切换。顾名思义，Feature Toggle 是一个on/off 开关，这可能不是您所需要的。

有时，升级还涉及更改现有功能的行为。这意味着您可能需要比 on/off 开关更复杂的东西。

Strategy pattern 是一种更灵活的行为变化建模方法。每个策略都可以代表特定行为的特定版本，如果您根本不想要该行为，可以提供Null Object 实现。换句话说，Feature Toggle 可以通过 Strategy 来实现。

您可以使用依赖注入将策略注入您的应用程序内核，并且您可以通过配置系统对策略的选择进行配置。我听说过的大多数 DI 容器（在 .NET 和 Java 上）都支持基于文件的配置。

这基本上描述了一个插件架构。

现在，即使对于一个全新的应用程序，这也不是一件容易的事。如果您有一个无头系统，那那么并不难，但是一旦涉及到 UI，您就会开始意识到您还需要将 UI 架构组件化，以便您可以插入通过策略在 UI 元素中。

至少可以说，在已有十年历史的代码库中，这将是我所说的“有趣的挑战”。

【讨论】：