In software engineering, Creational Design Patterns deal with object creation mechanisms, i.e. try to create objects in a manner suitable to the situation. The basic or ordinary form of object creation could result in design problems or added complexity to the design. In this article of the Creational Design Patterns, we’re going to take a look at the much-hated & commonly asked design pattern in a programming interview. That is Singleton Design Pattern in Modern C++ which criticizes for its extensibility & testability. I will also cover the Multiton Design Pattern which quite contrary to Singleton. By the way, If you haven’t check out my other articles on Creational Design Patterns, then here is the list: Factory Builder Prototype Singleton The code snippets you see throughout this series of articles are simplified not sophisticated. So you often see me not using keywords like override, final, public(while inheritance) just to make code compact & consumable(most of the time) in single standard screen size. I also prefer struct instead of class just to save line by not writing “public:” sometimes and also miss , constructor, , prefix std::, deleting dynamic memory, intentionally. I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible rather than the standard way or using Jargons. virtual destructor copy constructor Note: If you stumbled here directly, then I would suggest you go through first, even if it is trivial. I believe it will encourage you to explore more on this topic. What is design pattern? All of this code you encounter in this series of articles are compiled using C++20(though I have used features up to C++17 in most cases). So if you don’t have access to the latest compiler you can use which has preinstalled boost library as well. Modern C++ https://wandbox.org/ Intent To ensure one & only one instance of a class exist at any point in time. The Singleton Design Pattern ensures that a class has only one instance and provides a global point of access to that instance. This is useful when exactly one object need to coordinate actions across the system. So, essentially, the Singleton Design Pattern is nothing more than specifying a lifetime. Singleton Design Pattern C++ Example The motivation for using a Singleton Design Pattern is fairly obvious. Some components in our system only need to have a single instance. For example, a database that loads up from its constructor into memory & then gives out information about its contents. Once it’s loaded up you don’t really want more than one instance of it because there is no point. And you also want to prevent your clients/API-users from making any additional copies of that . Following is a trivial example of the Singleton Design Pattern in C++. object :: < :: , >  m_country;

    SingletonDatabase() { :: ; :: city, population; (getline(ifs, city)) {
            getline(ifs, population);
            m_country[city] = stoi(population);
        }
    } :
    SingletonDatabase(SingletonDatabase &) = ;
    SingletonDatabase & =(SingletonDatabase &) = ; { SingletonDatabase db; db;
    } get_population( :: &name) { m_country[name]; }
}; {
    SingletonDatabase::get().get_population( ); EXIT_SUCCESS;
} /* country.txt 
Japan
1000000
India
2000000
America
123500
*/ { class SingletonDatabase std map std string int32_t std ifstream ifs ( ) "country.txt" std string while public const delete operator const delete SingletonDatabase & static get () static return int32_t const std string return int main () "Japan" return Some of the things to note here from the design perspective are: Private constructor Deleted & copy constructor copy assignment operator Static object creation & static method to access The Problem of Testability With Singleton So we have our Singleton database and let’s suppose that we decide to use this database to do some research and we actually made a new class called a SingletonRecordFinder which is going to find the total population from the collection of city names provided in the argument as follow. { result = ; ( &country : countries)
            result += SingletonDatabase::get().get_population(country); result;
    }
}; { struct SingletonRecordFinder int32_t static total_population ( < >&   countries) const vector string int32_t 0 for auto return But let’s suppose that we decide that we want to test the SingletonRecordFinder and this is where all the problems show up. < > countries= { , }; TEST( + , SingletonRecordFinder::total_population(countries)); vector string "Japan" "India" // Strongly tied to data base entries 1000000 2000000 Unfortunately, because we are strongly tied to the real database and there is no way to substitute this database. I have to use the values taken from the actual file. And when later on these entries change, your test will start failing as you may have not updated the code. And this going to be a continuous problem. Moreover, this is not going to be a unit-test rather it is integration test as we are not only testing our code but also a production database which is not good design. Surely there is a better way of actually implementing this particular construct so that we can still use the singleton but if need we can supply an alternative to the singleton implementation with some dummy data of our own. Singleton Design Pattern With Dependency Injection The problem that we’re encountering in the testing of the SingletonRecordFinder is to do with the fact that we have a dependency upon essentially the details of how a database provides its data because we’re depending directly on the singleton database and the fact that it’s a singleton. So why don’t we use a little bit of on an interface or abstract class! dependency injection = ;
}; Database { < , >    m_countries;

    SingletonDatabase() { ; city, population; (getline(ifs, city)) {
            getline(ifs, population);
            m_countries[city] = stoi(population);
        }
    } :
    SingletonDatabase(SingletonDatabase &) = ;
    SingletonDatabase & =(SingletonDatabase &) = ; { SingletonDatabase db; db;
    } get_population( &country) { m_countries[country]; }
}; Database { < , >    m_countries; :
    DummyDatabase() : m_countries{{ , }, { , }, { , }} {} get_population( &country) { m_countries[country]; }
}; Database&       m_db; :
    ConfigurableRecordFinder(Database &db) : m_db{db} {} total_population( < > &countries) { result = ; ( &country : countries)
            result += m_db.get_population(country); result;
    }
}; {
    DummyDatabase db; ;
    rf.total_population({ , , }); EXIT_SUCCESS;
} { struct Database // Dependency int32_t virtual get_population ( & country) const string 0 : class SingletonDatabase map string int32_t ifstream ifs ( ) "countries.txt" string while public const delete operator const delete SingletonDatabase & static get () static return int32_t const string return : class DummyDatabase public map string int32_t public "alpha" 1 "beta" 2 "gamma" 3 int32_t const string return /* Testing class ------------------------------------------------------------ */ { class ConfigurableRecordFinder // Dependency Injection public int32_t const vector string int32_t 0 for auto return /* ------------------------------------------------------------------------- */ int main () ConfigurableRecordFinder rf (db) "Japan" "India" "America" return Due to Dependency Injection i.e. Database interface, our both following issues are resolved: We have done a proper unit test rather an integration test, Now our testing class is not directly tie-up to Singleton. So no need to change our unit-test over & over in accordance with a database change. Multiton Design Pattern Multiton is a variation to singleton but not directly linked to it. Remember that singleton prevents you to have additional instances while Multiton Design Pattern sets up kind of key-value pair along with the limitation for the number of instance creation. PRIMARY, SECONDARY, TERTIARY }; < T, Key = :: >
struct Multiton { <T> get( Key &key) { ( it = m_instances.find(key); it != m_instances.end()) { it->second; 
        } m_instances[key] = make_shared<T>();
    } : <Key, <T>>  m_instances;
}; < T, Key> <Key, <T>>     Multiton<T, Key>::m_instances; Printer() { << << ++InstCnt << ; } : InstCnt;
}; Printer::InstCnt = ; { mt = Multiton<Printer, Importance>; main = mt::get(Importance::PRIMARY); aux = mt::get(Importance::SECONDARY); aux2 = mt::get(Importance::SECONDARY); EXIT_SUCCESS;
} enum { class Importance template typename typename std string static shared_ptr const if const auto // C++17 return return private static map shared_ptr template typename typename map shared_ptr // Just initialization of static data member { struct Printer cout "Total instances so far = " endl private static int int 0 int main () using auto auto auto // Will not create additional instances return So as you can see we have three printers i.e. primary, secondary & tertiary whose access & instantiation is controlled by Multiton. Rest of the code is self-explanatory I hope. Benefits of Singleton Design Pattern The Singleton Design Pattern is quite helpful for application configurations as configurations may need to be accessible globally, and future expansions to the application configurations can be consolidated at single place. A second common use of this class is in updating old code to work in a new architecture. Since developers may have used globals liberally, moving them into a single class and making it a singleton, can be an intermediary step to bring the program inline to the stronger object-oriented structure. Singleton Design Pattern also enhance the maintainability as it provides a single point of access to a particular instance. Summary by FAQs What is so bad about the Singleton Design Pattern? Singleton object holds the state for the lifetime of the application. Which is bad for testing since you can end up with a situation where tests need to be ordered which is a big no-no for unit tests. Why? Because each unit test should be independent of the other. Singleton object causes code to be tightly coupled. This makes guessing the expected result under test scenarios rather difficult as we have seen above in database example. But you can overcome it by using Dependency Injection along with Singleton Design Pattern. Imagine the situation where you have a concurrent application accessing Singleton object from every part of your application, It just mashes up things or slows it down if you use a mutex or any other synchronization primitives. What is the correct way to implement Singleton Design Pattern? The right way to implement Singleton is by dependency injection, So instead of directly depending on a singleton, you might want to consider it depending on an abstraction(e.g. an interface). I would also encourage you to use synchronization primitives(like a mutex, semaphores, etc) to control access. When should you use the Singleton Design Pattern? Usually, Singleton is used in hardware interface usage limitation. For example, Printers are limited in numbers, so in such case, a singleton or multiton design pattern is used to manage access. Singleton Design Pattern is also widely employed in managing configuration or properties file to manage access. We can use the cache as a singleton object as it can have a global point of reference and for all future calls to the cache object, the client application will use the in-memory . object Previously published at http://www.vishalchovatiya.com/singleton-design-pattern-in-modern-cpp/

Design Patterns: Prototype Pattern in Modern C++

www.vishalchovatiya.com

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Design Patterns: Singleton Pattern in Modern C++

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

7 Advanced C++ Concepts You Should Know

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

7 Advanced C++ Concepts You Should Know

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps