It actually finds me amusing (er... ahem... well, I hope you understood me :)), that most of the time when people criticize Singleton, they criticize not the pattern (which describes any object that has 2 properties - global access point, single instance), but some common implementation of it.

After that, when they're asked for reasoning, they say stuff like "You have problems with an order of initialization", "Late initialization can fragment memory and produce stalls", "It's not thread safe", "Why the fuck we keep writing Class::Instance()->Method(), it's long and obscure", etc. - while none of this relates to some implementations.

There are certainly drawbacks to the pattern itself, but they are not as overwhelming.

What are YOU talking about? Can you elaborate?

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> inst1;
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.

By design:
* 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.

Solution:
* 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.

-= Dave

I will write my remarks in two posts - one now, and one later. Feel free to react to this one before I post the next.

Quote:Original post by David Neubelt

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> inst1;
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.

I don't think so. See below.

Quote: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.

By design:
* 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.

Solution:
* 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.

-= Dave

Regarding the singleton pattern, I more and more think just like Promit - and be sure that each time I see a possible use for this pattern, I try to see if that can be a good idea. And (every time, so far), I give up because of the typicall problems of singletons. That's depressing, even if I don't like this pattern. My goal is then to find at least one reason to like it - one reason that would prove that the GoF featuring of this pattern was a right choice. Up to now, I must confess that I think that because of this pattern, the GoF book really hurted a whole generation of software designer.

First question: what does that mean, having only one instance of a class?

I don't even consider the classical argument that says that "you may need more than one instance in the future". That's YAGNI. But really, answer the question: what does it mean?

To me, it means that the possibility to create a class has been abused. I have two way to use it: locally or globally. Creating a class so that it's used locally (in a single function) only once in a whole system can be proven to be absurd, unless the goal is to simplify the code and the overall design of the application. But I think that one should try to refactor the code in a better way to avoid this situation. The other option is to use that single instance globally. And that leads us directly to my second question.

Second question: why should this single instance be global?

the only reason I see is that you need to access this instance from everywhere in the code - that's typically a good sign of a common design flow - a locality problem. I don't know anything which have to be global and used by all the services of an application. Or, to be more exact, I know only one thing: system resources. And global system resources are best used using functions, because the system is supposed to know about their state internally. If these functions need some id (representing an instance of something) to work, then this is not a global resource, since providing two different id will have a different result. So this cannot be represented by a singleton, as the id might change. If there is no intrinsic data to store, then why using an object? A function is going to do the job just as correctly.

And there is another thing about that: just like all global variable, the singleton shall be stateless or shall not be.

C++ is a bastard language in this respect. The most common system resources are implemented using global variables (not even singletons): cin, cout, cerr and clog. But this is just cosmetic code.

From a design point of view, the singleton really makes no sense, because stating that one particular class should be global but should not be created more than once makes no sense.

Quote:Original post by Emmanuel Deloget
Second question: why should this single instance be global?

the only reason I see is that you need to access this instance from everywhere in the code - that's typically a good sign of a common design flow - a locality problem. I don't know anything which have to be global and used by all the services of an application. Or, to be more exact, I know only one thing: system resources. And global system resources are best used using functions, because the system is supposed to know about their state internally. If these functions need some id (representing an instance of something) to work, then this is not a global resource, since providing two different id will have a different result. So this cannot be represented by a singleton, as the id might change. If there is no intrinsic data to store, then why using an object? A function is going to do the job just as correctly.

I'd like to quickly address your second question.

Quote:Second question: why should this single instance be global?

I am not going to argue that allowing a variable to be global across an application is bad design. I also believe it is bad design. I'm arguing that you can have global variables that are exposed to one module and only one module. In this sense, it is local to that module but global across all files in that module.

There are two points we can argue here a) the effectiveness of a global variable and b) the single instance of an object. I'm sure we can both agree the advantage of a global variable in a library. Let's focus on the single instance of an object.

Problem domain for single instances of objects

If you are writing a module that needs to handle a system resource then I disagree on your view that a function call will always be the best idea. Imagine that the system resource gives you ownership of volatile variables. Having multiple access to these variables can cause system crashes and to protect your design you limit the entry point to those variables. This type of hardware implies the code has to control the state of the hardware. In this type of system there can only be one variable that controls the hardware and you must model your design with this restriction to protect against system crashes.

You say that all systems should know their state internally by function calls but this just simply isn't true. I'm currently working on hardware that forces you to create a variable for the OS to use (they have it externed) and then make changes to that variable! There isn't always a fancy OS to hide all the details for you and for certain consoles there is a close one-to-one mapping of hardware state and variable state.

I suggest for this domain of problems:

* Wrap the volatile state of the OS in a class.
* Only allow a single instance (single entry point).
* Allow every file in the library access to that class.

-= Dave