Ya, you are right :) This was from memory and I forgot about the empty
static constructor. Thanks for pointing this out!
Sébastien
On 7/24/06, gregory young <[EMAIL PROTECTED]> wrote:
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(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
