This is MVC.

[Brad Smith]

I have written a small MVC application (thanks to Andrew Monkhouse for his suggested modifications). This application does nothing more than enable the end user to enter a temperature in Fahrenheit or Celcius, and then outputs both types of temperature into output textboxes. This application is not directly related to the SCJD application, but the concepts can be used in the SCJD.
There are 3 source files (Model.java, View.java, Controller.java). Cut and paste them into your favourite editor, then compile, and run (Compile Model.java first, View.java second, Controller.java third, then run Controller.class).
Feel free to make any suggestions/comments/note other ways of implementing MVC...
-----------------------------------------------

  //Model.java
import java.util.*;
import javax.swing.*;
import javax.swing.event.*;
import java.util.*;
public class Model extends Observable{
  private double temperatureF = 50;
  public double getTemperatureF() {
    return temperatureF;
  }
  public double getTemperatureC() {
    return (temperatureF - 32.0) * 5.0 / 9.0;
  }
  public void setTemperatureF(double aTemperature) {
    temperatureF = aTemperature;
    setChanged();
    notifyObservers();
  }
  public void setTemperatureC(double aTemperature) {
    temperatureF = aTemperature*9.0/5.0 + 32.0;
    setChanged();
    notifyObservers();
  }
}

------------------------------------------------

  //View.java
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.util.*;
public class View implements Observer{
  private Model model;
  private JTextField inputFahrenheitText = new JTextField("");;
  private JTextField inputCelciusText = new JTextField("");;
  private JTextField outputFahrenheitText = new JTextField("");;
  private JTextField outputCelciusText = new JTextField("");;
  private JFrame frame;
  public void setInputFahrenheitListener(ActionListener al){
    inputFahrenheitText.addActionListener(al);
  }
  public void setInputCelciusListener(ActionListener al){
    inputCelciusText.addActionListener(al);
  }
  public View(Model model){
    this.model = model;
    frame = new JFrame("MVC Pattern Example");
    frame.setDefaultCloseOperation(frame.EXIT_ON_CLOSE);
    // create input field panel
    JPanel leftPanel = new JPanel();
    leftPanel.setBorder(BorderFactory.createCompoundBorder(
       BorderFactory.createLineBorder(Color.black),
       BorderFactory.createEmptyBorder(4,4,4,4)));
    leftPanel.setLayout(new GridLayout(3,2));
    leftPanel.add(new JLabel("Input Degrees : "));
    leftPanel.add(new JLabel(""));
    leftPanel.add(new JLabel("Fahrenheit"));
    inputFahrenheitText.setColumns(5);
    leftPanel.add(inputFahrenheitText);
    leftPanel.add(new JLabel("Celcius"));
    inputCelciusText.setColumns(5);
    leftPanel.add(inputCelciusText);
    // create output field panel
    JPanel rightPanel = new JPanel();
    rightPanel.setBorder(BorderFactory.createCompoundBorder(
       BorderFactory.createLineBorder(Color.black),
       BorderFactory.createEmptyBorder(4,4,4,4)));
    rightPanel.setLayout(new GridLayout(3,1));
    rightPanel.add(new JLabel("Current Temperature"));
    outputFahrenheitText.setColumns(7);
    rightPanel.add(outputFahrenheitText);
    outputCelciusText.setColumns(7);
    rightPanel.add(outputCelciusText);
    // add the panels to the frame and show it
    frame.getContentPane().setLayout(new BorderLayout());
    frame.getContentPane().add(leftPanel,BorderLayout.WEST);
    frame.getContentPane().add(rightPanel,BorderLayout.EAST);
    frame.pack();
    frame.setVisible(true);
    model.addObserver(this);
    model.setTemperatureF(model.getTemperatureF());  // display initial temp.
  }
  public double getFahrenheitInput(){
    double tempInput = Double.parseDouble(inputFahrenheitText.getText());
    inputFahrenheitText.setText("");
    return tempInput;
  }
  public double getCelciusInput(){
    double tempInput = Double.parseDouble(inputCelciusText.getText());
    inputCelciusText.setText("");
    return tempInput;
  }
  public void setCelciusOutput(double result){
    outputCelciusText.setText(""+result);
  }
  public void setFahrenheitOutput(double result){
    outputFahrenheitText.setText(""+result);
  }
  public void update(Observable t, Object o){
    setFahrenheitOutput(model().getTemperatureF());
    setCelciusOutput(model().getTemperatureC());
  }
  private Model model() {return model;}
}

------------------------------------------------

  //Controller.java
import java.awt.*;
import java.awt.event.*;
import java.util.*;
import javax.swing.*;
import javax.swing.event.*;
public class Controller{
  private static View view;
  private static Model model;
  public static void main(String[] args){
    // instantiate the model and view
    model = new Model();
    view = new View(model);
    // create and set the listeners to the view
    view.setInputFahrenheitListener(new ActionListener(){
      public void actionPerformed(ActionEvent e){
        double tempInput = view.getFahrenheitInput();
        model.setTemperatureF(tempInput);
    }});
    view.setInputCelciusListener(new ActionListener(){
      public void actionPerformed(ActionEvent e){
        double tempInput = view.getCelciusInput();
        model.setTemperatureC(tempInput);
    }});
  }
}

-----------------------------------------------
Brad Smith

[Max Habibi]

Nicely Done
M

[John Smith]

I have a few comments:

