Is Singleton Design Pattern a Code smell ?

Is Singleton Design Pattern a Code smell ?

Well, before we get into this debate, to set the stage correct, let’s discuss about Design Patterns and Code smells.  

Design Patterns

Design Patterns are reusable design solutions for commonly recurring problems. Let me explain with a simple example, to cut a tree maybe we can use an axe, we don’t need to invent a new weapon or tool to cut a tree, if I use an axe to cut my nails then it becomes an anti-pattern.

Every Design Pattern exists to solve a particular problem, so we must carefully understand the problem we are trying to solve and pick a particular design pattern to solve the problem in our hand, as one size will not fit all.  A wrong choice of design pattern will over-complicate our solution as opposed to making things easy.

Code Smells

Code Smells, my informal definition will be – badly written code that essentially solves a problem, but it isn’t easy to understand or maintain and/or may not be the correct approach to solve the problem in hand. Code smells can be better understood by looking at the picture below. Poorly written code may work today, but if it needs maintenance the effort required can be compared to that of the electrician as shown in the picture.

epa02217413 An Iraqi electrician checks the wires leading to a block of flats and all connected to a generator which runs when the national power grid is down, in Baghdad's Karrada district, 23 June 2010. A wave of protests has swept across of Iraq against frequent power cuts that partially last throughout the day, and which led to the resignation of Iraqi Minister of Electricity, Kareem Waheed who said that his ministry did not have sufficient funds and blamed the Oil Ministry for failing to provide power plants with the necessary fuel to function.  EPA/ALI ABBAS

epa02217413 An Iraqi electrician checks the wires leading to a block of flats and all connected to a generator which runs when the national power grid is down, in Baghdad’s Karrada district, 23 June 2010. A wave of protests has swept across of Iraq against frequent power cuts that partially last throughout the day, and which led to the resignation of Iraqi Minister of Electricity, Kareem Waheed who said that his ministry did not have sufficient funds and blamed the Oil Ministry for failing to provide power plants with the necessary fuel to function. EPA/ALI ABBAS

Now let’s get back to our debate

Singleton Design Pattern completely relies on static self-reference, in Clean Code context, static keyword is a bad word or considered as evil. There are some interesting devices that are around us all the time but we never notice them, consider the small Wifi Internet routers or modems that are installed in offices, these devices are hardly turned-off or rebooted. At homes, the refrigerators are hardly switched-off, as they run all the time, just like our heart. 

Now, assume as part of Wifi router/modem booting, it makes use of a singleton object in couple of places during the boot-up process and once booted assume the singleton object isn’t required anymore. In such a small embedded device, it is important to keep the memory and binary foot-print of software as small as possible, as the resources are limited and considered expensive.  Hence, use of static objects are considered costly as they are going to eat-up or hold the memory until the devices are turned off.  This is one of the bad effects of static variables from the optimization or performance point of view, on the other hand, from the testing point of view, use of static variables poses quite a lot of mess.

Assume you are planning to automate unit-test cases in your project, unit-test cases are supposed to be independent from one another, which means unit-test cases must be designed in a such a fashion, they can be executed in any sequence. Irrespective of the sequence in which the unit-test cases are executed, the results of those unit-test cases are supposed to the same. But in case one of the very first test case alters the static variables, then the residual effect might have an impact on further test cases, this may lead to false alarms or false pass. For these kind of reasons, use of static variables are considered as a code smell. The original Gang-of-four Singleton Design Pattern doesn’t talk about how and when to free-up the static self-reference object. 

Singleton Design Pattern heavily depends on static variables and static functions, hence we must use them with caution.

What is the takeaway message ?

For Swine Flu, we all know there are vaccinations like Influenza and Tamiflu, etc., Most vaccinations contain chemical toxins and in some cases, the vaccinations seems to have a weaker, modified form of the same virus for which we are vaccinated, hence we must take them only as a cure or prevention, just because they seem to prevent us from Swine Flu, obviously I shouldn’t take Swine Flu as a breakfast, just kidding 🙂

Use Singleton Design Pattern only if there are no other options, if there are better alternates avoid using Singleton Design Pattern or static variables and static functions.

If Singleton Design Pattern is the only solution for your problem, to work-around the memory leak issue, you can make use of WeakReference in Java and C# and std::weak_ptr in C++.

Hope you got the message.

Share Now

Jegan

More Posts By Jegan

Related Post

Leave us a reply