0

"Singleton" is widely considered anti-pattern ("bad" in everyday language).

What about this alternative modified singleton pattern?

An object constructor for our class ensures that at any given point of time there is at most one instance of the object (yes, this uses a global boolean variable). If the user attempts to create an object of our class while another object of the class is created (and not yet destructed), the constructor throws an exception.

This way we can ensure that two objects (possibly holding a global external state) cannot interfere with each other and disturb each other to operate as planned.

This facilitates such things as testing, as the object can be created in a test case.

So, should such modified singleton pattern be accepted? can it be it a pattern? or yet anti-pattern?

|improve this question
  • The simplest approach is to just use a lazy-loading factory, which will always return the same instance. Your singleton problem is solved without a static property. But wait, how do you make sure the factory creating the instance only exists once in your application lifecycle? Perhaps another factory for the factory? That does not seem right either. IoC containers (Castle Windsor, Spring, Guice, Ray.DI,...) completely solve your issue while making the construction of object graph incredibly easy. You configure certain classes as singletons and you are done. – Andy Jun 26 '16 at 18:42
  • This sounds like a very bizarre wait-free locking strategy to me. What do you, as a consumer of this API, do when the constructor throws? Do you catch the exception and busy-wait until the constructor succeeds? That's grossly inefficient, but I can't think of an obvious alternative if you don't have some kind of explicit locking mechanism... which defeats the point of ensuring there's only one instance since you still have a lock to keep track of. – Kevin Jun 26 '16 at 19:27
  • 3
    @porton: I consider Jon's article a definitive work on Singletons. It might be worth your time to read it, since your question appears to be discussing some of the problems that Jon's article addresses (like the concurrency problem you described). I'm not especially concerned that it doesn't discuss your proposed implementation, nor am I particularly bothered that he chose to make the material concrete by providing examples in a programming language you don't like. – Robert Harvey♦ Jun 26 '16 at 23:23
  • 1
    Some of the points that make the use Singletons an anti-pattern still hold for your idea (and other not-quite-singletons): Like any other kind of global state, they can create hidden dependencies between seemingly unrelated parts of your code. They can constitute a hidden line of communication in your application. If you ever decide that the class doesn't need to be singleton any more, you'll have trouble finding all places that rely on this property. – Hulk Jun 27 '16 at 5:11
  • 5
    Unless I badly misunderstand you, what you're describing would still be a singleton, albeit one that dangles the false promise of the ability to create more instances with a public constructor that will throw an exception. So all the regular criticisms of singletons would still apply, plus you've got a constructor that violates the Principle of Least Astonishment. – Kevin Krumwiede Jun 27 '16 at 5:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.