为什么Singleton被认为是反模式?

可能重复:
单身人士有什么不好?

单身devise模式:陷阱

单身反模式

我最近听说辛格尔顿是一个反模式。 我知道这与一个事实有关,使得一个类的单例就像把这个独特的实例变成一个全局variables,但是它也做了很多事情(限制这个对象的实例的数量,pipe理实例化等等)。

为什么Singleton认为是反模式? 还有什么select?

为了帮助回答,下面是关于反模式的评论:

它被过度使用,在没有实际需要类的唯一实例的情况下引入不必要的限制,并将全局状态引入到应用程序中

来自: http : //en.wikipedia.org/wiki/Singleton_pattern

欲了解更多,你可以看看: https : //www.michaelsafyan.com/tech/design/patterns/singleton

这是上面博客的一个很好的结局:

简而言之,单例模式使得代码更加复杂,不太有用,而且是重用或testing的真正痛苦。 消除单身可能会很棘手,但这是一个值得的努力。

好的,所以这段文字描述的是反模式的原因,正如作者所expression的那样,它将你的代码紧密地耦合到单例。

如果你发现你想使用一个单身人士,你可能要考虑你的devise,但有时候它是有用的。

例如,一旦我必须编写一个最多只能有一个数据库连接的应用程序,就可以处理数千个请求。 所以,单身人士是有道理的,因为我的资源被限制为只有一个实例。

但是,通常这被用来简化代码,而不用考虑将要引入的困难。

例如,这也适用于静态类,如果你是unit testing,或有并发性,那么一个请求的状态将改变状态,这可能会导致问题,因为调用实例的类可能会假设状态是这样的预期。

我认为挑战这个用法的最好方法是想想如果你的程序是multithreading的如何处理它,一个简单的方法是unit testing,如果你有多个testing一次运行的话。

如果你发现你仍然需要它,那就使用它,但是要意识到稍后会遇到的问题。

我不会完全认为单身人士是一个反模式。

不过,单例基本上是使用全局variables的一种方法。 全局variables是不好的,因为系统中的任何代码都可以改变它们的值。 所以在debugging的时候,很难弄清楚哪个代码path导致了单例的当前状态。

我认为它被认为是一种反模式,因为Singleton类不能以其他对象以正常方式实例化(除了通过调用通常称为“getInstance”的方法)。 所以,它看起来像是直接使用这个类,而没有实例化它来首先创build一个可用的对象。

我同意你的观点,辛格尔顿可以作为一个全球独特的例子。 我从一些人那里了解到,作为Singleton的替代品,我们可以使用静态variables和/或最终variables,也可以使用枚举(这样我们可以将多个variables分组在一个组名下,正如我们通常在使用正常的类/对象)。

但是,这些替代方法只能匹配Singleton类在存储状态/值时的function。 如果我们需要使用独特的函数,这些静态/最终variables和枚举不能帮助。 在我看来,当我们需要使用一个Singleton类(当我们需要一些独特的函数来处理静态/最终状态/值)时就是这种情况。

干杯… :))

单身人士往往执行不力。 请参阅双重检查locking。

在哪个范围内,一个Singleton实例是唯一的。 像multithreading环境,集群等

单身人士可能很难testing。

分配给单例的内存不能被释放。

由于单身人士的过度使用,您将从面向对象的编程转向程序编程。