使用spring避免单例模式

Question

考虑到Spring框架可以管理与对象创建相关的几乎所有东西(生命周期、对象范围.)，在使用该框架的应用程序中使用单例模式是否需要更长的时间，还是仍然需要使用singleton模式而不是Spring创建的单例实例？

使用单例模式的问题之一是全局状态。该问题是否避免使用Spring定义的单例范围？

Answer 1

“使用单例模式的问题之一是全局状态”

如果将其用于全局状态，则可以这样做。但这并不影响“单例模式”本身，因为它回答了一个对象可能有多少个实例的问题:一个。

“全局”和“国家”不回避“可能有多少个实例？”的问题。他们提出的问题是“范围是什么？”以及“数据可能发生变化吗？”(易变)。

春天会为你安排单身。但是范围和可变性取决于您的定义。

Answer 2

静态单子的问题不是全局状态本身。问题是，它们通常用于不透明的事物--最常见的例子之一是数据库连接。

静态单例错误的一个主要原因是:您可以在应用程序中的任何位置，在任何类中获得一个类的实例，而不需要让某个类的用户知道依赖项的实际存在。

显然，即使您没有静态的单例，并且在某种程度上遵循依赖注入，您也可以通过构造一个适当的依赖项(而不是传递)实现相同的目标。但是通常，当您这样做时，您会更早地意识到某些事情是不正确的(尤其是当构造的依赖项严格遵循依赖注入时，您突然看到的不是一个，而是像构造对象图的7个new调用)。辛格尔顿发出了一种感觉，那就是它实际上是好的，而在某些情况下，它并不是这样。

通过隐藏的依赖关系，您可以运行一个函数，在开发模式下(或者作为单元测试套件的一部分)接受一个字符串参数。该函数将突然调用生产数据库，因为它在内部使用单例。如果依赖关系是事先知道的(依赖项将被传递到函数中)，那么您可能会问自己为什么函数首先需要一个数据库，在调用它之前要更加小心。

Spring的特点是，它不会解决设计问题。但是，它可以通过运行它的魔力并根据某些规则将类连接在一起，从而使构建一个高度解耦的设计(其中几乎所有东西都是作为依赖项传递)变得更容易。

如果从Spring检索服务类和模块(或任何其他类类型)，则不再需要修改工厂并仔细管理实例。

要确保只存在一次的东西，实际上只有在配置框架和设置好之后才会存在。这真是太棒了。明显的缺点是，它是以某种方式完成的，对于经验较少或根本没有IoC容器经验的程序员来说，这一神奇之处可能会让人望而却步(参见知识诅咒)。

我个人是介于一个完整的IoC框架是好是坏之间。我喜欢让一些容器负责管理我的类并确保它们的作用域，但我不太喜欢使用某种XML配置器来完成所有这些配置。我更喜欢自己对类进行new，将手动newed实例插入到可选择的容器中，然后始终使用容器来检索它们。

手动部分只有一种方式，进入容器。如果我有一个类需要依赖项，我将从容器中请求它，这意味着我必须先在那里设置它。

Answer 3

传统的Singleton定义意味着确保只存在单例类的一个实例，并提供对该实例的全局访问。

这并不理想，因为a)全局状态意味着对单例的依赖可能是不明确的，而b)您不能创建第二个版本，例如用于测试。

如果不遵循传统的单例模式，而只需使用Spring确保给定类只有一个对象并将其注入需要的地方(即将依赖关系显式化)，那么这两个问题都会得到解决。