I wanted to write something about the concept of a "configuration class", which Emanuele touched on in a discussion about the singleton pattern.  Let me start by explaining what I mean by a configuration class.  It's a relatively common "pattern", although you'll never find it in any books.  I'm going to argue that this is because, like Singleton, it's the wrong solution to the problem. The Problem .NET has an incredibly flexible XML-based configuration API.  However, for the purposes of this discussion, we can concentrate on the bit that most developers use: AppSettings.  This is basically just a string hashtable with delusions...

Another thing that we covered at my recent presentation was common use cases of Singletons.  The problem with artificial examples is that you're often presented with objections that the point you're making is restricted to the particular example you've given.  So, instead, let's take a look at some of the most common usages of singleton patterns and explain why you're breaking your code to use them: The Current User I've lost count of the number of times I've seen the current logged-in user accessed through a static method.  It's extremely tempting: there's a phenomenal number of parts of your system...

Sun has always felt a need to educate its developers.  Sometimes this has led to Pearl Harbour scale disasters like J2EE, but it has also produced an extremely technically literate community.  On the other hand, sometimes you wish Microsoft didn't even try.  I've pretty much come to the conclusion, for instance, that the Microsoft Enterprise Library is the Wrong Thing.  Every so often, we come across stuff which falls under the heading of "mistakes you need a PhD to make", as Francis Fukuyama describes his advocacy of the invasion of Iraq.  The provider pattern is top of my list...

I recently had a rather incoherent rant about why Singleton is an anti-pattern.  Let's say that you decided that static methods needed to be eliminated from your code base.  So you embark on the refactoring to end all refactorings.  That's exactly the situation I'm in at the moment.  The irony is that the static methods I'm trying to eliminate are calls to StructureMap's ObjectFactory.GetInstance.  Yes, riddled through the code are calls to services.  Nothing is denied to any object.  If you start trying to replace static methods with proper instances, you're going to be asking yourself a lot: Why...

These is basically patterns where you're better off avoiding them.  Seriously, just skip those parts of the book: Singleton All patterns are a trade-off.  The trade-off with singleton is reducing the number of parameters certain functions take and trading them for more static methods.  From the perspective of code agility, a every method on singleton might as well be a static method.  Not only that, but everything the singleton touches might as well be a static method.  The testing implications of the Singleton pattern are horrendous.  Steve Yegge has written far more than I intend to on the subject, so I'm...