explorers' club

explorations in dev, science, sci-fi, games, and other fun stuff!

A new take on SequenceCommand (part 1)

1 Comment

With an ever-growing code base on our ever-growing project, I have been doing quite a bit of thinking regarding the Cairngorm SequenceCommand. It seems that every time we add a new feature, we have to add at least one new command, that is just a slight variation on the same thing. This is especially true in our initialization of our application. It could be even more true if you were using a modular type approach to building your applications.

During the initialization of our application, a chain of SequenceCommands fire off to get their needed data. There are also times that this same information needs to be retrieved out-of-sequence or retrieved solely on its own. So in a traditional approach, you would have a regular Cairngorm Command subclass when you need this information out-of-sequence, and then an almost duplicate Cairngorm SequenceCommand for those times previously mentioned. So essentially you are duplicating the needed code to achieve the same results. And the reason this is, is because the logic to perform the ‘guts’ of the SequenceCommand has some dependencies on the next command to be called. This then can have an effect not only the command in question but also the possible command preceding it and/or the next command as well.

I don’t like this for a few reasons:

  1. unnecessary code duplication.
  2. code dependencies at the logic level of the commands (increased coupling?).
  3. ripple effects for related commands.

So I started to think about how to make this process more efficient. How could I achieve code re-usage and still maintain the ability to ‘sequence’ commands together. I have been looking at how the mx.effects classes work. You can have a Move instance do something once like move a box from ptA to ptB. You can also have several other effects do their tasks, and then turn around and use your Move instance again. You can even chain Move along with those other effect to fire off in sequence with out modifying the original instances’ properties. So why can’t the same be applied to how we chain commands together? I think it can with very little effort. We’ll talk about the details in part 2.

Advertisements

One thought on “A new take on SequenceCommand (part 1)

  1. Pingback: The Sequence Command Revived. « jwopitz - flex/flash exploration

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s