{"id":6451,"date":"2022-09-25T14:42:54","date_gmt":"2022-09-25T14:42:54","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/singleton-pros-and-cons\/"},"modified":"2023-06-26T08:59:08","modified_gmt":"2023-06-26T08:59:08","slug":"singleton-pros-and-cons","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/singleton-pros-and-cons\/","title":{"rendered":"The Singleton: Pros and Cons"},"content":{"rendered":"

I introduced in my last post “The Singleton<\/a>“, the classical Singleton and the so-called Meyers Singleton. The Singleton Pattern is highly controversial. Let me, therefore, discuss in this post the pros and cons of the Singleton.<\/p>\n

<\/p>\n

\"CreationalPatterns\"<\/p>\n

 <\/p>\n

First of all, is Singleton a Pattern or an Anti-Pattern?<\/p>\n

Singleton: A Pattern or an Anti-Pattern?<\/h2>\n

My most read post so far is my post “Thread-safe Initialization of a Singleton<\/a>“.  It was read more than 300’000 times, and I got many comments.<\/p>\n

Consequentially, I asked the community if they use the Singleton pattern: https:\/\/twitter.com\/rainer_grimm\/status\/699717467770392576<\/a>. About 150 people voted on Twitter, and the answer was not as clear as I expected. 59% use the Singleton, but 41% do not.<\/p>\n

\"singletonPoll\"<\/p>\n

The comment I got about the Singleton Pattern can be summed up in two answers:<\/p>\n

    \n
  1. I don’t use the Singleton because it is an anti-pattern.<\/li>\n
  2. I only use the Singleton deliberately.<\/li>\n<\/ol>\n

    However, I think one faction has not spoken up in this discussion. That is the fraction of developers who use the Singleton Pattern frequently. I know this faction from my daily work. If I include this silent fraction in the survey result, I assume that about 80% of the developers use the Singleton Pattern.<\/p>\n

    Therefore, let’s dive deeper and analyze the pros and cons of the Singleton Pattern.<\/p>\n<\/p>\n

    The Advantages and Disadvantages of the Singleton Pattern<\/h2>\n

    I want to start positive:<\/p>\n

    Advantages<\/h3>\n

    Global Access Point<\/h4>\n

    A Singleton is a global object in disguise, but it provides a global access point. As a global, a Singleton can be accessed from anywhere in the program, but it cannot be modified from anywhere. It can only be modified from within the Singleton. It is, therefore, a means to protect globals.<\/p>\n

    Unique Entity Model<\/h4>\n

    It makes it easier to reason about your program when you model entities of reality. In reality, we often have Singletons such as registration offices, global timers, or factories for unique IDs. Consequentially, you achieve a very nice match between the program abstraction and the reality. This correspondence helps you and your client to better understand the program.<\/p>\n

    Disadvantages<\/h3>\n

    Static Initialization Order Fiasco<\/h4>\n

    In my last post, “The Singleton,” I already wrote about the static initialization order fiasco. It essentially means that you have no guarantee in which order statics in different translation units are initialized and destructed. The “Design Patterns: Elements of Reusable Object-Oriented Software”<\/a> based implementation of the Singleton Pattern has this issue, but the Meyers <\/a>Singleton overcomes it.<\/p>\n

    Concurrency<\/h4>\n

    The Meyers Singleton also overcomes the concurrency issue of the classical Singleton implementation. The Meyers Singleton is based on a local static. Since C++98, statics with local scope are lazily initialized, and with C++11, even thread-safe. <\/p>\n

    Too often used<\/h4>\n

    The Singleton Pattern was often used when it was inappropriate, and a simple class instance could do a better job. This was mainly due to the fact that software developers want to prove that they understood the classical design pattern, and the Singleton often seems to be the long-hanging fruit. Honestly, we can not blame the Singleton Pattern for its misuse. <\/p>\n

    Hidden Dependency<\/h4>\n

    You may assume it; this is my key point. A Singleton introduces a hidden dependency and breaks, therefore, testability. Let’s consider the following code snippet:<\/p>\n

    <\/p>\n

    \n
    void<\/span> func<\/span>() {\r\n   ...\r\n   DataBase::<\/span>getInstance().update(\"something\"<\/span>);\r\n   ...\r\n}\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    The call DataBase::getInstance().update(\"something\") <\/code>creates a hidden dependency. The caller of the function func<\/code> has no idea that a database is called internally. What are the consequences? The code is no unit anymore and, therefore, not unit-testable. You cannot test this code in isolation. You can only make a system test including the operational database. You always end with two tests. You test the code of the function func<\/code> and the database.<\/p>\n
    Unit Tests should<\/p>\n