Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
July 26, 2017, 05:37:53 AM
Home Help Search Login Register
News: Please DM @puremvc on Twitter to gain forum access. Spambots are why we can't have nice things.
Pages: [1]
Print
Author Topic: What is the recommended number of notifications for a command?  (Read 3158 times)
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW
« on: June 20, 2011, 09:04:24 PM »

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

Code:
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).
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2870



View Profile WWW
« Reply #1 on: June 21, 2011, 07:35:29 AM »

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>
Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW
« Reply #2 on: June 21, 2011, 06:49:45 PM »

Thanks for the reassurance.  Basically, one notification per command is still the convention.  I'm not going insane.
Logged
Pages: [1]
Print
Jump to: