MVC Pattern

[bubbless]

Hi all.
I'm trying to understand the MVC pattern so I tried to rewrite a small application.
In my view, I have all the labels, textfields, buttons etc.
In my controller, I have the function ActionPerformed.
But what do I need to do with the model?
I've read alot tutorials about this and I think the controller must use actions from the model, is that correct?
What's the point of the model then, if you can put these functions in the controller?

Could someone help me out here?

[Fubarable]

In very small apps, there's not much point, but as apps get bigger, then it's good to separate the two to allow for easier debugging and upgrading.

[bubbless]

But wich funtions have to be in the model and wich ones in the controller?
Also, is a view allowed to have functions?
My view contains the visible components (trough the construcor) and 4 functions, reset, setValue, getInput and addActionListeners.

[paul pasciak]

I have read some claims that absolutely nothing but
"getters()" and "setters()" should be placed in the
model. The following examples run counter to this
belief.

I really like the second example (Fred Swartz's)
because it is the MVC pattern without using the
Observable.class, making it easier for a beginner
to follow.

Model-View-Controller Example Code
Fall 2002, David Matuszek
CIT597 MVC Example

Model-View-Controller (MVC) Structure
Copyleft 2004 Fred Swartz MIT License
Java: Model-View-Controller (MVC) Structure

[bubbless]

I already saw the second example and I used this to make my program.
I've taken a second look at it and I think I'm starting to understand it.

View
- labels, textfields, buttons, ...
- get and set methods

Model
- all kinds of methods

Controller
- gets the inputs with the get methods of the view
- uses the methods of the model to edit these inputs
- sets the outputs with the set methods of the view

Is this right?

[paul pasciak]

I will limit my comments to the "Model" part of MVC
because discussion of the "View" and "Control" can
get complicated.

First, consider creating a Model using only
getters() and setters(). You can't go wrong.
You will have created a perfect, portable
class.

The next methods to consider are mutators().
David Matuszek has no getters() or setters()
in his code. He has one mutator(), code that
directly effects the Model. Implementing all
kinds of methods in the Model is not endorsed.

According to one computer science professor
I watched on a C++ video tutorial:
"The decision of into which class you place a
method is not a trivial matter."

It seems to me that MVC provides a
structure that helps us to make some of
these decisions.

[bubbless]

Ok, but the way I see it (see previous post), is that correct?
Because you can also put the methods of the model in the controller, right?
And the getters and setters, aren't they in the view?

[paul pasciak]

getters and setters can be placed in the view,
however, technically I do not think they would
be called getters and setters. They would likely
be called something awkward like, "That code
that updates the data in object so-and-so.."

Regarding Fred Swartz's CalcView code, here is
some analysis of all its methods:

The following are not getters or setters.
They do not access the model.
They access the JTextFields within CalcView.

    void reset() {
        m_totalTf.setText(INITIAL_VALUE);
    }
    
    String getUserInput() {
        return m_userInputTf.getText();
    }
    
    void setTotal(String newTotal) {
        m_totalTf.setText(newTotal);
    }

The next three methods are not getters or setters either.
showError(String s) access one of JFrame's features.
addMultiplyListener(ActionListener mal) and
m_multiplyBtn.addActionListener(mal)
add ActionListeners to the JFrame's JButtons.

    void showError(String errMessage) {
        JOptionPane.showMessageDialog(this, errMessage);
    }
    
    void addMultiplyListener(ActionListener mal) {
        m_multiplyBtn.addActionListener(mal);
    }
    
    void addClearListener(ActionListener cal) {
        m_clearBtn.addActionListener(cal);
    }

Finally, within the constructor,

    m_model.setValue(INITIAL_VALUE);

is not a setter.
This line of code invokes a setter within the m_model called:

    public void setValue(String value)

To see the 'code', or 'implementation' of
this method, we go to the CalcModel.class and
dig through its methods:

public class CalcModel {
    //... Constants
    private static final String INITIAL_VALUE = "0";
    
    //... Member variable defining state of calculator.
    private BigInteger m_total;  // The total current value state.
    
    //======================================================= constructor
    /** Constructor */
    CalcModel() {
        reset();
    }
    
    //============================================================ reset
    /** Reset to initial value. */
    public void reset() {
        m_total = new BigInteger(INITIAL_VALUE);
    }
    
    //======================================================== multiplyBy
    /** Multiply current total by a number.
    *@param operand Number (as string) to multiply total by.
    */
    public void multiplyBy(String operand) {
        m_total = m_total.multiply(new BigInteger(operand));
    }
    
    //========================================================== setValue
    /** Set the total value. 
    *@param value New value that should be used for the calculator total. 
    */
    public void setValue(String value) {
        m_total = new BigInteger(value);
    }
    
    //========================================================== getValue
    /** Return current calculator total. */
    public String getValue() {
        return m_total.toString();
    }
}

Here we see nothing but methods that
alter or return the model's value
(including "public void setValue(String value)", invoked in CalcView).

[bubbless]

So the model doesn't acces the view's data?

Could you correct this "schedule" please?
I think it might be easier for me to understand.

View
- labels, textfields, buttons, ...
- get and set methods

Model
- all kinds of methods

Controller
- gets the inputs with the get methods of the view
- uses the methods of the model to edit these inputs
- sets the outputs with the set methods of the view

[paul pasciak]

I believe these fit the ‘ideal’ MVC standards:

The model never accesses anything outside of itself.
The model can be designed without any knowledge of
any of the other classes that use it.

Model
- getter and setter methods only

View
- Methods that render the data, or present it in a particular format.
- Status flags that indicate the user's dictates for display modes.
- Constructor initialization routines for labels, textfields, buttons, ...

Controller
- Recieves input from the user by way of listeners.
- Mutator methods to modify/edit the model's data while accessing it
exclusively throught the model's getters and setters.
- Updates flags in the view to indicate special display modes.

[bubbless]

Thank you, that's wat I was looking for.

The controller, does it recieve the inputs trough the get methods from the model?
And how can the model have get and set methods when you don't know anything about the view?

I'm sorry for all these questions but I really want to get it right.

[Fubarable]

(very long) example in other thread.

[paul pasciak]

The controller, does it recieve the inputs trough the get methods from the model?

This may or may not be true. The MVC pattern is a
perfect representation of a concept.

Upon implementation, the MVC pattern usually gets
altered to meet the progammer's goals.

For example, I am not happy with the model having only
getters and setters, so I choose to put mutators into
the model. Some projects may have many models, and the
programmer may choose to deal with them through
polymorphism. This effects the method distribution
within the MVC pattern.

Furthermore, when using Java's Observable class, The
model becomes very interactive and does 'transmit'
notifications to other objects in the MVC pattern.

You are not using the Observable class, so cast aside
any notion that your model does anything other than
act as an object that contains the model's data.

how can the model have get and set methods when you don't know anything about the view?

That's exactly why it has only get and set methods.
The model programmer does not care about the view, and
the view programmer doesn't care about the model.
The programmer creating the view wonders for a moment,
"What kind of data is contained in the model?"
He looks at the model's getter and sees,
"Oh! an int!" or
"Oh! an byte[]!" or
"Oh! a Vector!"..
and he proceeds to design the view to display that
type of data.

The setters are a little different. A model might
have many different setters:
setData() // default value
setData(byte b)
setData(int i)
setData(String s)
Which shall the control programmer use? Any one he
likes, or anyone or ones he is told to use.

The programmer who worked on the model is
responsible to see that all these methods
work properly within the model.