A coworker of mine recently introduced me to the monostate pattern. At first I was like "wtf is that?". I had never heard of that pattern before. He is of the opinion that the monostate pattern is far better than the singleton pattern. I had no opinion on the subject because I only assumed singletons are the one and only way to ensure only one instance of an object is created throughout an application.
At first I gasped in excitement at the thought that there was something possibly, or arguably, better than using singletons. Like I said, I had no real opinion prior, so I spent today researching it. Low and behold, there's hardly any info or examples of implementations of this pattern out there. The only useful info I found was at this blog post. But, here is an example of what I gathered a monostate class to look like in ActionScript 3:
package { public class ApplicationConfiguration { protected static var _language:String = "en"; public function ApplicationConfiguration() { } public function get language():String { return _language; } public function set language( v:String ):void { _language = v; } } }
So in this case I have a class with a protected static var named _language in it. This variable, because its static, will only ever exist in one place, and thats in the class definition. No matter how many times I create a new ApplicationConfiguration instance, the value of that variable will persist throughout each instance, allowing every instance to have a "mono state". Why didn't I ever think of this before? It's so simple and clever. So here's an example use of this class:
var config1:ApplicationConfiguration = new ApplicationConfiguration(); trace( config1.language ); // Output: en config1.language = "fr"; var config2:ApplicationConfiguration = new ApplicationConfiguration(); trace( config2.language ); // Output: fr config2.language = "es"; trace( config1.language ); // Output: es
I've commented in the output of that code, and you can see, when I make a change to the language property in config2 the value of language in config1 also changes.
So now I'm wondering what the advantages and disadvantages to this approach over a singleton might be. One of the most obvious advantages I saw right away was the fact that I can easily extend a monostate class. Extending singletons is, well, impossible as far as I know. Other than that I'm not too sure what some major advantages are. But extending seems to be big enough for me to want to start using this pattern.
At any rate, I'd like to hear some comments about anyone's experience with this pattern.
13 Responses to “Why No Love for the Monostate Pattern in ActionScript 3?”
By sakri on Nov 19, 2008 | Reply
I’ve only seen one “reason” to go for singletons, which is that apparently in the Flex framework, there are some issues with databinding and static methods and properties.
Event dispatching can be done through composition in static methods (implement IEventDispatcher).
By Fedlarm on Nov 19, 2008 | Reply
Thanks a lot for sharing… This is very very cool.
I’ve tried the databinding thing, and for me it works! yay.. i do get a warning inside Flex Builder though that says its not possible..
However i do see a problem regarding inheritence. Say you make to class’ inherit from the monostate class, and you change the value in one of the classes, you change the value in all of them.
By Fedlarm on Nov 19, 2008 | Reply
So to answer your question: “Why No Love for the Monostate Pattern in ActionScript 3?”
Because it cannot make use of inheritance that is of any use. When you inherit and set a value, it affects every other class that also inherits. Further it is not possible for a programmer to know when he can use the power of static methods or singleton..
By Richard Lord on Nov 19, 2008 | Reply
“…you change the value in one of the classes, you change the value in all of them.” That is the whole point of the monostate pattern - the static property has one value that is shared by all instances of the class and derived classes. If you don’t want this behaviour then you shouldn’t use monostate.
By Theo on Nov 19, 2008 | Reply
“Why no love for the Monostate pattern in ActionScript 3?”
Because it’s still just global variables?
By Bjorn Schultheiss on Nov 19, 2008 | Reply
I dont see why you need singletons or monostates for.
I’ve got a version of cairngorm running that has no singletons and uses DI methodologies.
I call it “intravenous” : )
By Matt on Nov 19, 2008 | Reply
By DI, do you mean Dependency Injection?
By Bjorn Schultheiss on Nov 19, 2008 | Reply
Yes.. It uses a factory to create the Presentation Models that get passed via reference to the views..
it injects the delegate in the command and injects the service in the delegate.
By Fedlarm on Nov 20, 2008 | Reply
“That is the whole point of the monostate pattern - the static property has one value that is shared by all instances of the class and derived classes.”
Yes I can I see that, but, he compares this pattern to Singleton, so I tried to argue for an issue with Monopattern compared to Singleton. Matt, says that it is far better than Singleton, I don’t agree on that. I think it is more simple to use, but it cannot always replace the Singleton, because of the difference on inheritance.
By Matt on Nov 20, 2008 | Reply
I never said Monostate is better than Singleton. I’m just curious about the pros and cons of using one or the other when attempting to ensure only you have only one instance of something. Monostate seems attractive in some ways, but I also have no problem using Singleton. This “debate” seems to be rather unique and spurs some very opinionated responses. Again, I don’t have a preference really. Just wanted to see what other people think because the Monostate pattern isn’t very prevalent in the ActionScript world.
By todd anderson on Nov 23, 2008 | Reply
Nice discussion. I guess for me, i would stay away from the monostate as a ‘model locator’. It may just be personal taste, but anything static connotes to me as being a utility.
If you want a true single instance of an implementation without having to resort to Singletons or a model being self-aware of its use, i would go for an instance of a Factory that keeps a single representation of an implementation rather than go with a Singleton or monostate.
Of course this really all boils down to the size of the development team and individual comfort. I can definitely see where your example will be beneficial and could develop against it if the case presents itself. But i personally would not use it - meaning that it goes against my notions of static properties, not that it is a bad implementation.
By james on Dec 9, 2008 | Reply
I’d have to agree with Todd. A Factory only limits the amount of instances that can be created, not the way in which they are implemented, as is the case with both the Singleton and MonoState. This makes it instantly more flexible.
By james on Dec 15, 2008 | Reply
Hi Matt,
not sure if you’ve seen this, but it’s definately worth a read…
https://segueuserfiles.middlebury.edu/xp/SingletonAndMonostate.pdf