QUITERS NEVER WIN

0 Background

In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton.

Don’t know what it is talking about hah? Of course, I do not either.

Let start with case/code.

I was/still be a Starcraft player, and one big fan of ‘Ghost’ of Terran. Why? Ghost controls fantastic attack – nuclear weapon.

-‘Nuclear launch detected’

Yes, this is a alarm which means big trouble is coming because there is a Ghost aiming your army with nuclear weapon. But, of course, this is not a article to introduce anything about Starcraft. I just want to imagine to be the dope one, that I am just the super hero, using the device to aim the target with nuclear attack.

So there must be one program running on the device, and, of course, one device controls only one nuclear weapon due to the hardware limitation and requirement. Let’s start with the code,

1 Why Singleton?

This is a very obvious mistake I have made in the code above. Yes, the line highlighted is where the issue is caused. We have two Nuclear instances totally independent in NuclearMonitor and NuclearLauncher, which means the one in monitor is not been launched while the one in launcher as completed the launch scenario.

How to debug? Quite simple, just pass the Nuclear instance in launcher to monitor, everything will be fine, just like this without hesitation.

Yes, after updated by the code highlighted, get the nuclear instance out from the launcher and set it into monitor. Of course, the instance is allocated in the launcher and should be managed/release in the launcher, so the release part of nuclear instance in monitor has been removed.
After make&execute, we get what we expected, ‘Nuclear launch detected’,

So here comes the question, why singleton?
Sure, we can get/set instance through open new interface for classes to implement these kind of requirement, but design pattern never solves the problems of implementation.

From the design point of view, we need to reduce interconnection of every component, and ensure the architect extendable. Supposing we need NuclearPayloadCalculator to calculate the payload size, and then the launcher will need another interface to obtain payload size for nuclear initializing(No related code provided, but trail is not hard to implement). Also, to each object that uses Nuclear instance, how to alloca/dealloc/manage this instance has so much dependency from each other, which is expected to be solved by the architect design. In this kind of implementation, we have to get the object that own the nuclear instance even it is not designed to exist in the scope because we need it to pass the nuclear instance. In this case, which is the most important, I think, is nuclear instance could be allocated in any classes. If the memory requirement of payload is huge for the device, I think this is very dangerous to cause the OOM which should never happen because only one nuclear instance is expected to exist in the system.

Let’s summary the requirement,

Only one Nuclear instance exists in global scope at one time. Another Nuclear instance allocation should be forbidden if current one has not been released.

Instance management should be implemented within the Nuclear class itself.

Getter/setter interface could be implemented only in Nuclear class itself.

Extend-ability need to be ensured, which means dependency and update need to be minimum in the component using Nuclear instance when requirement updated/submitted.

2. Singleton Implemetation

Requirement has been listed above, so let’s start from the very beginning one by one.

1, One static private member of type Nuclear is needed in Nuclear class,

Of course, everything works fine~ We have not update any implementation.

3. Summary

Singleton pattern is one of the most simple design pattern, so it is one kind of design pattern. It would not help solve any issue of implementation

As talked before, code would be written only once but read millions, it helps make the code and logic more clear.

Singleton helps the extension, and trouble shooting. Unit test could be applied to ensure the singleton class is fine, and then any debug/new feature could be gotten rid of it unti the architecture is re-designed.

This case is the simplest singleton. Singleton pattern application could be extended more far, such as thread-safe ones.