Patterns

Why do so many people mess up Singletons?

Scott Galloway — Mon, 28 Jan 2008 00:47:55 GMT

I've written about this a few times now (use the search thingy to find where) but I'm still surprised how many people mess up the Singleton pattern.

For instance take:

if (blogSettingsSingleton == null)
                {
                    blogSettingsSingleton = new BlogSettings();
                }
                return blogSettingsSingleton;

Looks ok, right? But this is a classic poor pattern when dealing with multi-threaded apps. Why? Look at the initial 'if' statement, and think what happens if multiple treads hit this at the same time...one thread could be in the process of creating this object whilst the others are evaluating the condition...

If you're using Singletons PLEASE read this article. The singleton pattern article from Wikipedia has the following excellent implementation of a singleton:

/// <summary>
/// Class implements singleton pattern.
/// </summary>
public class Singleton
{
        // Private constructor to avoid other instantiation
        // This must be present otherwise the compiler provide 
        // a default public constructor
        private Singleton()
        {
        }
 
        /// <summary>
        /// Return an instance of <see cref="Singleton"/>
        /// </summary>
        public static Singleton Instance
        {
            get
            {
                /// An instance of Singleton wont be created until the very first 
                /// call to the sealed class. This a CLR optimization that ensure that
                /// we have properly lazy-loading singleton. 
                return SingletonCreator.CreatorInstance;
            }
        }
 
        /// <summary>
        /// Sealed class to avoid any heritage from this helper class
        /// </summary>
        private sealed class SingletonCreator
        {
          // Retrieve a single instance of a Singleton
          private static readonly Singleton _instance = new Singleton();
 
          /// <summary>
          /// Return an instance of the class <see cref="Singleton"/>
          /// </summary>
          public static Singleton CreatorInstance
          {
            get { return _instance; }
          }
        }
}

This is a lazy-initializing, thread safe singleton...does sacrifice *some* performance (see the earlier article for details of this) but it is FAR safer than the original I showed...

Oh, and one last thing...are you REALLY sure you need a Singleton? One horrible pattern I've seen is code is using Singletons to access database connections...this is VERY RARELY required and sacrifices a lot of the benefits which modern databases offer for concurrent access.

UPDATE: Umm...realized that I don't explain what a 'Singleton' is...essentially it's a pattern which limits the access of an object to a single caller at a time. Common uses for Singletons could be accessing files on a file-system where you really want to make sure that only one thread has access at one time. Oh, and to make things even more complicated you'd more commonly want to use a ReaderWriterLock in this scenario to allow many readers or a single writer...only of course you wouldn't...told you it was complicated! Oh, and to further complicate matters in VS2008 and above you'd probably want ReaderWriterLockSlim!

To struct or not to struct

Scott Galloway — Tue, 09 Oct 2007 18:15:47 GMT

I've been commenting on this post by Bernal Schooley on a method using structs to 'simplify' using ViewState. Bernal has had a couple of posts around ViewState and methods of making it's use simpler. I have to say the comments on the posts are more useful for me that the posts themselves (as is often the way...comments are still on the blog right ).
One problem I do have is advocating the use of structs for this stuff...now don't get me wrong, I am aware of some advantages around structs; which go away slightly when using Generics as the constant boxing/unboxing no longer happens...There does seem to be a lot of misunderstanding around structs though...they're not always faster!
Structs are stored on the stack rather than the heap, this makes accessing and using them faster (often dramatically faster!) . However you have to be aware of the limitations around structs...one biggie is that over 16 bytes you lost a lot of the advantage of this speedup - don't be storing a ton of data in a struct (well, not a ton...over 16 bytes!).
The other biggie is boxing structs...again in this case you've flipping them onto the heap rather than the stack...so you lose the 'stack' advantage again...
So, story is structs can be great but be careful with them...there's a newbie mistake in thinking that structs are these great, lightweight objects you can use however you want...they're not. Unless you can *really* justify using a struct, don't bother! In my entire .NET programming career I used structs maybe 5 times...and for very specific reasons!

Playing with .NET Remoting

Blog Author — Tue, 25 Jan 2005 20:02:00 GMT

