Singleton pattern in D

[janderson]

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).