The singleton pattern was detailed in the GoF "Design Patterns" book. Because of its static nature and public availability, it allows component writers to obscurely reference other components. Overuse makes for bad solutions. At the enterprise level, it makes for very very bad solutions.
We claim that the GoF Singleton pattern is in fact an antipattern. The downside of the singleton antipattern is that classes depending on it often end up depending on everything and the kitchen sink. Singletons cannot be replaced with Mock Objects for the sake of easy unit testing.
With PicoContainer we would replace this with a container managed single instance, possibly in a container hierarchy (see Five minute introduction and Caching).
Quite often with J2EE solutions, the component model is honored to a degree for the sake of external APIs, but is sidestepped for the sake of the internals of the application. Session beans Foo and Bar are likely to leverage a hairball of singletons to achieve their ends. Systems developed along these lines, rapidly become entangled and unmaintainable. These entangled systems can also be referred to as
- Raymen Noodle Design
- Big Ball of Mud http://www.laputan.org/pub/foote/mud.pdf
- Spaghetti Code
In case its not clear, Singletons as a core feature of a component design are mutually exclusive with Inversion of Control.