I've finished reading a great article on http://addyosmani.com/largescalejavascript/
This article explains how to combine modules, a facade, and a mediator together for a JavaScript application.
I can code what the article explains, but I don't understand why I need to use facade to access the mediator.
I think I can access the mediator directly from my modules.
Please advise me..
P.S: Is it a valid question here?
The reference material for that section, Pro Javascript Design Patterns, answers your question quite nicely when it says the following:
Facades are never strictly necessary. The same tasks can be completed without them. This is an organizational pattern; it allows you to modify the interfaces of classes and objects to be more convenient to you.
Take this, perhaps ridiculous, analogy:
YOU are a woodpecker (module), and you would like to pick out some larvae (data) which have been lain on a house's support-structure (Core). Normally, you'd just peck (actually woodpeckers have a long, barbed tongue that wraps around their skull) the larvae off of the infrastructure, but some carpenter (Application Architect) has applied a Facade on the outside of the house. However, the carpenter was nice enough to poke holes in the Facade to allow only woodpeckers to access the larvae. Furthermore, the carpenter was smart enough to make these holes a certain shape -- allowing the woodpecker to accomplish more larvae-eating tasks per peck.
So why have a facade, again?
Relating the Facade back to Addy's post -- the Facade augments a Sandbox in that a sandbox provides predefined efficacies which allow one module to accomplish tasks in specific ways, e.g. wholesale. For instance, you wouldn't want a sandbox that forces the user to write:
var node = getNode('#errorPanel');
node.innerHTML = 'Field is invalid!';
A better sandbox may have something like:
notifyUser.error('Field is invalid!');
The Facade on the other hand, can provide those throughways just the same, by only listening to the mediator.fire('error:Validation', 'Field is invalid!') channel.
The Facade in Addy's post, which I use all the time, could theoretically simply forward requests onto the Core. Probably, it would check something in the channel's signal to make sure, say, a Finch isn't trying to peck larvae that will make it sick -- e.g. throw an Exception.
This is why it may make sense to have a separate channel-medium (ie mediator) for your core, where your Facade is the sole 'referencer' to the Core -- and your modules only reference the Facade. Another way, is to enforce amongst your team a convention for discrete-channel-names, e.g. mediator.fire('ready://Core') & mediator.fire('updated://ToDos/task', taskId). The facade would listen to 'updated://ToDos/task' and would make request(s) to the core -- which may look something like:
var thus = mediator.installTo(this);
this.on('updated://ToDos/task', function(id){
thus.fire('request://Core/save/todo', id);
thus.fire('user://Core/notify/task/added', id);
});
this.on('response://Core/save/todo', function(err, id){
if(!err){
// ... success -- notify module!
} else {
// ... notify for failure :(
}
});
ATTENTION! do not write your handlers directly within your listener calls!
I really hope this helps and that I don't get downvoted for talking about birds ;)
