PureMVC Architects Lounge

Quite by accident, I found this in our code base:

public class AppStartupCommand extends SimpleCommand implements ICommand {
  ...
  override public function execute(notification:INotification):void{
    switch (notification.getName()) {
      case ApplicationConstants.START_UP: {
        //40 lines
      }
      case ApplicationConstants.LOAD_CONF: {
        //5 lines
      }
      //approximately 100 more lines of case statements, approx 10 case statements total
      //mostly registering mediators, proxies, and other commands
    }
  }
  ...
  //subroutines... so that no case statement goes beyond more than a few lines
}

At first I was kinda horrified... case statements in execute() ?!  But then I remembered that I had considered doing this myself in the past.

Is there any good rule of thumb for how to decide when multiple notifications should share the same command as above, and when a notification should have its own command?  I am about to recommend to this person that they implement a separate command per notification since there is no single piece of shared logic in any case statement (ie: nowhere do case 1: ... case n: call a common sub-routine).  But on the other hand, the entire class file is only 350 lines long, and there are no other command classes cluttering the code base... and the code is sequential.  I'm just worried about it getting out of hand.  I don't want to see a project later where every notification goes through one monolithic command.  Honestly, I have always had just one notification per command.  Any logic that couldn't handle a given structure of body data needed another command/notification.

I have to admit, though, at its current scale, his method was also a lot easier to implement than using the Loadup utility.  (basing this assumption on the amount of time he spent coding this versus the amount of time I spent struggling to comprehend Loadup tutorials).

Pretty much, I like to keep the responsibilities of any actor as minimal as possible. It's just good OOP design to do so.

When you gang everything up in one big class full of conditionals, it becomes unmanageable. It's impossible to reuse any part of the code, and to even describe all that it does. Whoever wrote the code may have had the big picture in his or her head at the time, but another person approaching it has to worry that if they touch it it will break.

You were correct to recoil in horror.
-=Cliff>

Thanks for the reassurance.  Basically, one notification per command is still the convention.  I'm not going insane.