问项目中有太多的单例--这是不是一种糟糕的做法？

EN

单例不一定是问题-拥有一个在其领域内是专家的单一对象可能非常有用-但显式地将单例编码到对象中几乎总是一个糟糕的想法(而且经常做得也很糟糕)。事实证明，最好将应用程序的配置-包括决定哪些类具有单例实例化-留给专门处理该问题的单独层，例如Spring for Java。这样，管理层可以关注什么是单例，什么是特定上下文中的单例(例如，在会话的范围内)，以及总是需要重新制造的内容。这让您可以专注于编写业务逻辑。

关于单例为什么会成为问题，以及为什么它们应该通过管理/配置成为单例，请考虑管理到数据库的连接的类。你可能会说，这是一个独生子女的典型案例。您也是对的，直到您发现您的应用程序已经发展到必须集成到两个数据库的连接的地步(这是真的！)然后你就得把这些乱七八糟的东西弄清楚。如果您的代码不知道它是否处理单例，那么您很有可能只需重新配置就能处理所有这些问题；一些类将连接到一个DB，另一些将连接到另一个DB，但它们将以最小的速度继续处理。(需要两个…的任何东西这就是为什么我说“极好的机会”的原因。)

为什么单例可能是问题的另一个例子是当你为你的代码写测试的时候。(你会写测试，对吧？)显式单例很难测试，因为它们很难配置，也很难隔离。您不能在两次测试之间正确地拆分它们，因为这意味着有许多它们。如果您的应用程序仅通过配置使用单例，则测试配置可以很容易地更改这一点，并且您可以更轻松地执行测试。

关于这个话题有很多讨论。对某些人来说，单例被认为是一种anti-pattern。然而，它可能非常有用，但它往往比看起来更难正确地实现。在某些情况下，它的使用是合理的，例如，对于整个应用程序通用的数据有一个唯一的入口点-这就是棘手的部分，它是伪装的全局状态，当且仅当数据是不可变的时，才能安全使用。

顺便说一句，最新版本的JEE6企业版现在包含了单例模式的support作为一个组件。但是想一想，这个标准花了六次修订才最终完成！

自从TDD取代了它的位置，程序员们认识到测试单例是一件痛苦的事情，并开始避免它。同样的效果可以通过注入所需的类/资源来实现，例如连接管理器、资源管理器等。这样，在测试环境中，可以简单地模拟、注入和覆盖这些类。

另一方面，在某些情况下，只使用单例似乎是正确的方式-确保只有一个实例存在。也就是说，它对连接池很有用，因为它保证了一个且只有一个实例同时存在，并且不会有任何泄漏。(注意:并不是所有单例模式的实现都能真正提供这一点。在Java中，正确的方法是使用枚举-因为语言本身确保了它的唯一性。)

总而言之，我的答案是肯定的，使用太多单例是不好的。请考虑使用DI原则。