单例模式：好的设计还是一个替代品？

编写正常的、可测试的、可注入的对象，让Guice/Spring/任何其他框架来处理实例化。这是非常重要的。
即使在缓存或单例的自然用例中，也应该这样做。没有必要重复编写代码来尝试强制执行一个实例的恐怖。让你的依赖注入框架来处理它。（如果你还没有使用过依赖注入容器，我推荐使用轻量级的Guice）。

我非常不赞同“穿着花哨的全局变量”这个想法。单例模式在解决正确的问题时非常有用。让我给你举个实际的例子。

我曾经为我工作的一个地方开发了一小段软件，一些表单需要使用公司、员工、服务和价格等信息。在第一个版本中，系统每次打开表单时都会从数据库加载数据。当然，我很快意识到这种方法并不是最好的。

然后我创建了一个名为“company”的单例类，它封装了关于该地方的所有信息，并在系统打开时完全填充了数据。

这不仅仅是一堆穿着花哨的变量，因为它有数十个职责，比如与持久层通信以保存/检索有关公司的数据，处理员工和价格集合等。

此外，它是一个固定的、系统范围内易于访问的公司数据点。

单例模式非常有用，使用它们本身并不是反模式。然而，它们因为强制消费代码承认它们是单例以便与之交互而声名狼藉。这意味着如果您需要“取消单例化”它们，对您的代码库的影响可能非常大。

相反，我建议将单例隐藏在工厂后面。这样，如果您将来需要更改服务的实例化行为，只需更改工厂而不是所有消费单例的类型。

更好的方法是使用控制反转容器！它们中的大多数允许您将实例化行为与类的实现分离。