COMP 310 Fall 2012	Lec14: Command Dispatching

Instead of merely telling the ball to perform an invariant update method (single method to move, paint, bounce, etc) with an invariant parameter (the Graphics object) being passed, the dispatcher sends out a variant command object that the ball invariantly executes.

A command to the ball to do something is defined as such:

package ballworld.model;

/**
 * Interface that represents commands sent through the dispatcher to process the balls
 * 
 */
public abstract interface IBallCmd {
    /**
     * The method run by the ball's update method which is called when the ball is updated by the dispatcher.
     * @param context The ball that is calling this method.   The context under which the command is to be run.
     * @param disp The Dispatcher that sent the command out.
     */	
    public abstract void apply(Ball context, Dispatcher disp);
}

Notice that the command is given a Ball object when it is executed, so that it knows what ball it is working on.  

Notice too that a reference to the Dispatcher that sent the command is also being passed along.    We'll modify our exisitng strategies later to take advantage of this.

For instance, the dispatcher may send out a command to update the state:

_dispatcher.updateAll(_updateStateCmd);

An anonymous inner class can be used above for the IBallCmd implementation without any loss of generality.  A typical dispatch using an anoymous inner class would look something like:

_dispatcher.notifyAll(new IBallCmd() {

	@Override
	/**
	 * Do stuff with the ball
	 */
	public void apply(Ball context, Dispatcher disp) {
				
		// Whatever you want to do with the context Ball!
					
	}				
});

How do you think that anonymous inner classes can be used to communicate additional information (i.e. additional input parameters) to the balls?   Remember that the one free parameter that updateAll() used to accept is now taken up with the command being passed!

All the ball ever does is to run the command, passing itself and the Dispatcher:

/**
 * The update method called by the main ball Dispatcher to notify all the balls to perform the given command.
 * The given command is executed.
 * @param o The Dispatcher that sent the update request.
 * @param cmd The IBallCmd that will be run.
 */
public void update(Observable o, Object cmd) {
    ((IBallCmd)cmd).apply(this, (Dispatcher) o);
}

What would the method body of an IBallCmd.apply() implementation look like if you

• Replaced the current, non-command dispatching -- i.e. both everything is done in a single update call?
• Just painted?
• Just updated without painting?

With this, a ball can be made to do whatever you want it to do, whenever you want it to do it!

Making Balls Talk to Eachother

Above, we saw that sending commands to the balls enables us to make them do anything the model wants them to do.   But does it matter who sent the command?   What if it was another ball that sent the command?   Couldn't that ball make the other balls do something?  Or the sending ball be affected by the other balls?

All we need to do is to enable a ball to get a hold of the Dispatcher.   If it has that, it can send out a command just like the model.

With two simple changes to our current system, we can modify the Ball's updateState method and the IUpdateStrategy.updateState method to take the Dispatcher as an input parameter.   The latter change will unfortunately instigate a rather tedious chore of modifying all the concrete IUpdateStrategy implementations.  (Can you explain this phenomenon in terms of variant/invariant?).

The update strategy is modified to accept the Dispatcher:

public interface IUpdateStrategy {
	/**
	 * Update the state of the context Ball.
	 * @param context  The context (host) Ball whose state is to be updated
	 * @param dispatcher  The Dispatcher who sent the command that is calling through to here.
	 */
	public abstract void updateState(Ball context, Dispatcher dispatcher);
}

In the Ball, we pass the Dispatcher along to the update strategy.   The IBallCmd is responsible for passing it to the Ball's updateState method.

/**
 * Update the state of the ball.   Delegates to the update strategy.
 * @param dispatcher The Dispatcher that sent the command that is calling this method.
 */
public void updateState(Dispatcher dispatcher){
	_updateStrategy.updateState(this, dispatcher); // update this ball's state using the strategy.		
}

Now an IUpdateStrategy is free to send commands out through the dispatcher to all the other ball -- including itself.

Always check if you are receiving your own command!

Consider the following update strategy that spawns new balls when a ball contacts another.:

public class SpawnStrategy implements IUpdateStrategy {

	private int count = 0; // tick counter that counts out the delay before another ball can be spawned.
	private int delay = 100;  // tick delay which increases at each spawn to keep total spawn rate from exponentially exploding.

	@Override
	public void updateState(final Ball context, Dispatcher dispatcher) {
	
		if (delay < count++) {
			dispatcher.notifyAll(new IBallCmd() {

				@Override
				public void apply(Ball other, Dispatcher disp) {

					if (count != 0 && context != other) {
						if ((context.getRadius() + other.getRadius()) > 
						    context.getLocation().distance(other.getLocation())) {
							disp.addObserver(new Ball(
									new Point(context.getLocation()), 
									context.getRadius(),
									new Point(-context.getVelocity().x+1,-context.getVelocity().y+1), 
									context.getColor(),
									context.getContainer(), 
									new SpawnStrategy(), 
									context.getPaintStrategy()));
							count = 0;
							delay *= 5;
						}
					}
				}

			});
		}
	}

}

© 2012 by Stephen Wong