COMP 310 Fall 2011	Lec13:  Painting continued and Command-Driven Dispatching

Painting continued...

First, we must finish up the previous lecture materials...

Command-Driven Dispatching

As discussed at the end of the last lecture, the dispatcher shouldn't be considered simply as the conveyor of a single message to the balls, "update!".     One problem that arises out of that viewpoint is that the painting and the state updating processes are coupled together, resulting in artifacts such as the simulation speeding up whenever the frame is resized or an animated GIF is used. 

The dispatcher should send a message (a "command") object to the balls.

But since the ball has no idea a priori what that command is, the only thing that the ball can do is to delegate the interpretation of that command to the one object that knows unequivocally what the command is...the command itelf.

The ball delegates to the command to perform the processing associated with that command.

The balls can be made to do anything one desires simply by sending the appropriate message to them.

Definition:

Strategy -- an abstract behavior/processing that is used by a context object for a specific purpose, e.g. it is used with a known semantic.    Painting and updating the state of the ball are strategies.

Command -- and abstract behavior/processing that is used by the context object without a specific purpose, without a specific semantic.   All the context knows is when to run the command, e.g. whenever it is called to update.  But the context never needs to know what the command is really doing.   Typically, because of the lack of semantic, the command will either have a void return or the context will simply pass any returned values on to something else without doing any additional processing on them -- it can't because the context doesn't know what the results are.

The discussion continues at the bottom half of Lab04...

© 2011 by Stephen Wong and Scott Rixner