COMP 310
Spring 2010

Lec10:  Collisions, killing and the environment

Home  Info  Owlspace  Resources

Homework should be completed before class on Friday.   Directions on how to use Subclipse to turn in your work will be posted, but we will spend some class time on Friday to make sure that everyone is able to do it successfully.    Bring your laptops to class!

First, let's finish up collisons...

Post-Collision Behaviors

How do you get a ball to react to the collision, e.g. change color, explode, get killed, etc?   Is this a variant or invariant behavior?

Once again, we see the subtle line between the invariance of doing something vs. the variance of what is being done.

The collision handling command from the previous lecture is therefore forced to call the invariant method of the ball for post-collision behavior.     That method in turn, must then delegate to a strategy to handle it.  (Why shouldn't the strategy's collision update method be called directly from the collision command?)

Since classes are collections of lambdas (methods), then the update strategy can carry methods for both updating the state and post-collision updating.


Killing Balls

Likewise what happens when one attempts to kill a ball?  

This is basically a very similar issue to the post-collision behaviors, so we would expect a very similar solution, i.e. an invariant method calling variant behaviors on a strategy.   The update strategy class at this point, is now up to 3 different update methods:  update state, update collision, update kill.

But what about the issue of a potentially non-successful kill attempt?   When a ball's "kill" method is called, does it invariantly get removed from the dispatcher?

This technique of "intercepting" calls is very common and we will see it again in various forms, though all involve some sort of "indirection" layer that is being inserted into the program flow or architecture.


Passing an Environment to the Ball

While it is tempting to simply give each ball a reference to the main model class, in general, this would be a very unwise solution as this would expose way too much of the inner workings of the model to the ball.

Restrict the visibility of the model by using an interface.   At this point the ball only needs the following services from the model:

These services should be methods on an interface, IEnvironment, that represents the enivironment in which the ball is operating.

Two ways of accomplishing this:

  1. The model implements IEnvironment

  2. The model has a factory method that returns an IEnvironmentimplementation.

The bottom line here is using an interface to protect (encapsulate) the system by providing a portal with limited capabilities.   From a security standpoint, this helps seal off the system from posible intrusion.

Solution to the problem of how a single class can implement more than one interface or the same interface with different behaviors:

 The factory method technique above is also the solution to enabling classes to implement more than one interface at the same time, in spite of Java's single inheritance restriction.    The class simply needs to have multiple factory methods, each producing its own implementation of a particular interface.  

This even enables the class to implement the same interface multiple times but with different behaviors--each factory method, while returning a result of the same type, is producing implementations of that same interface but with different behaviors.   This is possible because technically, the factory methods are producing separate objects.


© 2010 by Stephen Wong