单例:应该如何使用它

编辑: 从另一个问题，我提供了一个答案，有很多关于单例的问题/答案的链接:

所以我读了单身人士的帖子:好的设计还是拐杖? 争论仍在激烈进行。

我认为单例是一种设计模式(有好有坏)。单例的问题不在于模式，而在于用户(对不起大家)。每个人和他们的父亲都认为他们可以正确地实施一个(从我所做的许多采访来看，大多数人都不能)。另外，因为每个人都认为他们可以实现正确的单例，所以他们滥用模式并在不合适的情况下使用它(用单例替换全局变量!)

所以需要回答的主要问题是:

什么时候应该使用单例如何正确地实现单例

我对本文的希望是，我们可以在一个地方(而不是谷歌和搜索多个站点)收集何时(以及如何)正确使用Singleton的权威来源。同样合适的是列出反用法和常见的坏实现，解释为什么它们不能工作，以及对于好的实现来说它们的缺点。

所以开始行动吧: 我会举起我的手，说这是我用的，但可能有问题。我喜欢“Scott Myers”在他的书《Effective c++》中对这个主题的处理。

使用单例的好情况(不多): 日志框架线程回收池

/*
 * C++ Singleton
 * Limitation: Single Threaded Design
 * See: http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
 *      For problems associated with locking in multi threaded applications
 *
 * Limitation:
 * If you use this Singleton (A) within a destructor of another Singleton (B)
 * This Singleton (A) must be fully constructed before the constructor of (B)
 * is called.
 */
class MySingleton
{
    private:
        // Private Constructor
        MySingleton();
        // Stop the compiler generating methods of copy the object
        MySingleton(MySingleton const& copy);            // Not Implemented
        MySingleton& operator=(MySingleton const& copy); // Not Implemented

    public:
        static MySingleton& getInstance()
        {
            // The only instance
            // Guaranteed to be lazy initialized
            // Guaranteed that it will be destroyed correctly
            static MySingleton instance;
            return instance;
        }
};

好的。让我们把一些批评和其他实现放在一起。 : -)

当前回答

正如其他人所注意到的，单例的主要缺点包括无法扩展它们，以及失去实例化多个实例的能力，例如用于测试目的。

单例对象的一些有用的方面:

延迟或预先实例化适用于需要设置和/或状态的对象

但是，您不必使用单例来获得这些好处。您可以编写一个普通的对象来完成这项工作，然后让人们通过工厂(一个单独的对象)访问它。如果需要，工厂可以只考虑实例化一个，并重用它等等。同样，如果你对一个接口而不是一个具体的类编程，工厂可以使用策略，也就是说，你可以切换到和退出接口的各种实现。

最后，工厂可以使用依赖注入技术，如Spring等。

2009-09-25 16:30:14

其他回答

关于模式有一点:不要一概而论。当他们有用的时候，当他们失败的时候，他们有所有的情况。

当您必须测试代码时，单例可能会令人讨厌。您通常只能使用类的一个实例，并且可以选择在构造函数中打开一扇门或使用一些方法来重置状态等等。

另一个问题是，Singleton实际上只不过是一个伪装的全局变量。当你的程序有太多的全局共享状态时，事情往往会倒退，我们都知道这一点。

这可能会使依赖追踪更加困难。当所有事情都依赖于你的单例时，就很难改变它，拆分为两个等等。你通常会被它困住。这也妨碍了灵活性。研究一些依赖注入框架来缓解这个问题。

2008-09-17 19:26:48

单例对象的问题不在于它们的实现。而是它们合并了两个不同的概念，这两个概念显然都不可取。

1)单例提供了对对象的全局访问机制。尽管在没有定义良好的初始化顺序的语言中，它们可能更线程安全或更可靠，但这种用法在道义上仍然相当于全局变量。它是一个用一些笨拙的语法修饰的全局变量(比如说，foo::get_instance()而不是g_foo)，但它具有完全相同的目的(在整个程序中可访问的单个对象)，并且具有完全相同的缺点。

2)单例防止一个类的多个实例化。据我所知，这种特性很少被添加到类中。这通常是一个更有语境的东西;很多被认为是独一无二的东西实际上只是碰巧是独一无二的。在我看来，更合适的解决方案是只创建一个实例——直到您意识到需要多个实例为止。

2008-09-17 19:27:56

大多数人在试图让自己对使用全局变量感觉良好时使用单例变量。有合法的使用，但大多数时候，当人们使用它们时，只能有一个实例的事实，与它是全局可访问的事实相比，只是一个微不足道的事实。

2009-04-17 19:09:19

Meyers单例模式在大多数情况下工作得足够好，在某些情况下，寻找更好的模式并不一定值得。只要构造函数永远不会抛出，并且单例对象之间没有依赖关系。

单例对象是全局可访问对象(从现在开始是GAO)的实现，尽管并非所有的GAO都是单例对象。

日志记录器本身不应该是单例的，但是理想情况下，记录日志的方法应该是全局可访问的，以便将日志消息的生成位置与日志记录的位置或方式分离。

延迟加载/延迟计算是一个不同的概念，单例通常也实现了这一点。它自身也有很多问题，尤其是线程安全问题，如果出现异常而失败，那么在当时看来是个好主意，结果却并不是那么好。(有点像字符串中的COW实现)。

考虑到这一点，goa可以像这样初始化:

namespace {

T1 * pt1 = NULL;
T2 * pt2 = NULL;
T3 * pt3 = NULL;
T4 * pt4 = NULL;

}

int main( int argc, char* argv[])
{
   T1 t1(args1);
   T2 t2(args2);
   T3 t3(args3);
   T4 t4(args4);

   pt1 = &t1;
   pt2 = &t2;
   pt3 = &t3;
   pt4 = &t4;

   dostuff();

}

T1& getT1()
{
   return *pt1;
}

T2& getT2()
{
   return *pt2;
}

T3& getT3()
{
  return *pt3;
}

T4& getT4()
{
  return *pt4;
}

它不需要那么粗糙地完成，显然，在包含对象的加载库中，您可能需要一些其他机制来管理它们的生命周期。(将它们放在加载库时获得的对象中)。

至于我什么时候使用单例对象?我用它们做了两件事 -一个单例表，指示哪些库已经被dlopen加载 -日志记录器可以订阅的消息处理程序，您可以向其发送消息。信号处理程序特别要求。

2011-03-02 13:09:27