“单例”工厂，好还是坏？

我有很多（抽象）工厂，它们通常作为单例实现。

通常是为了方便，不必将它们传递给实际上与使用或了解这些工厂无关的层。

大多数时候我只需要在启动时决定哪个工厂实现其余的代码程序，也许通过一些配置

它看起来例如喜欢

abstract class ColumnCalculationFactory { 
  private static ColumnCalculationFactory factory;
  
  public static void SetFactory(ColumnCalculationFactory f) {
    factory = f;
  }

  public static void Factory() {
    return factory;
  }

  public IPercentCalculation CreatePercentCalculation();
  public IAverageCalculation CreateAverageCalculation();
   //....
}

有些东西确实闻到了这一点，我只是不确定是什么 - 它可能更像是一个隐藏的全局而不是一个单例。这并不像真的那样have to成为唯一一个创建 ColumnCalculations 的工厂 - 尽管我的程序不需要更多。

这被认为是最佳实践吗？我应该将它们填充到一些（半）全局 AppContext 类中吗？还有什么（我还没有准备好切换到更大的 IoC 容器，或者 spring.net 顺便说一句）？

这实际上取决于您正在做什么以及您的应用程序范围。如果它只是一个相当小的应用程序，并且永远不会超出这个范围，那么您当前的方法很可能没问题。这些事情没有通用的“最佳”实践。虽然我不建议将单例用于无状态叶方法和/或单向调用（例如日志记录）之外的任何内容，但“仅仅因为”它是单例而立即忽略它并不一定是正确的做法。

对于除琐碎代码或原型代码之外的任何内容，我个人喜欢通过构造函数注入显式使用控制反转，因为这意味着所有依赖项都被考虑在内，并且您不会得到任何“惊喜”。编译器不会让你实例化没有 B 的 A 和没有 C 的 B。单例会立即埋葬这些关系——你可以实例化没有 B 的 A 和没有 C 的 B。当从 A 到 B 的调用发生时，你将得到一个空引用例外。

这在测试时尤其烦人，因为您必须通过运行时故障迭代地向后工作。当您测试代码时，您就像其他编码员一样使用 API，因此这表明了这种方法的设计问题。构造函数注入确保这种情况永远不会发生——所有依赖项都已预先声明。构造函数注入的缺点是对象图的配置更加复杂。通过使用 IoC 容器可以缓解这种情况。

我想我想说的是，如果您已经考虑使用某种上下文对象和注册表模式，那么您不妨看看 IoC 容器。当您可以使用像 Autofac 这样成熟的免费产品时，努力推出自己的 mutt 版本可能是浪费时间。