|
Comp202: Principles of Object-Oriented Programming II
|
Quick links to supporting pages: Main page, BodyParts, Sounds, View & controller, WordList
The Model-view-Controller ("MVC") design pattern is one of the fundamental ways to architect a program that involves both user interfacing, a "view", and internal data processing, a "model". The MVC provides a technique with which to completely decouple the view and model, enabling easy interchange of either. That is, the way a model presents itself to the user can be changed without modifying the view itself. Or, the specific model used to process the user inputs can be changed without affecting the user.
The MVC pattern can also be used to connect various decoupled parts of the model together ("sub-models"). This is because any isolated (decoupled) portion of a program essentially considers the whole rest of the program it interacts with as its "view". The MVC pattern is very useful for arbitrating the dispatching of commands or signals from one part of a program to another.
Read about the MVC design pattern here.
The MVC is based on the idea that different parts of the design communicate by issuing "commands". In many programs, these commands are insituted simply as the act of calling method on another object. In OOP parlance this is often called "sending a message to" or "issuing a command to" the other object. More generally, however, a command is an abstract object (like what isn't?). This is often the case when the issuer of the command doesn't care who performs the command (the "receiver") -- only that the job gets done by someone. In such, the command is abstracted to an abstract class with an abstract "execute"-type method. The receiver is then handed a concrete instance of the command, on which the issuer calls the execute() method (or whatever it is called) when desired.
Read about the Command pattern here.
To connect the view to the model, and the sub-models together, the MVC utilized the concept of the "adapter". Since the model and the view are completely decoupled, they usually cannot be directly connected. That is, it would only be a lucky coincidence that the model could transmit information to its view by calling a method of the view. The model normally has no knowledge of the available methods of the view. So, an intermediary object, the "adapter", is needed. The job of the adapter is to translate the command executed by the issuer, into the appriopriate method call(s) of the view. In such, adapters can also serve as command dispatchers, sending the command out to multiple receipients.
Read about the Adapter pattern here.
Here is a little exercise with which to hone your MVC skills. This program will demonstate how the view of a model can be dynamically changed.
Place the exercise in a clearly marked directory (not cs151l01s1!).
Be sure that the package of all the classes involved are that of the exercise
directory. Reference the above (incomplete!) diagram in the instructions
below:
Some things to note about the exercise code:
Now you're ready to tackle the Hangman.
Last Revised Thursday, 03-Jun-2010 09:52:20 CDT
©2006 Stephen Wong and Dung Nguyen