Comp 212 Lab 09: Koch Curves MVC

Introduction

This tutorial will lead you through the process of putting together an MVC design for the Koch Curves programming project #2.  Your labbies will help divide the lab class into three groups:

• One group will work together to design and implement the model.  
• One group will work together to design and implement the view.
• One group will work together to design and implement the controller.

Here is roughly how you should budget the lab time to carry out the design process.

• 15 minutes: to start, the three groups will have to meet and nail down the interfaces for the adapters.  You are strongly encouraged to reuse the MVC design ideas in the Hangman project.   Once the adapter interfaces are agreed upon, each group should go to work on its own component.
  • A crucial question to ask is "what is the minimum amount of communication needed between the model and the view that will enable each side to do its task?"
  • Another question to ask is "how should the communications between the model and the view be grouped together?" Maximum flexibility is achieved by minimal grouping, so you only want to group together commands that you feel are intrinsically related.
  • Be very careful about designing at too low an abstraction level. For instance, when designing the adapters that the view will use, consider only the needs of the view, not what the model has to offer. The requirements of the view in terms of what it needs to communicate with are independent of the capabilities of the model. It is the controller's job to provide the appropriate concrete adapter that will translate the requirements of the view into the services provided by the model.
• 45 minutes: each group works to design and implement its component.  You should fill out the stub code with code that does some kind of work.  An simple approach would be to have a bunch of System.out.println("blah blah blah..") to see some output showing that something is happening.
• 30 minutes: the three groups get back together and try to assemble the components of the GUI program.  You will probably discover a few things do not quite fit and should try to iron out the kinks.

The labbies will help manage the time, facilitate the discussion, and serve as consultants. In the end, the whole lab class should come up with an appropriate MVC design for the Koch GUI application and a (perhaps partial) implementation of each of the components of the MVC design.   You can use your lab work to complete milestone 2  for programming project #2.  

Code sharing is allowed between members of the same lab section only.  Suggestion: one member of each group should make a publicly readable directory where shared code is placed. Be sure to tell your lab partners where that directory can be found!

Koch Curve View

It is perhaps more convenient to look at the view first.  From the demo applet, we see that the view frame has the following required GUI components.

1. What it looks like.
   • A "Grow" button to grow the currently displayed Koch curve.
   • A "Reset" button to make one Koch curve in its initial state, using the currently selected Koch curve factory.  Read the semantic for the Reset button again; it's important.
   • A combo box to select a concrete Koch curve factory.
   • A JPanel to graphically display the current Koch curve.
2. What it behaves like.
   • the grow button should register an action listener to respond to the click by telling the current Koch curve in the model to grow, and then tell the view to repaint.  But since it does not know anything about the model, it can only tell some appropriate adapter interface to grow.
   • the reset button should register an action listener to tell the model to make one a Koch curve in its initial state using the currently selected factory.  But since it does not know anything about the model, it can only tell some appropriate adapter interface to make one Koch curve and set the current Koch curve to that one just created.
   • the combo box should register an action listener to tell the model to set current factory to the one whose class name has just been selected .  But since it does not know anything about the model, it can only tell some appropriate adapter interface to set the current Koch curve factory to the one whose class name has just been selected.
   • the JPanel should be able to repaint itself and display the current Koch curve in the model.  But since it does not know anything about the model, it can only tell some appropriate adapter interface to paint the current Koch.  Here it may help to take another look at  the view for the simple GUI application provided in lecture 17 to jump start the Hangman GUI
3. How it is created and initialized.
   • It is the controller that creates the view and pass to it appropriate concrete adapters at construction time.  These adapters are created by the controller as well.  The controller design is discussed in a latter section.

Koch Curve Model

It is important to recognize that the model for the Koch curve GUI application is not simply the Koch curve class and its abstract factory designed in milestone 1.  To have a working  the model for the Koch GUI application, we will need to write the code for the Koch curve class and at least  four concrete Koch curve factories as shown in the demo and put them together in such a way that they can work together and carry out the task required by the GUI application.   Assuming you have written such code, the Koch curve model for the required application have the following properties and behaviors.

1. What it looks like- The model for the Koch GUI application maintains
   • a current Koch curve object
   • a fixed pair of end points (Point2D.Double or Point, depending on how you implemented your Koch Curve) defining the current Koch curve.
   • a current abstract Koch curve factory reference which is initialized to some concrete factory object. (Does that reference always remain to the same concrete object or does it change?)
2. What it behaves like
   • it knows how to make one Koch curve using the currently selected Koch curve factory and set it as the current Koch curve.
   • it knows how to grow the current Koch curve using the currently selected Koch curve factory.
   • it knows how to paint the current Koch curve on a given Graphics object.
   • it knows how to dynamically load a Koch curve factory class given a class name.  The code for dynamic class loading is given in the Dynamic Class Loading section of the Hints page.
3. How it is created and initialized.
   • It is the controller that creates the model.  When the model comes into existence, it initializes its Koch end points to some fixed values, its current Koch factory to a default factory,  and its current Koch curve to the one manufactured by the current factory using the fixed end points.

Koch Curve Controller

The Koch controller instantiates the model and the view, and set up the "wiring" between the two using appropriate adapter.

1. What it looks like - The controller maintains
   • a Koch model object
   • a Koch view object
2. What it behaves like.
   • it has no behavior! (Except perhaps to create the rest of the system.)
3. How is it created and initialized.
   • when it comes into existence (or when commanded to do such), it instantiates a Koch model and a Koch view passing to this view the appropriate adapters that it creates itself.  These adapters are best created as anonymous inner classes!