puremvc
|
|
« Reply #1 on: November 06, 2009, 08:47:10 » |
|
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>
|