Comp202: Principles of Object-Oriented Programming II
Fall 2006 -- The Model-View-Controller Design Pattern   


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.

 

A MVC Exercise  (Highly recommended, but not required)

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:

  1. Using StructureBuilder, create a "model" class that has a method that takes a String as an input and calls an abstract command object's show() command that takes a String as input.   The abstract command class is described below.   The method of the model should do something creative with the String and then output the result through the abstract command. 
  2. The model should have a "setCommand()" accessor method for the abstract command.
  3. Create the abstract command class.
  4. Create at least three concrete command classes:  one that puts the String on a JLabel, one that appends the String to the text in a JTextArea and one that does both (do this with no duplicated code! ).
  5. Create a new JBuilder project with a JFrame.
  6. Put a JTexField, a JLabel, a JTextArea, and three radio buttons on the JFrame.  Don't forget the ButtonGroup.   Add whatever JPanels, etc needed to make the program look and act nicely.
  7. The actionPerformed of the JTextField should call the input method of the model using the text of the textfield.    Convince yourself that this constitutes a direct connection between the model and the view.
  8. The radio buttons should switch the command (adapter) used by the model to show its output to the JLabel or to the JTextArea or to both.  
  9. Consider very carefully which object should instantiate the model and the commands and what parameters should be passed to their constructors.    Especially be careful about what the combination command takes as constructor parameters.

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