Recently had the chance to dig into remoting in a bit more detail (for the Bulk Mail app I've mentioned before). I have to say, it's both more difficult and a lot easier than I imagined!
Having to modify my class to allow use from a remoting client was a little wierd; I wanted to use SingleCall mode - with a simple response to keep performance up, unfortunately this has led to quite a radical reworking of my main Engine class (and subsequent bug-fixing...it wasn't that tight in the first place). The actual set up of remoting is however amazingly easy, letting me simple switch from local to remoting versions with a simple bit of config...e.g.

<system.runtime.remoting>

</serverProviders>

</channels>

</client>

</application>

</system.runtime.remoting>

Oh, I did use a Facade pattern to help reduce the type and number of changes I had to make to my core engine (specifically to reduce the amount of thread-handling code in the core engine...

One oddity I did come across though was trying to use remoting from an ASP.NET site - which is what this app was doing, acting as a web-service proxy to another remoting server on the same box (simplifies things for non-.NET clients using the app...config etc...). No idea where I found it but this code in my Global.asax.cs helped a lot:

protected void Application_Start(Object sender, EventArgs e)

{

string configFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;

RemotingConfiguration.Configure(configFile);

}

All this really does is aid the app in identifying the correct config file to use (which is actually tirckier than you'd expect.).

The only other hassle I had was an annoying error related to a change introduced in .NET 1.1 to do with typeFilterLevel - this article sorts it all out...

Patterns and Practices...suck!

Blog Author — Tue, 20 Jul 2004 17:42:00 GMT

I think I've made it pretty clear in the past that I think that one of the weakest areas of the Microsoft 'developer experience' is the Patterns & Practices area, don't believe me? OK, try and find an article about the Singleton pattern on the site; hint, don't use the Search feature, it returns a link to the Caching Application block for 'Singleton' and nothing at all for 'Singleton Pattern'! When you do manage to find it (here), you may notice a few things:

1. It doesn't really explain where / why you'd want to use it, here's the 'Context'

'You are building an application in C#. You need a class that has only one instance, and you need to provide a global point of access to the instance. You want to be sure that your solution is efficient and that it takes advantage of the Microsoft .NET common language runtime features. You may also want to make sure that your solution is thread safe. '

Which is technically accurate, absolutely...ok, so why would you actually want to use it? Some examples may help here!

2. This really isn't the easiest or even the 'best' implementation - for my money, this is - has a lot of versions explaining the benefits / drawbacks of each one.

I've complained about this before, reason I'm doing it again? I was trying to find a decent implementation of a specific pattern, the Dispatcher View - eventually I went to the Sun Patterns site and translated from the J2EE version into C#...which is a pain in the ass! I can't find the post at the moment but I read some stuff on someone's blog that the focus had been on the 'professional' developer as opposed to the 'opportunist' on the P&P site...meaning those with formal comp-sci training versus those who chose to become developers after having qualified in a different subject.
Hmm...I don't know if the UK is unusual, but I'd say that of the many developers I've worked with, around 5% have actually been comp-sci graduates - and they haven't been easily identifiable by their skill level.
I find this really annoying, patterns should be the universal language of all developers, sure, the 'Enterprise Developer' will probably rely on patterns more (as the use of patterns can greatly simplify the creation and future understanding of complex enterprise systems) but I really believe that Microsoft have dropped the ball in not pushing patterns more to the general developer community. Sites like DoFactory do fill in part of the gap but I'm still puzzled by the Patterns agnosia on sites like MSDN, even the Architecture center barely mentions them...come on, it's like building a house out of raw materials like clay and wood rather than using things like bricks and doors.

Anyway, rant over...

Interesting site - with a focus on Patterns in .NET

Blog Author — Wed, 10 Mar 2004 21:17:00 GMT

Found this site really interesting from Maxim V. Karpov, basically it's a blog with a focus on the use of design patterns in .NET - which I personally think are currently not widely underused but could provide a huge boost to a whole lot of developers. Maxim recently wrote an article looking at the ASP.NET Out Of Process Session State - which is in itself an implementation of the Intercepting Filter pattern. If you're interested in patterns in .NET you could do a lot worse than look at the Microsoft Patterns site - whilst it isn't perfect (I'd personally like to see a WHOLE lot more example code) it is a great introduction.

More on Patterns

Blog Author — Sun, 14 Sep 2003 22:20:00 GMT

Found this on the Furrygoat site, this is a truly excellent site on the GoF design patterns (you'll see this alot, it refers to this book - the original book on design patterns). If you're creating applications in any language, I really recommend you get at least a passing knowledge of what patterns are and how they can be used.