Title: Handler classes for mediators Post by: sasuke on November 11, 2009, 11:28:29 Hi all.
When creating mediators for complicated views, the handleNotification method quickly gets out of hand and becomes overly complex when dealing with a bunch of notifications. Would it be a good idea to introduce the concept of handler classes for mediators which lead to even more cohesion [i.e. the handler responsible for handling notifications as opposed to Mediators]. Something along the lines of: public interface IHandler What do you guys think? If not this, then what else can be done to remedy the above scenario? TIA, sasuke Title: Re: Handler classes for mediators Post by: Jason MacDonald on November 12, 2009, 08:24:48 If your mediators are getting "out of hand" then you are putting too much logic into your mediators. You shouldn't be putting more than simple "get" and "set" calls in your mediators. Anything more complex should go in a command. It sounds like you are over extending the mediator to pefrom tasks it is not meant to.
As Cliff has stated before, the mediator handleNotification method is constructed in such a way that it acts as a kind of snaity code check. If you find it's getting unwieldy, then it's a sign you are trying to do too much and need to refactor. Title: Re: Handler classes for mediators Post by: puremvc on November 12, 2009, 09:22:13 For the most part, as Jason mentioned, to many interests is usually a sign of an overworked mediator and the answer is usually to cleave it in twain. Make two (or more) mediators that handle different sub-assemblies of this (clearly mammoth) view component.
But there are some places where a mediator class hierarchy as you've described can be helpful. If you have several cross-cutting concerns, you can leverage this approach successfully. Such as in MultiCore apps using pipes, the JunctionMediator (part of the pipes utility) handles notifications common to all pipe aware modules (accepting input and output pipes) and the subclass handles all the specific stuff to that core. In the PipeWorks application it actually goes to three levels of hierarchy. JunctionMediator is extended by LoggingJunctionMediator which adds the ability for every core send messages to the logger. Then the ShellJunctionMediator and the PrattlerJunctionMediator both extend LoggingJunctionMediator to add the specific notification handling for the Shell and Prattler modules. -=Cliff> Title: Re: Handler classes for mediators Post by: Jason MacDonald on November 12, 2009, 10:16:00 I may have misunderstood the issue. I thought the issue was he had overly complex handlers (ie: trying to do way too mcuh per handler), not too many handlers in general.
Title: Re: Handler classes for mediators Post by: sasuke on November 16, 2009, 11:01:19 Having read this thread http://forums.puremvc.org/index.php?topic=1524.0 I realized that I was trying to solve the wrong problem here. Rather than going by the SRP and striving for separation of concerns, I was just shifting the burden from mediators to handlers.
Thanks for the replies Cliff & others. :) -sasuke |