Re: singleton vs static

From: Daniel Parker (danielaparker_at_spam?nothanks.windupbird.com)
Date: 05/24/04 

Date: Sun, 23 May 2004 22:45:13 -0400

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:1vcva0ps0m9focabi1tvmdiqe6ng9r12mm@4ax.com...
>
> www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf
>
> Advantages of Singleton:
>
> * Derivatives of non-singletons can be singletons

> * Lazy evaluation. If you don't use it, it doesn't get created.

Depends on the implementation. It may be advantageous in C++ and Java to
force instantiation at initialization to deal with threading issues without
locking getInstance.

> * Obvious semantics. Everybody knows the class is a Singleton.
>
> Disadvantages of Singleton
> * There is no universal way to destroy the singleton.

It usually doesn't matter. In C++, if you need the destructor of the
instance to be called when the application terminates, you can use a smart
pointer for the static instance. If the singleton contains state that needs
to be saved, there likely needs to be logic at shut down for that anyway.

> * Derivatives of Singletons are not necessarily Singletons

I have never seen anyone derive from a Singleton. Surely they should be
declared final, where the language supports that.

> * Dangling references are possible.

Are you referring to threading issues with getInstance? Or just that the
static instance has outlived its usefulness?

> * Intrusive Semantics, changing from singleton to
> non-singleton could break a lot of code.

It can be straight forward, getInstance() replaced by getInstance(type),
say. But generally, changing from one instance to many instances is a
significant change in application design.

I'm surprized you don't discuss threading issues. It still seems to come as
a surprize to many C++ and Java programmers that the standard Singleton
implementations, e.g. those in your article, the Patterns book, and in Scott
Meyers' books, are not thread safe. There are still programmers who know
about the double locked checking pattern but do not know that it does not
work in C++ and Java. (It's interesting that it can be made to work in C#.)
>
> Advantages of static class (Monostate)

Can't comment, I've never used them and I've never seen them used outside of
your articles (first in the C++ Journal.) Keep in mind that Java developers
are going to find your use of the term "static class" confusing!

Regards,
Daniel Parker

Relevant Pages

  • Re: Are Singletons Worth Using?
    ... I am a Java expert. ... >> The Singleton pattern is not about instanciation, ... > 1/ the client class has to know that it is using a singleton because ... The Singleton pattern, as defined in the GoF book, inherently has this ...
    (comp.object)
  • Re: Java Singleton Constraint?
    ... it would seem that Java would not ... >allow a class to be derived from a Singleton. ... >that you must never have a need to extend the Singleton class? ... "The aim of science is not to open the door to infinite wisdom, ...
    (comp.object)
  • Re: Java Singleton Constraint?
    ... I have a Singleton question that is specific to Java ... However, since this is a design pattern question, I ...
    (comp.object)
  • Java Singleton Constraint?
    ... I have a Singleton question that is specific to Java ... However, since this is a design pattern question, I ... that you must never have a need to extend the Singleton class? ...
    (comp.object)
  • Re: forms timers, events, and threading
    ... more about whether or not to use threading at all. ... > Singleton, either the MainForm or my ApplicationContext singleton) have a ... > code the Timer events so they were not reentrant (by checking a Static ...
    (microsoft.public.dotnet.languages.vb)