Quote:Original post by jonathanjansson

Quote:If you are an OO purist, globals and singletons both violate various pure OO principles.

I don't think they violate OO principles.

Well, they do. For more info, google Law of Demeter, Open/Closed Principle, and (arguably) the Acyclic Dependencies Principle.

Quote:
Or there is no need for another of the same object, and the code is easier to use. Or singletons could be used to contain boiler plate code that the developers would have to run every time they want to do something.

No, those are wants, and poor ones. The singleton pattern, as expressed by the GoF book (which is the de facto standard for definition of many design patterns) expresses the singleton as SimonForsman did. Your additions are just fluffy attempts at justification, and are non-canonical.

On a few different occasions, I have tried to completely avoid using singletons. I kept ending up with more code, and a design that didn't work well. Sometimes an object is used in so many places, it just makes sense to have global access. I will say that trying to avoid singletons can lead to better code, but you have to give in sometimes.

My company uses singletons extensively. They have a very serious bug uncovered by me in regarding to the use of singletons. The cause of the problem is that they use singleton in their libraries(which are compiled into dlls) and every instance of their classes accesses/shares the same singletons though they are supposed to be unique instances, not sharing any resources or information. For example, you set a information in one instance, all other instances got the same information because they access the singleton. Another example is all the instances ask the singleton(same resource) to do some work, all the tasks are enqueued, all the tasks are waiting to be executed by the same singleton and the application is perceived by user to be unresponsive. The tasks of each instance can be executed in parallel if it has a normal class member, instead of accessing a singleton.

They overlooked this bug because they usually tested one instance, not multiple instances, during their testing. It is too much work to convert/redesign the library code not to use singletons.

Singleton are just disguised global variable IMO. Rule of thumb is not to use singletons in your library while it is alright to use singletons in your application.

Quote:Sometimes an object is used in so many places, it just makes sense to have global access.

Can you give an example?

In any case, as has been mentioned, if you need global access to an object, just make the object globally accessible (there's no need to make it a singleton).

I generally don't mind singletons, *if* they're used solely to control instantiation and are passed into objects using standard dependency injection type techniques.

Unfortunately, they're usually used as a "OO-compliant" version of globals.

I think there's some basic conceptual stuff to understand design patterns well, and singleton is one of the patterns that appears useful (for the wrong reason) to folks that haven't made that conceptual jump yet.