Re: Singleton Pattern

Responding to TheinvisibleGhost wrote:

I've just started working on a very large project
that uses the singleton pattern to create just about everything.
Argghh!
Why did someone ever allow this pattern to come into existence.
It just seems an incredibly posh way of using global data!

There is nothing wrong with the Singleton pattern. The problem lies in the abuses of it, such as sneaking in global data. There are very specific conditions when using Singleton is appropriate:

(1) There is only one instance of the underlying entity in the problem space and the problem solution must ensure that uniqueness AND

(2) There are multiple contexts where the entity can be instantiated within the problem solution AND/OR

(3) The instantiation context can be invoked iteratively during the execution.

IOW, one should /only/ use Singleton when the problem solution has multiple paths that could lead to violating the problem space referential integrity requirement in (1).

The most common abuse of (1) is trying to sneak in global data because it will make the solution "easier". In that case one is not abstracting the problem space in an OO fashion.

The second and third conditions are violated when Singletons are created just because there happens to be only one instance. For example, if one creates an instance only at startup in main(), there is no need for Singleton because the startup code only gets executed once so there is no possible way for the instantiation code to be invoked multiple times to create multiple instances. [One can often avoid multiple creations in (3) by simply having a boolean attribute in the object that owns the creation context. So, as a practical matter, one usually only needs Singleton when (2) applies.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: when to use component-based design vs. stayign with traditional OOP
    ... object abstracts some identifiable entity in some problem space. ... So it seems to me that saying that having both classes and objects is a problem for the OO paradigm is much like saying having namespaces and data is a problem in a 3GL. ... So I also don't see why the Singleton pattern is a problem. ... The class system distinguishes groups of objects with sets and enables relationships to ensure collaborations take place between the proper participants. ...
    (comp.object)
  • Re: Global variables
    ... > (generally from external file), that need to be shared in the application. ... I think using Singleton may be a different issue. ... the behavior doing the creating may be invoked multiple times. ... sending emails before I speculate on where to glue the SMTP server ...
    (comp.object)
  • Re: Utility classes?
    ... I don't want to duplicate code in multiple places. ... > (singleton) classes created to encapsulate related operations in one class. ...
    (comp.lang.cpp)
  • Re: Thread-safe Collection
    ... but after that it would only be supporting multiple readers. ... I wanted the dictionary items in a common memory store (to avoid ... If you pin a singleton somewhere, ... If you want to have fast parallel reads from multiple STAs, ...
    (microsoft.public.vb.com)
  • Re: when to use component-based design vs. stayign with traditional OOP
    ... One of the most annoying aspect in OOA/D methods is the ... object abstracts some identifiable entity in some problem space. ... fundamentally in the OO paradigm. ... Singleton Pattern to try to abstract a not-OO domain space with an OO ...
    (comp.object)