COMP 310
Spring 2018

Lec13:  Painting continued and Command-Driven Dispatching

Home  Info  Canvas   Java Resources  Eclipse Resources  Piazza

Just something a little bit crazy to have fun with...

Painting continued...

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

Command-Driven Dispatching

For reference, please see the Command-dispatching Architecture with Inter-ball Interactions" target="_blank">command-dispatching Ballworld with inter-ball interactions demo.     Note:  This is the functionality that you will be creating for HW05, not HW04.  In HW04, the command dispatching will be implemented, but only to the extent of replicating the existing updating and new painting behaviors.

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.


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.


Optional materials on using lambda for asynchronous updating and key binding with action maps.







© 2018 by Stephen Wong