It depends on how you define you static construction ...
If you use Sebastien's method listed
private static readonly Singleton _instance = new Singleton();
You will not receive the behavior that you expect (it will not be lazy
loaded and will loaded when the assembly is loaded). To get around
this you simply need to declare it either as ..
static singleton() {
_instance = new singleton();
}
or leave it as in the first example but include an empty static
constructor (I know that sounds silly but ...)
Jon Skeet had a good article about this a while ago ..
http://www.yoda.arachsys.com/csharp/beforefieldinit.html
Cheers,
Greg
On 7/24/06, Robert Rolls <[EMAIL PROTECTED]> wrote:
I use the singleton pattern XyZ.Instance in the following instance - I have a
configuration section that contains a list of types that I need to create.
Within the private constructor I iterate through the config calling
Activator.CreateInstance caching them within a hashtable, accessible via an
indexer or IEnumerable public property. Is this a reasonable use of
Xyz.Instance or should this too be a static.
One thing about static that is a little fuzzy is beforeFieldInit and static
classes/properties/methods etc. Which I think incur a performance penalty?
Rob.
-----Original Message-----
From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf
Of Sébastien Lorion
Sent: Saturday, 22 July 2006 6:36 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Singleton vs. Static Classes
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(r) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
--
If knowledge can create problems, it is not through ignorance that we
can solve them.
Isaac Asimov
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
