Cairngorm – the Way I See It – Third Part
To put together the last part of the Cairngorm series, I’ve started doing a little research about the Cairngorm architecture and got myself into trouble : I got lost into debates! All over the place there are voices which express a “this architecture versus that one“, who points out the pro and con for each and every single principle applied there. I don’t like debates, at least not in the sense of “mine is bigger than yours“, so, I feel that it is my duty to remind you the following:
- if you are reading this series of articles, then you got here looking for tutorials, right? You are looking for a way to discipline / educate yourself, to get started with the design patterns terms (in a practical sense) and to make your first mistakes – from which you will surely learn;
- do not get discouraged by those voices I’ve mentioned : criticism is good as long as you take what you need from it (and I’ll give you an example later regarding Singleton debates). To consider a bad thing that Cairngorm relies too much on the binding seems stupid to me, since points out another debate about how good is binding and why you shouldn’t use it. Another issue which is considered to be very important is monolithic classes : nobody forces you to get there, but you just might run into this problem. The solution ? Refactor your classes grouping by functionality and roles – as the basic Cairngorm principle says;
- take a good look at Universal Mind Cairngorm Extensions before starting to play with Cairngorm;
- Cairngorm 3 is quite recent – so Cairngorm is not (yet) deprecated, even if the alternatives seems better (by alternatives I mean pureMVC, Mate, Parsley, etc);
- if you haven’t done so until now, you should take a look to the official article which introduces you into Cairngorm.
Since I’ve mentioned the debate over Singleton, I’m inviting you to read this and then this. I’m not going to take sides over this debate (too) – I’m so in love with Singleton and so far from puristic approach to design pattern. As long as you are carefully about excessive use of Singletons and you strive to respect the loose coupling between classes, you will be fine – and the day when Singletons will disappear from your code is not that far.
Now, there are two things that you will need in order to complete your Cairngorm terms : one is the Mediator. Shortly said a mediator is a class two other classes, so those two won’t couple themselves. You can find a way (and the explanation) to do it here.
Also, you will need some sort of substitute for the Observer pattern. The closest class to that is the following (the code is not my creation – I took it from somewhere, but I cannot remember where – my apologize to the author):
public class Observe extends Observer { private var _handler : Function; private var _source : Object; override public function get handler() : Function { return _handler; } public function set handler( value : Function ) : void { _handler = value; if( value != null ) { isHandlerInitialized = true; if( isHandlerInitialized && isSourceInitialized ) { callHandler(); } } } override public function get source() : Object { return _source; } public function set source( value : Object ) : void { _source = value; isSourceInitialized = true; if( isHandlerInitialized && isSourceInitialized ) { callHandler(); } } } public class Observer { protected var isHandlerInitialized : Boolean = false; protected var isSourceInitialized : Boolean = false; public function get handler() : Function { return null; } public function get source() : Object { return null; } public function execute( method : Function, ...params : Array ) : Object { var returnValue : Object; try { returnValue = method.apply( null, params ); } catch( e : Error ) { trace( e.message ); } return returnValue; } protected function callHandler() : void { try { handler.call( null, source ); } catch( e : Error ) { trace( e.message ); } } }
How you will use it ? Simple : let’s say you need to observe some property of a instance child. You’ll use binding to set the Observe source property and declare a handler for that (e.g. : < mx: Observe source = ” { someChild.someProp } ” handler = ” onChildPropChanged () ” / > ). As you can see, this is not a design pattern, but a trick to achieve as close as possible the same effect.
Last but not least, you’ll have to know about you might bump into while using Cairngorm:
- you will not be happy about not being able to notify events to the view. Dispatching events from commands and listening them in the view seems like a good idea – but after a degree of complexity this will surely get in your way. Writing a Singleton which can cover the register-me-for-event the way FrontController is doing it might be a much clearer solution – of course, keeping them separately so you can easily locate them.
- you will be angry with the number of small classes containing commands and events. There are workarounds for this one that you can google. My technique is to declare all the event names in a static manner and use only the CairngormEvent, without creating more classes – you’ll get annoyed by the type casting anyway. Another thing that you can quick to is to extend the CairngormEvent to add a class property so the getter of data will type cast itself (as I’ve said in part II).
- on large applications, use case handling and reacting to state becomes overwhelming for the number of views you have to cover – very hard when you have to debug. Making one big view could help you with that – also you might want to introduce new design patterns for this, e.g. State Machine.
Of course, this is not everything that might get into troubles, just what I could recommend you right now – but I would like to hear from you if you need my help with something.
Before ending this post, I’m recommending you to read an article about PureMVC – of course, once you’ve absorbed all there is to know from Cairngorm.
