抵住单例模式的诱惑

Resist the Temptation of the Singleton Pattern

单例模式可以解决你的很多问题。你会认为只要单例模式就够了。这可以保证实例在初始化之前就能使用。通过一个全局指针访问就能保持你的设计简洁。这么经典的设计模式还有什么不对的地方吗?

其实太多了。它们可能很有诱惑力,但根据经验来看,其所带来的损害要大过好处。它们阻碍了可测试性和可维护性。不幸的是,这种认识应该还没有得到广泛的传播,单例模式仍然吸引住广大程序员中的。但它们值得被抵抗:

  • 单例需求是被幻想出来的。很多情况下,它只是对未来不会再有新增实例的纯粹推测。把这种推测贯穿到整个应用程序设计势必会在某些地方引起痛苦。需求总会变。好的设计拥抱这一点,单例模式不会。
  • 单例导致概念上独立的代码单元之间存在隐式依赖。所造成的问题是单例在单元之间是隐藏的,并引入了不必要的耦合。当你尝试写个松耦合的单元测试有选择性地来模拟真实情况的时候,这种代码闻起来相当刺鼻。单例简单粗暴地阻碍了这种模拟。
  • 单例还会带有隐式的持久状态,再次阻挠了单元测试。单元测试是彼此独立了,因此测试可以在任何情况下运行,程序在每次测试执行前也可以设置为一个已知的状态。一旦你在可变状态下引入单例,就很难达到效果。此外,这种全局访问的持久状态将会使代码变得更难以查找问题,尤其是在多线程环境。
  • 多线程进一步加大了单例模式的陷阱。简单的加锁访问不是很有效率,被称作双重验证锁的模式(DCLP)广受欢迎。不幸的是,这可能是一种致命吸引力的形式,不论在哪里,都仍然有可能弄巧成拙。

清除单例也存在着最终的挑战:

  • 不支持显式杀死单例。在某些情况下这是个很严重的问题,例如,在插件架构中,一个插件只有在所有对象都被清理干净后才能被安全写在。
  • 不支持在程序退出后隐式清理。对于含有相互依存的单例将会非常麻烦。当应用程序关闭时,某个单例可能会去访问其他已经被销毁的(对象)。

这其中的一些缺陷可通过引入额外的机制来解决。但无不如何,这样做的代价是增加了代码本可以用其他设计来避免的复杂度。

所以,把你使用的单例模式限制在永远不会实例化超过一次的类上。不要在含糊不清的代码里使用单个全局访问指针。相反,对单例的直接访问应该来自几个定义明确的地方,可以通过接口传递给其他代码。这里的其他代码是不知道它的,不需要依赖单例或其他类的实现接口。这就破除了单元测试的依赖性,并提高了可维护性。所以,下次你想要实现和访问单例的时候,我希望你能三思而后行。

0%