David Ferenczi wrote:
>> An interesting read. Thank you.
> 
> I'll try to summerise the article:
> 
> 1. Singleton is evil.
> 2. Everyone, who uses singleton, is a beginner (or nerd?) and doesn't
> understand the OO paradigm.
> 3. There are many problems with singletons, see section "Get to the Point,
> Already".
> 4. If you want to use singleton, use a static class or a factory instead.
> 
> IMO the problems with singleton implementations are valid, but he forgets to
> mention that exactly the same applies for static classes. Static classes
> are just more effective (you save a function call) and syntactically nicer
> (in the class itself, and also wehne calling). But is there really more?
> Are singletons really so evil, that worth bashing? And can the factory
> pattern be applied everywhere, where you need a singleton (static
> availability, only one instance)? I'm not sure.
> 
> Do I miss something?

I agree that Singleton is overused.  But I think it's overused in the same way that stubbed out copy constructors are overused.  Everyone knows they should provide a reasonable copy constructor for their classes, but y'know getting the darn thing working at all is often a much higher priority than than figuring out the details of safely copying a complicated object.  So rather that not doing anything and letting the compiler merrily supply a bogus copy constructor that will appear to work at first, you stub it out so anyone who tries knows that you haven't done the work yet.

I think many times Singletons are used in the same vein.  "Yeh, I know some day there could be more than one Renderer instance, but there isn't now and I'm not really ready to deal with it".  So you put all the renderer bits in a Singleton, and make everyone who wants to use it call getInstance().  Steve says that makes for a horrible refactoring experience when suddenly you do need more than one instance, but to me it seems much better than if you had started out with globals.  You can convert the getInstance() method into a static factory method that takes some kind of parameter to select the instance desired, and you're good to go.  For example you can change it so that getInstance("directX") give you the directX renderer, and maybe leave getInstance() as returning the 'default' renderer so old code still works.  Seems all in all much easier refactor to me than if you than if you had started out with a bunch o globals.

--bb

David Ferenczi wrote:
>> Final point: just make sure you actually need singleton.  I've seen a
>> lot of people using singleton for a single class, which would be more
>> efficiently handled by a static class.
>
> Can you mention some godd and bad examples?
>

In my option:

Good examples:

The singleton needs to be created/destroyed
You need to:
- create some sort of resource
- file handle
- deal with something that is not available until a certain time in execution.
- To save memory by not always having the skeleton available and use the RAII to make the singleton only available when necessary.


Bad example:

- You have something thats always available during the entire project and no initialization/destruction is necessary.  For instance, it would be a bad idea to create a maths library with things like cos and sin in it (unless you wanted to generate some sort of fancy lookup table at run-time which requires initialization).

- Performance critical code.  For things that are included in your most inner loops, you don't want the overhead of an extra pointer lookup. (note that inline'ing can sometimes cure this problem if used in the local project)

Why?
Singletons add code bloat both in the interface and in use.  It means more reading, more typing, more debugging and slower compiles.  Also it means that things become harder to refactor because they are closely coupled to a class.


Rant:
Personally I think some people use OOP to much.

I'm no expert however this is where I'm currently at with my coding ethic:

1) Use free functions when they make sense.  Free functions are easy to move around.  If it's in the class its one more attribute you have to maintain when that class is inherited from or move around.  Also free functions can be more generalized.

2) Use inheritance for polymorph only.  Avoid using inheritance for code reuse. This way the class becomes more manageable.

3) Use components class for code reuse.  If the component changes it has less effect on the interface of the owner class.

4) Use small classes that have one function as they are much more re-useable and debugable. However, I concede that it can be much faster to write a big class then lots of scaffolding small classes, particularly in the short term.

5) Don't write getter/setter methods if the class simply exposes everything anyway, use a struct instead.  Getter/Setters should be used for classes that do more then just provide access properties, its just unnecessary code bloat that is time consuming to maintain.

6) If programming in C++ don't write extremely complex templates.  They slow slow down compilation and confuse everyone else.  Do use templates for generalization just don't go overboard and beware of code bloat issues.  If programming in D, go nuts with templates.

7) Use constant lookup tables/arrays (or datadriven tables) instead of switch statements and if statements, where possible.  These are easier to maintain.  For instance it makes it easier to register/remove new types. It also helps keep all the information together that is meant to be together.

8) Scaffolding = time.  Scaffolding takes time to write, compile and maintain.  Try to minimize scaffolding and keep most of the code actually doing something useful, without sacrificing readability.

9) Perfect is the enemy of good.  Don't over design.  Get the fundamentals and then add as needed.  Particularly if your writing code that is application code or internal to a library (with public libraries you don't know what your users will need).

janderson wrote:
> David Ferenczi wrote:
>  >> Final point: just make sure you actually need singleton.  I've seen a
>  >> lot of people using singleton for a single class, which would be more
>  >> efficiently handled by a static class.
>  >
>  > Can you mention some godd and bad examples?
>  >
>
> 9) Perfect is the enemy of good.  Don't over design.  Get the fundamentals and then add as needed.
> Particularly if your writing code that is application code or internal to a library (with public libraries
> you don't know what your users will need).

That should be:
... Particularly if your writing code that is application code or internal to a library. This approach of course doesn't not work for public library interfaces where the more flexibility provided the better.

Now I only wish I could always follow my own advice ;)

-Joel

Thank you very much!

BLS wrote
> found the Singleton pattern interesting

http://www.digitalmars.com/d/archives/21642.html

-manfred