execute() method of MacroCommand

[sasuke]

Hi,

Is there any reasoning behind why the `execute` method of the MacroCommand is marked `final`? I've at times found the need to override the `execute` method to execute sub-commands *along* with executing some additional functionality. Something along these lines:

:

class MyCommand extends MacroCommand
{
override protected function initializeMacroCommand( ) : void
{
addSubCommand(FirstCommand);
addSubCommand(SecondCommand);
addSubCommand(ThirdCommand);
}

override public function execute(notification:INotification):void
{
super.execute();
sendNotification(COMPLEX_INITIALIZATION_COMPLETE);
}
}

In the absence of the above setup, I'd have to do something like:

:

class MyCommand extends MacroCommand
{
override protected function initializeMacroCommand( ) : void
{
addSubCommand(FirstCommand);
addSubCommand(SecondCommand);
addSubCommand(ThirdCommand);
addSubCommand(ComplexInitializationCompleteCommand);
}
}

public class ComplexInitializationCompleteCommand extends Command
{
    override public function execute(notification:INotification):void
    {
        sendNotification(COMPLEX_INITIALIZATION_COMPLETE);
    }
}

Thoughts?

[jpwrunyan]

The MacroCommand does not execute logic, rather it calls the execute() method of the SimpleCommands that it.. uh.. macros (is that a verb???).  Any "extra" logic should be in an extra SimpleCommand that the MacroCommand also executes.  In your case, the second code-block is exactly correct.

Anyway, MacroCommand and SimpleCommand are very different things.  The SimpleCommand does stuff (like an .exe) while the MacroCommand just bundles a bunch of SimpleCommands so they do their thing all at once and with one notification (like a .bat).  Or, more apropos, an Excel macro does not do anything in addition to the simple commands that it contains.  Whether I do it by hand or with a macro, the process in Excel is identical.  I believe that's the definition of a macro.  So if the MacroCommand's execute() does anything else, it's not really a macro anymore but some weird hybrid thing-that-should-not-be.  Thus the reasoning, I assume, behind execute being final.

An alternative is that you could make a "boss" SimpleCommand that sends the notifications required to execute all those other commands and perform some additional logic within its execute.  The notification name would not be shared among the commands the way it is with MacroCommand but ideally SimpleCommands shouldn't care what the name of their notification is anyway and the overall functionality would be identical.  I'm just not sure if it is good etiquette to execute SimpleCommands from within other SimpleCommands.

[sasuke]

Sorry, but the reasoning doesn't sound convincing in your case.

The MacroCommand does execute logic; the logic in this case being executing other commands. It is a specialized command provided as a convenience feature by the framework here. The primary purpose of this would be to help developers re-use existing commands and promote the creation of re-usable commands. But why forbid developers from extending this "handy" class? Why forbid extension?

One of the major points chalked against PureMVC by the users is the exponential explosion of classes when it comes to using the framework for executing a use case. Creating a command just for sending a single notification really can't be justified.

Anyways, Cliff, thoughts?

TIA,
sasuke

[puremvc]

This is not the responsibility of the MacroCommand as it was designed. If the execute method were protected instead of final, then the likelihood of it being misused by not calling super is pretty high. You can always have the last command in the macro send the note that says it has completed.

One of the major points chalked against PureMVC by the users is the exponential explosion of classes when it comes to using the framework for executing a use case. Creating a command just for sending a single notification really can't be justified.

That's one of the major points chalked against any OOP system. When I developed in Perl using the 'unified file theorem' (everything goes in one big honking file), I too forked the sign of the evil eye at full-on OOP languages like Java for this very reason. It's like a one man band vs an orchestra. Sure the one man can strap all those drums and cymbals and harmonicas to him and somehow make a coherent musical statement with it, but there's a reason orchestras are still around.

I'm not saying you need to have tons of classes just for the thrill of it. The goal is still to do the job with the fewest number of actors while still distributing the application's responsibilities amongst them in a sensible way. Many of the PureMVC applications I've seen rely far to heavily on Commands, one of the things that drove me from Cairngorm years ago, where there were always so many commands to write. Taking advantage of long-lived actors (Mediator and Proxy) that share a relationship while still decoupling the view components from the Model and visa versa, the number of Commands fell radically.

Also, just FYI, I rarely use MacroCommands except for startup, and even for that I often combine the View and Model prep into a single SimpleCommand. I just haven't found the need for them.

-=Cliff>

[sasuke]

If the execute method were protected instead of final, then the likelihood of it being misused by not calling super is pretty high. You can always have the last command in the macro send the note that says it has completed.

But that is the least usage path given that no one typically overrides the `execute` method. All normal usages of MacroCommand override the `initializeMacroCommand` method. Regarding the last command part, like already mentioned, writing a Command class which has a single sendNotification() call seems pretty wrong IMO. Also, there are a couple of other classes in the framework in which not calling the super method anyways ends up screwing things. But those methods were still marked non-final, no?

I do understand that the MacroCommand class was created with a different motive in mind but allowing developers to extend on that would be great. Anyways, not a big deal IMO, I just wanted your take on the design decision. I'd now be creating my own version of MacroCommand which I previously didn't want to.

Regards,
sasuke