Quote:Original post by Promit
Here it is. A first round of Promit's Principles of Software Engineering. I may expand on this list in future posts, but this will get us started nicely.
1) There are no legitimate uses of the singleton design pattern.
I disagree. I believe that in most situations you may have encountered that the implementation of a singleton on a class has been a bad design. I do not feel that the pattern in itself has no legitimate use. I'm only talking about the unique instance of the pattern and not the other properties. I'd like to draw a comparison, give reasoning and finally provide an example.
First, I believe the pattern can be applied on objects as a modifier, much like the constant modifier. The implementation should not force the object to have all classes always have one instance but rather it should modify the class. For this program, my design says that having more then one instance of the class would be erroneous so let me mark it as having only one instance. Anything more would result in an error. It is a protection scheme much like statically typed languages. For another program, it would be acceptable for this class to have multiple instances so I would not mark it as a single instance.
In an ideal language it would look like this
class MyClass; // <-- declared
MyClass = single // <-- in an implementation file somewhere else
In C++ I've created a similiar construct that isn't as ideal.
CGlobal<MyClass> inst2; // second instance is the same as the first
Notice, that in another program I could decide to use a second instance by not using CGlobal and another class. This allows me to decide on a per project basis or even per library basis of whether it makes sense to mark the class as having one instance. The point I'm getting at is that in certain domains having more than one instance is erroneous and any constructs we can use to enforce the design will be a step in the correct direction and lead to less buggy code.
By allowing a choice of having multiple instances or single instance the design pattern creeps between the line of a singleton and multiton. Which gives it a more flexibility then it was originally designed.
It makes sense that any class that encapsulates physical interaction with devices on a system that you will want to have one copy of that class. Imagine that this class will be managing interactions with physical devices that only allow control of a volitle variable through one thread. Anymore attempts to access that variable will cause a system failure. Also, imagine that this certain instance of this class needs to be seen by one module.
* This module needs only one instance of the class any more will result in a hardware failure.
* The class needs global view from every other file in that module.
* Protect the hardware by enforcing a singleton design on the class. It can manage state of the device and prevent any attempts to misuse it.
* Perhaps, on another console you can have multiple access to the device so do not enforce that the class always has to be a singleton. This should be a modifier for that particular class in that module.