- basics
- interests
- projects
-
- vitae
- story
- s100+ pages
Last edited - March / 99
|
|
-- Hear and forget; see and remember; do and understand...
the model-view-controller (MVC) design pattern
      
MVC things to do...
Here's a list of some ways to extend this code in order to get more
familiar with the way the MVC architecture works:
- Create another view for the application. Have this
one simulate an EKG, with a line scrolling across the window, and spikes
occurring for each heartbeat.
- Create a separate thread for updating the views (so
that the model thread can continue unaffected by how many
views need to be updated). This is useful in the cases
where the model is computationally intensive or needs to
be running on a strict timing pattern.
- Implement a Command pattern [to be described in the GA writeup...but
for now, check out Head First
or Buschmann
for info on it] to send the messages between the
controller and the model. It will
clarify the various actions that the model allows.
- Implement the Visitor pattern [again, to be described in the GA
writeup] to send multiple types of updates (multiple update objects) from
the model to the views. Each
view can handle each update type in its own manner. The
Visitor pattern makes the code explicit about which updates are being
handled and which are being ignored. [One could use
instanceOf
but that's not quite as pretty. Acceptable for small projects, it limits
the "growability" of your application - use instanceOf with
caution.]
- Create proxies for the model, view
and controller in order to facilitate distributing them
among several machines. There should be two proxies inbetween each MVC pair:
- the model to view connection becomes
a model to view proxy which connects via
a stream to a model proxy connected to a
view
- likewise, the controller to model
connection becomes a controller to model
proxy which connects via a stream to a controller
proxy connected to a model
- In both case, the proxies use streams to communicate - that way they
can use pipes (same machine) or sockets (networked).
- A couple of listeners might need to be set up to spawn off new proxies
in the networked case.
- In cases where the views receive their updates at
varying speeds (a view is on a modem), then each
view needs to be updated in their own thread. If not, the
rest of the application (the model and other
views that need to be updated) will have to wait for
slower view to finish its update (the I/O blocks for all
the modem acknowledgements). Create a multi-threaded distributed update,
building up on the proxies and multi-threaded update methods mentioned
above.
Of course, you could start by writing your own toy MVC application too.
A good starter problem would be to write a model of
a clock. Create two views that could display the time - one digital
display
and another view presenting the time on an analog display. A
controller could allow the user to set the time and/or
change between 12 and 24 hour displays. As you create it, I'm sure you can
come up with more options to add - and you just might be surprised how
easy it will be to implement them!
Naturally, you might want to look at some other
docs on MVC in order to get
a better grasp of it...and if you have comments on anything you've read
here, drop me a note.
      
|