This has been a great discussion. One minor opinion, I like to separate the two patterns more on dealing with static data. I tend to expect that static only classes are stateless. Dealing with the annoyance of the static constructor is just too weird for me. If it has state, I tend to just make a singleton (or a non-static class).
But thanks to everyone who contributed their opinions...I appreciate it! Thanks, Shawn Wildermuth Wildermuth Consulting Services, LLC http://adoguy.com C# MVP, MCSD.NET, Author and Speaker > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of > Luke Dalessandro > Sent: Friday, July 21, 2006 5:21 PM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Singleton vs. Static Classes > > >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. > > I see this as an interface issue, rather than a singleton > issue. As an example: > > class Singleton > { > /// singleton stuff here > /// ... > /// ... > > public static void Foo() > { > return Instance.doFoo(); > } > > protected void doFoo() {} > } > > There's no reason for the client to call Singleton.Instance, > it might even be protected. I've just provided a static > interface that forwards to the protected instance interface. > The client has no idea they're not using a static class. > > >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. > > Absolutely true, although lazy evaluation techniques can > alleviate your startup times. When I talk about .net I'm > generally thinking in C# terms (and mostly in ASP.NET terms, > because that is what I do). I worry more about resource leaks > than memory leaks. Threading issues apply to both static > classes and static singleton instances similarly. Your point > about changing signatures and core frameworks is absolutely > true as well, though I was thinking about private static > data, not public static data. > > =================================== > This list is hosted by DevelopMentorR http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
