In Exercise 16, we studied a program that used a change propagation mechanism similar to MVC. A Reactor could watch other Reactors, so that when the "watched" changed the "watcher" could update itself (and propagate the change to any Reactor that was watching it). This change propagation mechanism is just what an MVC system requires--though Models and Views are different components, and so the elements of the mechanism will be distributed over them.
In Exercise 17, you are studying a simple implementation of MVC, in which the ideas of "watched" and "watcher" are separated into Model and View, respectively.
Not all of you managed to digest this code very quickly. It is considerably more complex than the reactor demo, but some of what you see is similar. The "subscription" mechanism for dependents and change propagation has been factored into two classes, Model and View. The "core functionality" of the example resides in a class derived from Model, Counter. The interface components of the example reside in classes derived from View. (Our interface is file-driven, for the sake of simplicity and portability.)
Feel free to continue to study this code. Download it, compile it, and run it. Try to follow the inheritance relationships. Simulate the code's execution by hand. You will have a better feel for MVC if you understand this simple implementation example. Feel free to ask any questions you may have, next time in class, and we will try to answer them!
Here are some of the questions and issues raised by students in this and previous sections:
change()at the bottom of
reset()do? -- This is the model sending telling itself "I just changed!", in response to which it tells all of its dependents "I just changed!".
The more likely use of MVC is in an event-driven, distributed environment. If you would like to see such an implementation of MVC, check out the Java GUI version I provide on the code page.
this, and why does
view::viewpass it to the model with its
thisis a pointer(C++)/reference(Java) to the object sending the message. In this case, the sender is a
View, actually a
CounterLineView. Why? So that the model knows who to send an
update()to later when the model changes!
virtual = 0(C++) or
abstract(Java) mean? -- These constructs are C++'s and Java's way for a class to say "Instances of me must respond to this message, but I do not know how they will respond. So a subclass of me must implement this method." Models must respond to the message
value()-- that is how views ask them what their current value is, after receiving an
update()message -- but the
Modelclass has no idea what data any particular model keeps track of. So subclasses of
Modelmust be sure to implement
Work in the same teams as you did for Session 17.
You may want to consider dividing up the tasks to be done, working independently for a while, and then come to together as a group at the end of the session to discuss and refine your answers.
For each task above, be sure to explain why the idea or technique you chose to use is a good choice for supporting MVC programmers.
Your group submits solutions to all three tasks.
We will discuss candidate solutions as a class.
Applying the techniques you read about in Chapter 5 is a better way to learn their strengths and weaknesses than just staring at the pages. For example, a grammar for MVC developers probably isn't the most convenient tool for describing MVC systems. The important relations that exist in an MVC system seem to be more easily visualized than written in text. A transition diagram or state chart offer much more expressiveness. But the typical examples are low-loevel, and typically procedural.
Having a design tool like LabView for MVC seems to be a wonderful idea. Designers could create "pictures" of the models, views, controllers, and interactions and have a second pane show what the users would see. The tough part to implementing such a design tool is having provide useful feedback on the model, which lies underneath the surface of the user interface (the views).
What might an automated critic of MVC design say? What can it say, based only on code and design? Well, it could consider the relationship between views and models (does the model's interface support the designed views? what about potential views) and views and controllers (does the mode of interaction available to users match the way the view presents data?). We could also apply HCI principles to the views themselves and ADT/OO principles to the models themselves. Might a tool recognize an loop in the dependencies of views on models? Is that necessary?
One reason that this exercise is hard: it doesn't constrain you! Freedom can be daunting. But it also provides opportunities to try just about anything out, in the service of understanding the concepts being studied.
Another reason that this exercise is hard: you need to understand the material in Shneiderman's Chapter 5. Technical material can be daunting. But it also provides opportunities for you to explore those ideas, in a relatively forgiving environment...