Singleton vs. Monostate

The singleton pattern structurally enforces the fact that you can never have more than one instance of a class at a time, and it is obvious to the developers that they are dealing with a singleton.  Here is a sample Singleton implementation:


 


using System;


namespace TestLibrary


{


      public class Singleton


      {


            private Singleton()


            { }


 


            private static Singleton theInstance = new Singleton();


 


            public static Singleton instance()


            {


                  return theInstance;


            }


      }


}


 


But what about the monostate pattern?  The monostate enforces the behavior of a singleton without the structure of the monostate.  This is a sample implementation of a monostate:


 


using System;


namespace TestLibrary


{


      public class Monostate


      {


            private static int _x;


 


            public Monostate()


            { }


 


            public static int x


            {


                  get{ return _x; }


                  set{ _x = value; }


            }


      }


}


 


Here you can instantiate many Monostate objects, but the x property is the same across all objects.  What are the benefits of the monostate pattern over the singleton pattern?

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

14 Responses to Singleton vs. Monostate

  1. Robert Dexter says:

    You might find situations where you still need instance data. Therefore a monostate would be better. You can create the instance, use methods to affect instance data and still have access to the static data. With a singleton, you cannot have instance data.

    I also tend to think that a singleton is one way of making a set of global functions, sort of doing the C code thing, but with C++. When converting C code to C++, people tend to do this, and not redesign.

  2. Darrell says:

    Thomas – good point, though I have not had to TDD a Monostate yet. Mock objects are an important simplifying mechanism in TDD.

  3. Thomas Eyde says:

    Monostate is also usually preferred if you code in a test-first fasion. That is because you sometimes want to insert a mock object into the object under test so you can test its behaviour.

    That’s harder to do with a singelton because you don’t have a constructor to insert the mock with.

  4. Darrell says:

    Thanks Ken. That was an excellent comment!

  5. Darrell Norton's Blog says:

    Why choose monostate over singleton?

  6. Ken says:

    If you plan on deriving classes from the singleton and you want those classes to be singletons, your better choice is monostate. That’s because all classes derived from a monostate are monostates. Classes derived singleton classes are not singletons by default. You would have to add the static method and attribute to each derived class.

  7. Darrell says:

    Steve Maine – Personally I would prefer a Singleton over a Monostate for the exact same reasons you mention. But when Robert Martin described the Monostate pattern in as much depth as the Singleton, I wondered what the use of it was. Probably the only time I would use it is if I had to refactor a regular class into a Singleton but didn’t want to fix all those broken instantiations.

  8. Steve Maine says:

    Interesting post. I agree w/ James — I’m not sure if there is a real semantic difference.

    I like the fact that singletons can’t be instantiated via normal mechanisms. As you said, developers always know when they’re dealing with a singleton — because the compiler tells them. The monostate pattern gives a different semantic to object instantiation but retains the same syntax. With singletons, the difference in construction syntax reminds me of the difference in behavior.

  9. Darrell says:

    Very interesting!

  10. Steve Metsker says:

    Good question, and… there’s some interesting discussion of (what I take to be) your point, at http://c2.com/cgi/wiki?JavaSingleton.

    I personally would tend to view your Monostate class as an *implementation* of the Singleton pattern. The structure of code that fulfills the intent of a pattern is not critical — what makes code an example or implementation of a pattern is that it fulfills the intent.

    – Steve Metsker

  11. James Avery says:

    Well, I don’t know if there is an advantage… perhaps more of a difference. The singleton is about limiting an object to a single instance of that object, whereas the monostate is about creating a single state that all of the instances use.

    I think they both have there uses.

    -James

  12. Darrell says:

    Yeah, the MSDN sample definitely looks better. Mine was a port from Java, so not as good!

    But still, what is the advantage to the Monostate pattern?

  13. Darrell says:

    Ok, I fixed the code. I must have copied it incorrectly. Thanks!

  14. James Avery says:

    Your private member variable also needs to be static in the singleton example. Also, when you need this to work in a multi-threaded environment check out this cool MSDN example:

    http://msdn.microsoft.com/practices/type/Patterns/Enterprise/ImpSingletonInCsharp/

    -James

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>