Singleton

From APIDesign

Among other things the Chapter 7 also introduces the NetBeans pattern for doing Component Injection. The claims there are not fully aligned with common know-how of developers that use Dependency Injection. The most surprising thing is that NetBeans APIs commonly contain singletons (and yet there are no problems or design issues and testability is supported). It is quite common to see static methods like:

public abstract class WindowSystem {
  public static WindowSystem getDefault() { /* some impl */ }
}

This is something a Dependency Injection fan would have never done. Recently Witold Szczerba shared a very interesting observation on our mailing list[1]:

Now I feel totally lost. Jaroslav Tulach and Miško Hevery are, for me,
one of the most prominent and experienced people in the software
engineering, however they proclaim totally contradictory theories
about the bases for building applications. Or they not? I am still
trying to figure it out. In Chapter 7: "Use modular architecture",
Jaroslav describes the concept of generic registry, which is #2 on a
list of  "Top 10 things which make your code hard to test"[2]... Do
we have two mutually exclusive yet both correct theories?

This page is my attempt to explain this paradox. It may not be complete yet, I am still on the hunt for the little differences in initial assumptions that produce such contrary suggestions. But one day we'll get them...

I started by reading the Miško's articles references by Witold. Let's thus use them as headers for now.

Singletons are Pathological Liars[3]

It is easy to agree that the sample given here shows really horrible style of programming. Nobody who wants to code in modular way can have uninitialized objects floating all over the system waiting for some proper call to initialize them:

Database.init();
OfflineQueue.init();
CreditCardProcessor.init();
CreditCard c =  new CreditCard(
  "1234 5678 9012 3456", 5, 2008
);
c.charge(100);

The fact that in order to charge a credit card one needs to initialize various subsystems needs to be made more visible otherwise proper use and maintenance of such system requires non-trivial amount of knowledge and goes directly against the principle of cluelessness.

Miško's philippic is targeted against singletons, however I feel the problem is rather in existence and usage of uninitialized objects. Yes, it is easier to let uninitialized singletons escape to foreign code, however this can be simulated with regular objects as well. As such I am going to slightly shift focus and complain about uninitialized objects, potentially finding ways to use singletons so they are properly initialized.

As an executive overview, let me say that there seem to be two approaches to prevent uninitialized objects:

• Dependency Injection's principle is to always create objects with all their necessary environment - e.g. it is not possible to create new instance of an object without providing all services it needs. This style almost eliminates singletons.
• initialized singletons on the other hand solve the uninitialized objects approach by making sure singleton are properly initialized as soon as their defining class is linked together.

Obviously both of these approaches exorcise the above nightmare requiring various init class to set up your application.

Where Have All the Singletons Gone[4]

• don't mix object construction and app logic
• rarely call new operation
• desktop apps have no "request factory", just "application factory"
• mention Tim's there is only one main window[5]

Root Cause of Singletons[6]

• private constructor - not the Nb case
• immutable singleton is OK. If immutable == not configurable, then everything is OK.
• add story about main window and why NetBeans have just one - again levels of co-existence
• global state is bad. why? It does not seem that bad in desktop applications...

Top 10 things which make your code hard to test[7]

• test is small instance of the app
• Lookup.getDefault() is seam.
• inherit vs. composition
• switch vs. polymorphism
• value objects vs. service objects

Conclusions

• note about levels of co-existence
• Convention over Configuration
• Testability
• compatibility with ten years old design
• bridge with modern technologies LookupAndSpring