编程中单例的目的

the*_*man 50 language-agnostic theory singleton

这无疑是一个相当宽松的问题.我目前对单身人士的理解是,他们是一个你设置的类,只有一个实例被创建.

这对我来说听起来很像静态类.主要区别在于,对于静态类,您不能/不能实例化它,您只需使用它Math.pi().使用单例类,你仍然需要做类似的事情

singleton firstSingleton = new singleton();
firstSingleton.set_name("foo");

singleton secondSingleton = new singleton();
Run Code Online (Sandbox Code Playgroud)

如果我错了,请纠正我,但firstSingleton == secondSingleton现在,是吗?

secondSingleston.set_name("bar");
firstSingleton.report_name(); // will output "bar" won't it?
Run Code Online (Sandbox Code Playgroud)

请注意,我独立询问这种语言,更多关于这个概念.所以我并不担心实际上如何编写这样一个类,但更多的是为什么你不愿意和你需要考虑什么.

Mic*_*rdt 52

单例对由静态组成的类的主要优点是,您以后可以轻松地确定您实际上需要多个实例,例如每个线程一个.

然而,在实践中,单身人士的主要目的是让人们对拥有全局变量感到不那么糟糕.

一个很好地使用单例的实际示例:您有一个使用SQL数据库的应用程序,您需要一个连接池.这种池的目的是重用数据库连接,因此您肯定希望所有客户端都使用相同的池.因此,将其作为单身是正确的设计.但有一天,您需要将应用程序连接到第二个数据库服务器,并意识到您无法连接到同一池中的不同服务器.因此,您的"一个整体"单例变为"每个数据库服务器一个实例".

  • "因此,将它作为一个单独的设计是正确的设计"我无法看到这在逻辑上是如何希望所有客户端使用相同的池.与单身人士相比,肯定有其他更好的方法来实现这一目标. (6认同)

bal*_*alu 13

为什么你不愿意

我不会因为单身人士通常是非常糟糕的方式来解决你的问题.我对你的建议是完全避免它们.

主要原因是:

  • 单身人士主要代表全球国家(这是邪恶的).
  • 正确的依赖注入变得不可能.

我建议您在此Google员工的博客中阅读其余内容(包括详尽解释):

  • 五年前,我实施了一项政策:"永远不要使用单身人士.如果你确定需要一个人说服你的领导!".在五年内遭遇两次挑战.最终结果总是相同的:非单身人士解决方案更好. (4认同)