or, implement the Mediator-Mini-Controller anti-pattern at your peril.
The robotlegs out-of-the-box implementation – what I like to think of as the standard issue trousers – relies on a version of the mediator pattern.
In this usage, the mediator’s job description is clear: deliver stuff from the application’s shared event dispatcher to the view, and from the view to the event dispatcher.
Like any good delivery service*, it also offers enhanced packaging for your exotic sending needs. Perhaps slipping your simple
MouseEvent into an air-mail-approved
A good delivery service also varies its delivery approach based on the type of thing being delivered. Simple letters belong in the mail box. Packages requiring a signature lead to a knock on the door. Fragile goods are handled carefully.
But, and it’s a vital distinction, the mailman doesn’t open the mail.
Why shouldn’t the mailman open the mail?
Imagine that I asked my postie to start opening my post – or perhaps some of my post – and, based on the contents, delivering it, binning it, marking it urgent for me. Perhaps he could sort it into happy post and sad post? It would save me some work if he took it out of the envelopes first – after all, he passes my recycling bin on his way between the front door and the garden gate.
This might work out well for a while. But it would inevitably lead to problems. The return envelopes for starters – recycle, or use? How does the postie know whether I’m going to need them? And, yes, letters from people telling me to pay them money probably belong in the ‘sad’ pile – but what if the letter asks me to pay the deposit for something really cool?
And if something went missing – how would we know who’d misplaced the important letter? Instead of just back tracking through my own actions, I’d be querying the postie’s movements as well.
A good mediator should know and care what to do with each type of information – but they shouldn’t vary their behaviours based on the values they find.
If your mediator reads the view’s mail, you end up with an application in which your logic is distributed over multiple mediators. It’s not just harder to keep DRY (because different but similar views may have mediators which would each need to implement some of this logic), it’s virtually impossible for someone looking from the outside to know where to start. And never forget, that someone is most likely going to be you, a year and several projects down the line.
If you do end up with logic – specifically a variation in behaviour (usually seen in the wild as a conditional such as
switch) – in your mediator, at least call it what it is: SomeViewMediatorController.
And what the hell’s wrong with a Mediator Controller?
[@troygilbert, Nov 16, 2:10 am GMT]
Troy Gilbert points out that robotlegs mediators make excellent view-controllers. And they do – but a view-controller approach requires a different overall architecture to a mediator approach. We can use mediators at various levels of granularity – mediating a group of screens, a screen, a component or even just a button. In robotlegs, anything that lands on the displayList can be mediated. And with true mediators, you can take advantage of this in a relaxed way; the choice of whether to mediate a button or a group of buttons has no far reaching consequences for your application.
Can the same be said for view-controllers? Does it matter which views have controllers and which are just slaves to other views? I think it matters a great deal. You can still have a great, flexible, DRY design based on view-controllers, but almost certainly not just through the relaxed implementation of nosy mediators that open the view’s mail.
Troy is building some amazing stuff, so I’ve got no doubt that he is conscious in his decision to use mediators as controllers, and designs his apps accordingly; the mediator-mini-controller anti-pattern arises when you unconsciously use your mediators for controller responsibilities.
Who could resist?
I’ll confess that I don’t always resist. And I nearly always regret it. To help my willpower, I like to think of my classes as reluctant employees. They’re just waiting for a chance to storm into my office (head) waving their contract and complaining that the task I’ve just given them wasn’t in their job description.
And they’d be right. If I want my mediators to act like controllers I should give them the promotion in both name and status, and treat them with the respect they deserve. Otherwise, I’ll stick with the fundamental social premise that the mailman should never open the mail.
* Like programming, delivery activites are carried out by women, of course, as well as men and cats.