Software Mechanics
Why do we even have that lever?

Resolving a Singleton? Here's how...

January 23, 2009 18:01 by chris

A user posted a question on the Unity Codeplex forum a couple of days ago. He wanted to configure Unity through the configuration file to resolve a singleton object. My first thought was "of course, that's easy". Then I read the actual question and it got a bit more interesting. I thought I'd put my response here instead of the forum because I thought it was an interesting discussion, and I'd like it to still be around the next time it came up.

The thing was, the object in question was an actual singleton, along these lines:

public class MySingleton : IMySingleton { 
    private MySingleton() { }
    public static MySingleton Instance { 
        get { return instance; } 
    } 
    private static MySingleton instance = new MySingleton(); 
} 

He wanted to configure Unity to, essentially, return the Instance property of this singleton class during resolution. That's not so easy.

So, how do you fit something like this into the container? You could write an extension or custom config node to special case it, but that's just asking for trouble. Plus, it encourages use of singletons, which are pretty well understood to be Not A Good Thing these days.

Unfortunately, many times the singleton behavior is forced upon you by libraries or frameworks. Or you may have lots of other code that isn't using a container that you want to leave unchanged. So what do you do?

Luckily in this case, the singleton has an interface on it. So what I'd do is start by creating a new class that has a public constructor, implements the singleton interface, and defers all the methods to the underlying singleton.

public class MySingletonWrapper : IMySingleton {
    public void MyMethod() {
        return MySingleton.Instance.MyMethod(); 
    }
}

Something along those lines.

Next, I'd configure the container to inject the wrapper when asked to resolve IMySingleton. The nice thing about this is that you get simple integration with the code you currently have, and your new classes which you build up through the container are ignorant of both the singleton class and the wrapper; they just use the interface.

You could stop there. That's the nice thing about proper refactoring: at each step you could stop and still leave your system in a working state. But why? Why not get rid of the singleton and let the container manage the object instances? This is pretty easy through more refactorings.

The first thing to do is change the type of the Instance property on the singleton to return the interface type rather than the concrete type. This should be pretty transparent to the callers, and your compiler will tell you if any edits are required.

The next step is to move the guts of the interface implementation out of the MySingletonClass and into the MySingletonWrapper class. Then change the instance the singleton manages to an instance of MySingletonWrapper instead. Finally, change the methods on the interface to delegate to the wrapper instance instead.

public class MySingletonWrapper : IMySingleton
{
    public void MyMethod() {
        DoStuffHere();
    }
}

public class MySingleton : IMySingleton
{
    public IMySingleton Instance {
        get { return instance; }
    }

    private static IMySingleton instance = new MySingletonWrapper();

    // interface implementation now delegates to instance
    public void MyMethod() {
        instance.MyMethod();
    }
}

At this point, all your code should still be running, through the container or not. You should definately change the name of MySingletonWrapper to something a lot more descriptive at this point. That'll be very easy since the only places that use this class name are your container configuration and the MySingleton class.

From here, the next thing I'd probably do is remove the interface implementation from the MySingleton class. This class now has only one responsibility: managing the lifetime of that inner instance.

Now, as you go forward, you should be able to remove references to the explicit singleton and replace them with objects injected from the container. Over time, you should be able to remove all the reference to MySingleton without affecting your code's behavior at all. When the last reference is gone, you delete the singleton class.

And that's how I'd resolve a singleton.


Currently rated 1.6 by 28 people

  • Currently 1.571429/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:
Categories: .NET | Agile | Unity
Actions: E-mail | Permalink | Comments (3) | Comment RSSRSS comment feed

Comments

Comments are closed