singleton - "Singleton"工厂，好还是坏？

Question

我有很多(抽象)工厂，它们通常被实现为单例。

通常是为了方便，不必让他们通过那些真正与使用或了解这些工厂无关的层。

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

它看起来例如像

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();
    ....

}

有些东西确实闻到了这个味道，我只是不确定是什么——它可能更像是一个不合时宜的全局而不是一个单例。并不是真的只有一个工厂可以创建 ColumnCalculations——尽管我的程序不需要更多。

这被认为是最佳做法吗？我是否应该将这些东西放在一些(半)全局 AppContext 类中？别的东西(我还没有准备好切换到一些更大的 IoC 容器，或者 spring.net 还顺便说一句)？

Answer 1

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

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

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

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