In the previous articles I’ve outlined some alternatives to the standard practice of using a Singleton as the ModelLocator in Cairngorm. I’ve tried all three of the alternatives I outlined in a real project so here’s a summary of my opinions about them and the standard singleton.

Singleton

Pros:

  • Well known design pattern (other developers understand it with little explanation).
  • Singleton is enforced by blocking the constructor (there are various ways to do this).

Cons:

  • Difficult to mock for testing.
  • Changing code to allow more than one instance is not trivial.
  • Class can’t easily be extended.

Singleton factory

Pros:

  • Separates singleton behaviour from the model class
  • Model class can be extended in the normal way.
  • Multiple instances can be created and used with no alterations to the code.

Cons:

  • There is no protection to enforce the singleton – we rely on developers to remember to use the SingletonFactory.

Hiding the singleton

Pros:

  • Behaviour added by simply extending a predefined class.
  • Model class can be extended in the normal way.
  • Multiple instances share the same data so instance creation is standard, using new.

Cons:

  • The data is copied between instances, so multiple instances means multiple copies of the data which means increased memory use.
  • Because multiple instances all share the same data, there is no option for multiple sets of data.

The monostate

Pros:

  • Behaviour added by simply extending a predefined class.
  • Model class can be extended in the normal way.
  • Multiple instances share the same data so instance creation is standard, using new.
  • Can have instance data as well as shared data.
  • Data can be switched from shared to instance specific simply by changing the getter/setter for the property.

Cons:

  • Model class definitions are more complex (requiring the use of getter/setter pairs for every piece of data).

Conclusion

I’m sure there’s more pros and cons to be outlined – please add them in the comments below.

My own conclusion is that the monostate is the best solution, but it is hampered by the non-trivial implementation for the model classes due to the need for getter/setter pairs for each property (although some would say this is a good thing). It’s worth noting, however, that the resulting code is no more complex than the code generated by the compiler from the bindings in the other techniques – it’s just that we have to write this code ourselves. An automated tool to convert properties to appropriate getter/setter pairs when compiling would make this technique far and away my favourite (ant task, anyone).

If you don’t want to have to write getters and setters for each piece of data in the model then any of the other techniques are worth considering. My own favourite would be the Singleton Factory. As long as your developers remember to use it, everything works very neatly.

An apology

Finally, an apology for the rambling nature of this set of posts. When I started I only intended to write one post, then as I worked with the problem another post emerged, etc. Had I planned it in advance the posts would have be structured better.