• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Singleton Abuse

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
After reading some conversations here and other places, I suspect might be a Singleton abuser, but I'm not sure.

Does anybody have any links to or advice on examples and explanations of typical Singleton misuses?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are you limiting a class to have exactly N instances without a strict requirement for such a restriction?
 
Al Korov
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No. At least I don't think I am.

I tend to create a Singleton where I think it's appropriate for only a single entity be responsible for some behavior, or set of behaviors. For example, in my past few projects, access to a database connection was controlled by a Singleton. (The database connections were pooled.)

I'm curious about where others have used Singeltons, where such use was later decided to be inappropriate.
 
Ranch Hand
Posts: 862
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you use a singleton I would at least provide a method to get access to the object, so if later you decide you can't use a singleton (say due to the singleton having state that varies by consumer) the change won't affect client code.

It seems people use singletons in 2 ways:

1) There should really only be one instance. For example in a model of our solar system you would have one Sun, or in computer hardware you could only have 1 program listening on a socket.

Even this second example is debatable whether this needs to be a singleton, and in my opinion that is typical of Singletons. A singleton should be considered an implmentation detail and no one should write code assuming the implementation will always be a singleton.

2) For stateless or thread save objects, developers sometimes use one instance to save on unnecessary creation of Objects. Again if you do this hide it.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A singleton pool manager sounds fine to me. If I accidentally wound up with two or three instances and doubled or tripled the number of db connections I would get a nasty call from the DBA.

A static utility class is another option, but runs into lots of extensibility and flexibility issues.
reply
    Bookmark Topic Watch Topic
  • New Topic