Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

 The caller of such a method need only to simply delegate to the returned value by having the returned value accept the proper visitor.   Suppose the method my3OutcomeMethod} has three possible outcomes, so it returns an {{IUtilHostABC object.    All we need to do is to delegate to the returned value of the method:

...

 A discussion of the details and implications of the Model-View-Controller Design Pattern  are beyond the scope of this class, so here is but a brief overview:


 The The point of the MVC is to separate how a program looks to the user from what it does.   In the above UML diagram, you can see that we have two separate packages:  edu.rice.comp211.gui and edu.rice.model that hold the "view" and "model" components respectively.

The view, GameFrame communicates with the rest of the system via its IModelAdapter which is also in the gui package.   The ICellView is used to communicate to the view, and so, it is also in the gui package.  The gui package does not define what the IModelAdapter does!    But the GUIFrame does not know this--so far as it can tell, it's entire world is defined by the gui package because there are no references to anything outside of the package.      .

Likewise, the model, GameModel communicates with the outside world via its IViewAdapter.   The model does use the code in the data and util} packages, but only to define data structures and provide utility capabilities.   All communications to the view take place through the {{IViewAdapter which is in the model pacakge.  Like the view, the model code has no idea what the implementation of IViewAdapter is.

The view and model packages are thus completely isolated and independent from each other.   The job of the Controller class in the edu.rice.comp211.controller package is to assemble the complete, operational application by joining the view and model together.   It does so by creating implementations of both IModelAdapter and IViewAdapter that pass their method calls onto the GameFrame and GameModel respectively.   This may involve simply passing the call along to the appropriate method on the receiver, for instance, IModelAdapter.solve() is implemented to simply call GameModel.solve().   But other methods may require more extensive translation, for instance, IviewAdapter.setCellViews() is implemented to take a Vector<ICellSet> object, convert it into a 2-dimensional array of ICelllViews and then make the call to GameFrame.addCells().   

Thus, the Controller is the class that contains the main() method that starts the application.   The constructor of Controller instantiates the model, GameModel, the view, GameFrame, and the adapters that communicate between them, IViewAdapter and IModelAdapter.    The method Controller.start() is then called to actually start the application.

The Controller is the only class that knows which view and which model are used for any given application. 

Key Methods of GameFrame

  • initGUI - intializes the GUI components.
  • addCells - displays the given cells on the screen.   Used to update the view with the latest state of the board.
  • showMessage - a utility method to display the given string as a pop-up dialog box.

Puzzle Generation Utilities

...