Abstract mediators?

[eco_bach]

Came across this post and explanation for reducing code in concrete mediators
http://www.ahrooga.com/2009/06/puremvc-creating-a-short-hand-mediator/
http://www.ahrooga.com/blog/wp-content/uploads/2009/06/AbstractMediator.as

Would this be a recommended(best) practice?

[puremvc]

This merely re-engineers the notification handling to use separate methods for handling notifications. I can’t see it ’significantly shortening’ a concrete mediator.

The code in listNotificationInterests, (which generally just returns an array of literal strings) is now replaced by a series of calls (presumably invoked from the constructor) to registerMediatorInterests and is more complex because now you’re mapping those strings to handlers. You didn’t need to override a method, but the extra code making the calls, mapping the notifications to the handlers is going to net you the same amount of characters or more if you have more than one or two interests.

Next, the code in handleNotification is generally a switch statement with a case block for each notification. This single handler scheme was chosen because a) it is simpler, and b) it discourages doing anything terribly complex, which should be moved off into a command, since the mediator’s role is one of communication, not logic. By moving the handlers out of the switch statement and into handlers, you now have a) added the overhead of method signatures for all those new handlers, and b) encouraged doing more heavy lifting in the mediator, a step away from best practice use of the framework. Net code for this part of the ’shortening’ is likely equal to or greater than had it been handled in handleNotification.

I would be interested to see a Mediator with 5 interests implemented both ways, to see this significant shortening.

-=Cliff>

[Groady]

I wrote that blog post. I replied to Cliff's comment there but I'll copy it here also:

I see your point about it not necessarily being shorter once you account for the actual handler functions.

Part of my motivation for this was that I constantly find myself adding my notification constants to the listNotificationInterests method but forgetting to add a case to the switch statement in the handleNotification method. Not a big deal but having a single registration method feels more elegant and “cleaner” with a similar syntax as the addEventListener method. Also the mapped handler functions can have strongly typed parameters which cuts out the need to explicitly cast notification objects as often needed when using the switch statement method.

I see your point about promoting best practices by using a single handler, however I often found myself calling methods from within this switch statement. Not necessarily because I was doing anything complex, but because It felt more ‘natural’ to contain code in relevant functions like everything else in AS3. I did consider the method signature overhead which comes with this kind of mapping however I assumed it would be no worse than addEventListener (I may be wrong?).

You’ve definitely offered some food for thought and made me re-think the point of Mediators in the context of PureMVC.