Re: Design Patterns
Peter Duniho wrote:
_Needed_ is situation-specific, but examples generally will include
situations where multiple callers require access to some shared resource
abstracted by the singleton class. In some cases, a static class suffices.
Nitpick: "static class" is the wrong term. I figure you mean a "utility class",
or class with only static members.
But in other cases it's either useful or required to have a singleton (e.g.
because you need the singleton to implement an interface, something static
classes in Java can't do).
Static classes certainly can implement interfaces. It's non-instantiable
classes that can't, and classes containing only static methods.
But even in absence of _need_, there is the class of examples where one
needs an implementation of an interface that can be shared by multiple
callers. One approach is to keep creating new instances of the implementor
every time a caller needs it, but this has obvious efficiency issues. In
Sometimes has efficiency issues. The "obvious" ones often aren't actually
issues at all.
To "keep creating instances" is actually a situation for which Java is
optimized.
some cases, those issues can actually be a problem, in which case it's nice
to implement a singleton.
Isn't "issue" a synonym for "problem"?
Each caller can "solve" the efficiency problem by caching their own copy of
Yes, "solve" in quotes, because quite often something labeled a "cache"
simply isn't. Also, there's that aforementioned optimization for short-lived
instances.
the class, but it's generally better to do the work once in the singleton
class rather than making each caller duplicate the effort. Good API design
And this is the heart - not whether the instance hangs around but whether the
work needs to be repeated. It's the latter that helps decide on whether to keep
an instance (singleton or otherwise) lingering.
means the client of the API has a minimum of work to accomplish needed
functionality, without a bunch of extra busy work.
Another class of examples involve classes where it's useful to have a
"default" instance. Again, callers could use a default constructor and
create a new instance every time they needed the default one. But it's
convenient to have a singleton instance representing that default.
Strictly speaking, that's not a singleton unless it's the only possible
instance.
Frankly, I'm amazed any experienced programmer would argue against the
pattern solely on the basis of perceived lack of "need". Almost everything
in a high-level language and framework is there not because of need, but
rather convenience and simplicity (which often in turn leads to code that
is easier to get correct, always a nice feature of one's code). Everything
you can do in Java, you can do in assembly language. You don't _need_ Java
at all.
And yet, we use it.
Now that is a salient point indeed.
--
Lew
It's an incursion of logic into the center of the line of defense posed by
irrationality.