First, I don't see how to do inline replies in gmail, so sorry about that.
Humm, let me try to convey my meaning very explicitly: if your class
has *only* static methods, then it should be a static class.
Otherwise, it should probably be a singleton for all the previous
mentionned reasons. I would not like to see XyzUtility.Instance or
Algorithms.Instance or Math.Instance pop everywhere in my code, this
looks just wrong to me.
You say it is insanely easy to do a singleton in .NET, yet I need to
correct that constantly in code reviews I do. Many people don't know
that "static readonly _instance" is both lazy and thread-safe, no need
for locking here.
Maybe it is just me, but keeping state in a static class has bitten me
too many times (cold startup time, possible memory leaks, remoting
issues, threading issues, etc.). You do not always have the luxury of
changing the public signature of your components ... especially if you
are designing a core application framework that will be used in many
large projects.
About sealing the singleton class, let me give you an example:
If you derive from HttpContext, how do provide access to your new
singleton? You either need to shadow the "Current" property or provide
another one (yurk). Then, can you still consider it a singleton? You
got two instances of the same concept, possibly conflicting with each
other. That is why I think it should be sealed. If it is okay to have
different implementations of the same concept, then a factory would be
a good choice:
class TransactionHandlerFactory
{
static ITransactionHandler GetTransactionHandler(Type type)
{
// return the singleton for the provided type
}
}
Sébastien
On 7/21/06, Luke Dalessandro <[EMAIL PROTECTED]> wrote:
>I completely agree with you. All the reasons you named are valid ones.
>But notice you did not mention "can mock out" as a reason.
In a way I did. "Mocking out" and "mock object" are Extreme Programming
terms for what others call a "service stub." In object oriented languages,
these patterns typically rely on the ability for objects to behave
polymorphically, which a static class cannot do. This is achieved through
the use of an abstract singleton base class.
>Where do you draw the line between trivial/non-trivial?
The $64,000 question.
>Why not use a singleton everywhere and be consistent?
You could, there's no reason not to. A simple singleton is insanely easy to
code in .NET.
>Utility classes should be static but as soon as you need to keep some
>sort of state, then a singleton should be preferred I think, for all
>the reason you gave and more (eg can implement interface).
I actually don't see state as a criteria for deciding between a singleton
and a static class. Static member variables are essentially identical to a
static member's intance variables.
I really think that it's a matter of needing to make use of language
features that require object oriented principles (like the previously
mentioned polymorphism, or encapsulation, inheritence, etc. ), or complete
control of an object's lifecycle. The "mocking out" practice is a perfect
example of this.
If you don't need any object oriented features, or control over object
lifecycle, skip the singleton pattern, and go with a static class.
>You should also make the singleton class sealed, otherwise I think a
>factory is a better choice.
I'm not sure what you mean here... my understanding of the factory pattern
is that it is independent from a singleton. Many times a factory is
implemented as a singleton, but that doesn't mean it has to be.
In my view, the issue as to weather or not to seal a singleton class is
totally singleton specific. I actually feel like, if you have a situation
where you are trying to seal a singleton, that's actually a case where a
static class might work just as well.
My feeling is that a singleton is not always the BEST choice, but never the
wrong choice, while a static class might be the best choice, but could also
be the wrong choice.
Just to contradict this, my strategy is generally to start with a static
class, and then convert to a singleton later if I start needing object
oriented stuff. This is because I'm lazy, and the conversion is rarely painful.
Hope this helps,
Luke
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
--
Sébastien Lorion
Software Architect / Architecte organique
[EMAIL PROTECTED]
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
