Overview
This tutorial will begin with the Model and View from Tutorial 2
and adds the last component -- the Controller. The Controller interprets keyboard inputs from the
user and translates them into messages that are passed to the Model or View.
Usage in the Simulation Container
Start the Simulation.
The Simulation should look identical to that of Tutorial 2.
With the Display view still selected, use the plus and minus keys to increase and
decrease the number of particles, respectively.
The Controller, Model, and Messages
UserInputMessages generated from keyboard inputs are translated
into the ParticleModel specific Messages "increase particle
quantity" and "decrease particle quantity"
The ParticleModel does not use the UserInputMessages
directly for two primary reasons: separation of concerns and encapsulization.
The ParticleModel knows and understands concrete concepts such
as "change particle color" or "move particle emmitter to the left".
It is the function of this Controller to translate input messages into these
concrete concepts. If the ParticleModel responded to UserInputEvents
directly then changes that are external to the Controller - Model communication
would be able to affect the ParticleModel breaking the encapsulization
of the Controller - Model communication.
The flexibility of this separation is enormous. For example, if this
particle system were to be used in a client / server application, only
this Controller would need to be enhanced to receive and translate new
events from the networking subsystem; neither the Model or View needs to
change. This allows the components to be reused in different simulations.
This flexibility is bi-directional. The Model can define new Messages
that it responds to independant of the Controller. In other words, new messages can be defined and
the Model can be coded to accept these messages but no Controller need yet send the messages. This
shows the degree to which each component can be developed and tested separately.
Code Structure
Particle, ParticleCache, and ParticleView
remain unchanged from Tutorial 2. ParticleModel has been modified to
introduce two new related concepts: number of displayed particles and
ParticleMessage handling.
The UserInputSimlet translates
keyboard events into ActionTypes and
makes them available in the MessageContext. It is the job of the ParticleController
to receive + and - ActionTypes.
The ParticleController looks for + and - ActionTypes
and translates them into the appropriate ParticleQuantityMessage. These
messages are received by the ParticleModel which performs
the appropriate operations on the particles.
Because ParticleQuantityMessages do not contain any stateful information,
the flyweight pattern was chosen.
"A flywieght is a shared object that can be used in multiple contexts simultaneously." [GOF95]
The ParticleQuantityMessage messages are implemented as flyweights. Rather than
creating a new message for each user input message, the same object is reused. In any situation
where a stateless object or an object whose state does not depend on its context can be used,
the flyweight pattern should be considered.
Performance Optimizations
Compare the following two code snippets:
(50.0 * Math.random()) - 25.0f) * 10.0f
random.nextInt() % 500
In the first snippet, Math.random() produces a double.
This means that 64-bit floating point math is in use for the multiplication. Then a
cast is done to a float to do the subtraction and then finally a 32-bit floating point
multiplication is perfomed.
In the second snippet random.nextInt() produces an integer that is
in the range [Integer.MIN_VALUE, Integer.MAX_VALUE].
The modulus operation then limits the result to the range
(-500, 500). Similar results were achieved with only one 32-bit
operation.
Conclusion
The using the MVC paradigm to separate each function of the particle emitter
into a separate object has simplified the code, created a separation of
concerns, and provided for more reusable objects.
