Re: Singletons

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/18/05 

Date: Tue, 18 Jan 2005 04:25:55 GMT

Responding to Cerra...

>> That is very true. They should only be used when two conditions both
>> prevail:
>>
>> (1) The must never be more than one instance of the object.
>>
>> (2) There are multiple opportunities to create an instance during
>> execution because
>>
>> (2a) An instance can be created in different contexts (i.e., by
>> different objects) and/or
>>
>> (2b) The instantiating behavior can be invoked multiple times.
>>
>> However, when those conditions prevail Singleton is usually the best
>> (safest and most readily understood) mechanism.
>
>
> Do objects that manage the creation of other objects usually make good
> Singletons? Like Abstract Factories implementations, Object
> Pools/Managers, and the like?

Usually not. That's because concrete factories are usually instantiated
once during application initialization. There is usually no need for
more than one and it will be more efficient to allocate it once at
startup than to allocate/deallocate it on an as-needed basis.

OTOH, I can envision situations where it might be desirable to create
factories on an as-needed basis and get rid of them afterwards. In that
case one might have a need for making them Singletons for efficiency
sake because the as-needed invocation may be unpredictable or repeated.

>
> In fact, I think this lets the singleton be more flexible and less
> risky. That is, if you think a class should be a singleton, make the
> constructor protected and allow it to be managed by a seperate singleton
> object manager. If you change your mind, you only have to change the
> manager's code, or even just write another manager. E.G.

Hmmm. OK, I think I may have answered a different question above than
you asked. B-)

If you just mean that if one is already using a factory to create
instances, then let the factory control the number rather than a static
method in the class being instantiated, then I agree. That is
necessarily more flexible because the factory has more control over the
instance being created (i.e., in Singleton there is only one possible
flavor of instance to create initially)

However, I would counter by wondering how much need there is for that
flexibility. The only situation I can think of where that would be
useful is when one needs one sort of single instance (read: attribute
initialization) for awhile during some context but when that context is
replaced one needs a different sort of single instance for awhile. IOW,
one wants to be able to delete the current flavor and recreate a new flavor.

But one can do that if one adds a static delete method to Singleton.
The odds are somebody else needs to understand when the context switch
and whoever that is can invoke the delete() method of the singleton.
Taking that one step further, whoever that is also likely to understand
what new flavor of single instance is needed for the new context. So
they would be a single point of instantiation and one wouldn't need a
Singleton at all. B-)

>
> Say you origionally think Window objects hould be singletons. So write
> this instead of the classic pattern. (note: there are better Singleton
> implementations... I chose this one for brevity):
>
> ] package Motif;
> ] public class Window {
> ] protected Window() {...}
> ] }
>
> ] package Motif;
> ] import Motif.Window;
> ] public class WindowManager {
> ] private static WindowManager wm = new WindowManager();
> ] private static Window ww = new Window();
> ] protected WindowManager() {...}
> ] public static getInstance() {return wm;}
> ] public getWindow() {return ww;}
> ] }

OK. But unless I'm missing something this is just a Singleton
(WindowManager) combined with a composition relationship

                                  1
[WindowManager] <*>--------------- [Window]

The Whole/Part composition with unconditional 1:1 multiplicity already
ensures there can't be more than one Window created for each
WindowManager, so if WindowManager is a Singleton there is only one
point of instantiation and Window does not need to be a Singleton.

>
> If you change your mind, then either change WindowManager or (better)
> create a new manager:
>
> ] package Motif;
> ] import Motif.Window;
> ] public class WindowManager2 {
> ] private static WindowManager2 wm = new WindowManager2();
> ] protected WindowManager2() {...}
> ] public static getInstance() {return wm;}
> ] public getWindow() {return new Window();}
> ] }
>

OK, but WindowManager2 is a different class than WindowManager. I'm not
sure I see how this is different than having any two different classes
that are singletons.

> It also allows Window objects to be easily extended (singletons are
> traditionally hard to extend or subclass).

I don't think subclassing should be a problem; only a leaf subclass is
instantiated, so any one or all of the leaf subclasses can be a
Singleton. That is, subclassing, inheritance, and polymorphism are all
orthogonal to the number of instances of the leaf subclasses.

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

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

Relevant Pages

  • Re: Has anyone ever implemented a Decorator pattern in VB?
    ... > public method that returns an instance that implements the expected ... Class factories generalise this idea by having a single object whose sole responsibility it is to create other objects. ... that you don't have to keep track of each singleton class, but let the class factory do this for you allowing you to simply ask the ...
    (microsoft.public.vb.general.discussion)
  • Is a static method sufficient to call it factory?
    ... Talking about factories why someone propose the way ... why the singleton? ...
    (comp.lang.java.programmer)