Re: Singleton
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 10/29/03
- Next message: Hoff, Todd: "Re: Singleton"
- Previous message: Shane Mingins: "Re: Implementing Presentation Logic"
- In reply to: Shane Mingins: "Re: Singleton"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 29 Oct 2003 22:52:52 GMT
Responding to Mingins...
> Buzzzzzzzzzz .... that's the sound of the buzzer saying wrong answer. Did my
> post really sound like a homework question? Maybe the introductory question
> did. But the main part (and unanswered by yourself I will add *grin*) of my
> question was more to do with alternatives to the Singleton pattern. Appart
> from cases where the Singleton was clearly the wrong pattern as mentioned in
> Kent Beck's example there is a general feeling that the Singleton pattern
> should be avoided ... and I was trying to get some answers as to what other
> alternatives might one consider when all the reading I have done so far does
> not give any clear winner or examples of cases where ..."yes the Singleton
> is the winner."
To answer your question... (Hopefully pretty much the way I answered the
last time this came up.)
I don't see it that Singleton should be avoided. It is more a matter of
it being over-used. Too often people clutter up the application with
Singleton when it isn't necessary.
There are essentially two necessary conditions for using Singleton: (1)
it is important that only one instance the class be active at a time and
(2) there are multiple contexts where it can instantiated. (2) can be
further qualified as: (2a) the code doing the instantiation is invoked
multiple times and/or (2b) the instantiation can be done by different
objects.
If (1) and (2) are true, then Singleton is a useful pattern because it
isolates the rule about a single instance and determining if one already
exists in a single place. That frees the clients that need an instance
from worrying about the details.
The problem is that (2) is rather unusual in practice. More precisely,
(2b) is rather unusual because it is in the nature of OO development to
encapsulate responsibilities like instantiation in one place. While
(2a) is fairly common, one can often deal with that situation by simply
providing a private attribute (e.g., isInstantiated) in the object that
does the instantiating.
So the alternatives to Singleton are:
(A) do the instantiation in one place that is not invoked multiple
times. Typically this would be a Factory that is invoked at startup or
only after the instance from a previous Factory invocation was deleted.
(B) if the same code that instantiates is invoked multiple times, use a
private attribute as a flag for whether it has been done or not. (If
the instantiator has a conditional relationship to the instance, one can
simply check the instantiation of the relationship.)
(C) provide a semaphore attribute somewhere to indicated whether
instantiation is needed. This is simpler than Singleton when multiple
contexts can instantiate the instance. However, I am not enamored of
this unless such a flag already has a meaningful semantic in the problem
space to justify it being a public knowledge responsibility. That's
because it forces each context to understand the instantiation rules,
which may not have anything to do with context.
Having said all that, I see global access as an orthogonal issue. All
objects within a subsystem or layer are effectively global. That's
because there will always be a relationship path between any two classes
that can be navigated.
[Occasionally the Class Diagram will be a disconnected graph, but that
is pretty unusual in practice. Also, during OOP dependency management
will make the graph directional. However, that is addressing a
developer problem for physical coupling so the problem has already been
solved by the time one gets there.]
I also see navigation as an orthogonal issue. To collaborate with the
instance a relationship must have been instantiated to allow addressing
of messages. Instantiating the relationship is a different activity
that instantiating instances. One can construct pathological cases but
in practice whoever instantiates the relationship will either create the
instance (via Singleton or some other means) or will already have an
instance reference in hand. (The second situation is quite common in
languages like Java whose primary paradigm for instantiating
relationships is to pass a reference as an argument.)
So I think worrying about a "global point of reference" is not so much
about having a global reference as concentrating the rules and policies
of instantiation in one place.
*************
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.pathfindersol.com
(888)-OOA-PATH
- Next message: Hoff, Todd: "Re: Singleton"
- Previous message: Shane Mingins: "Re: Implementing Presentation Logic"
- In reply to: Shane Mingins: "Re: Singleton"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