The use of Sun's java.util.Observable and java.util.Observer is certainly a valid option, but it's not without the drawbacks. Most notably, since java.util.Observable is a class and your Model must extend java.util.Observable, it fixes the position of your Model in the class hierarchy. That is, your model cannot extend any other class. Additionaly, the java.util.Observable-java.util.Observer pair is somewhat heavy and inflexible (since it is in the classes that you can't modify). For these reasons, some people prefer to create their own, custom version of Observer-Observable, which is a very straighworward thing to do.

In your code, the constructor for the View takes a reference to Model, which essentially couples the View with the Model and constitues a so called "pull" model. That is, the View quires the Model and pulls the data that it needs. Again, this is a valid option, but there is also an alternative. Instead of View pulling data from the Model, you can instead "push" it from the Model down to the registered Views. That way, your Views are completely decoupled from the Model and don't need to change when the Model code changes.

Good job with the View-Controller and the event listeners, -- everything is nicely encapsulated and coupling is minimized.

[Jim Yingst]

Cool, it's nice to have a short concrete example of this stuff to talk about. Good job.
A few comments:
I feel compelled to point out that it's "Celsius", not "Celcius".
Eclipse felt compelled to point out that you have a number of unused imports, especially in the Model. Also as a matter of style, frame.EXIT_ON_CLOSE should probably be JFrame.EXIT_ON_CLOSE so it looks less like an instance field.
On a more substantial note, I find I dislike seeing the controller code using ActionListener - that feels too closely tied to Swing/AWT. What If I want to change Controller to use an HTML-based view from a JSP instead? Or WML for a wireless app? These guys shouldn't have anything to do with ActionEvent, IMO. I'd prefer to have all the view's hook methods use a more generic interface, like Runnable. So my controller would say

        view.addInputCelsiusResponse(new Runnable() {
            public void run() {
                double tempInput = view.getCelsiusInput();
                model.setTemperatureC(tempInput);
            }
        });

and the code in View would be

    public void addInputCelsiusResponse(final Runnable response) {
        inputCelsiusText.addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent e) {
                response.run();
            }
        });
    }

What do folks here think of this approach? Good, or one level of abstraction too many?
Naturally Eugene's comments may be incorporated as well. Perhaps we could see several complete version of the code for this application, to more fully illustrate the different approaches preferred by Eugene, Mark S, etc.

[Brad Smith]

Thanks for the replies.

The use of Sun's java.util.Observable and java.util.Observer is certainly a valid option, but it's not without the drawbacks...

The reason I used Observer/Observable was to simplify my code (as suggested by Andrew Monkhouse). I realize that it may not work in every situation.

...you can instead "push" it from the Model down to the registered Views. That way, your Views are completely decoupled from the Model and don't need to change when the Model code changes

I realize that by having a reference to the model inside the view, that there is more coupling. However (as suggested by Andrew Monkhouse),"...if you decide to allow views to access static data in the model directly (such as your database schema for instance) then your view would need to have a reference to the model (or to an interface that the model implements)."

On a more substantial note, I find I dislike seeing the controller code using ActionListener - that feels too closely tied to Swing/AWT. What If I want to change Controller to use an HTML-based view from a JSP instead? Or WML for a wireless app? These guys shouldn't have anything to do with ActionEvent, IMO. I'd prefer to have all the view's hook methods use a more generic interface, like Runnable.

I believe that this is a judgement call, I would be interested to hear what other people would do in their SCJD project.

Brad Smith

[John Smith]

JY: I feel compelled to point out that it's "Celsius", not "Celcius".
It would be nice to have an Eclipse plug-in that would detect such a gruesome violation of the JLS.
JY: On a more substantial note, I find I dislike seeing the controller code using ActionListener - that feels too closely tied to Swing/AWT.
I didn't think there was a way to avoid it, but there is, indeed, looking at your sample code. Very nice.
BS (presumably quoting AM) : if you decide to allow views to access static data in the model directly (such as your database schema for instance) then your view would need to have a reference to the model (or to an interface that the model implements).
Not really. It doesn't matter if the data is static or not, -- you can push anything down to the views, in any form you want. The real disadvatage of the "push" is that there may be a more frequent and excessive amount of data transfer between the Model and the Views, whereas with the "pull", the Model just sends a ping and the Views retreive the needed data selectively, using the Model state quiry methods.

[Andrew Monkhouse]

Hi,
Good points by everybody.

Eugene: The use of Sun's java.util.Observable and java.util.Observer is certainly a valid option, but it's not without the drawbacks.

Agreed. But unless you are being affected by one of the drawbacks you mentioned earlier, then for the assignment I would recommend using Sun's provided classes. After all, we are recommended to use standard solutions where they exist.
In both this and the other MVC example Brad posted, the Model has not extended any other classes, so there is no problem extending Observable. I found that for my assignment, I did not need (or want) to have my model extend any other class either. My model had an instance of a class that implemented DatabaseInterface - my model was not a DatabaseInterface itself. To me this is logical, because the model "represents enterprise data and the business rules that govern access to and updates of this data" (from the Sun MVC blueprint). Therefore the Model may not necessarily just be a facade to the database, but may have totally different methods to those provided by the database, where these methods may indicate the business function (e.g. "bookFlight()") and/or have additional business rules behind the methods.

BS (presumably quoting AM) : if you decide to allow views to access static data in the model directly (such as your database schema for instance) then your view would need to have a reference to the model (or to an interface that the model implements).

Yep, that was me. What I was trying to suggest was a hybrid model that does both "push" and "pull". The model could push out any changes to the data being modeled, but views can also pull in any static data. The example I gave was pulling down the schema. You could push out the schema to all Observers, but this could be unnecessary overhead - the schema should not be changing in the middle of your application. So you could pull that down (possibly even in your constructor - so you would not need to keep a reference to your model later) but still get changes to the data pushed to you.

Jim: I feel compelled to point out that it's "Celsius", not "Celcius".
Eugene: It would be nice to have an Eclipse plug-in that would detect such a gruesome violation of the JLS.

Bwahahaha.
If we are going into spellings, can someone please change all the computer languages that spell Colour as Color? :roll:
Regards, Andrew