MVC Variations Confusing Me

Question

I've read this in one article:
# a model consisting of the application with no external interface;
# a view consisting of one or more graphical frames that interact with the user and the application; and
# a controller consisting of the ``main'' program that constructs the model and the view and links them together.Additionally,
When a program with a graphical interface starts, the controller
   1. creates the model (application),
   2. creates the view consisting of one or more graphical frames and attaches commands to the graphical input controls (buttons, text boxes, etc.) of the view,
   3. activates the graphical components in the view, and
   4. terminates.Here's what I understand: anything that can be seen or has a graphical component is automatically a view. This includes Swing, AWT, even a JFrame with all the buttons and stuff in it. I've also read somewhere that Views can opt to register to a Model to automatically update itself when the Model changes, but that the Controller would handle the registration process. Models only store state, or data. They DO NOT have to do any special formatting or know how to present themselves. They don't know about any Views. Controllers contain the application-specific logic. They just tie the two together then terminate. They don't have a user interface. Hence, the following code...
class Model
     // misc. code.
     private String name;
     public void setName(String name)
          this.name = name;
     public String getName()
          return name;
class Controller
     // misc. code.
     private Model model;
     private View view;
     public Controller()
          model = new Model();
          model.setName("I am Sam");
          view = new View();
          view.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
          view.addOkButtonListener(new ActionListener()
               public void actionPerformed(ActionEvent e)
                    view.setNameTextFieldText(model.getName());
     public static void main(String[] args)
          new Controller();
class View extends JFrame
     // misc. code.
     private JButton okButton;
     private JTextField nameTextField;
     public void addOkButtonListener(ActionListener l)
          okButton.addActionListener(l);
     public void removeOkButtonListener(ActionListener l)
          okButton.removeActionListener(l);
     public void setNameTextFieldText(String text)
          nameTextField.setText(text);
}is an example of MVC, or at least that is my understanding of it. I was just beginning to appreciate the above pattern when all of a sudden, I encounter this(http://www.cs.tufts.edu/~jacob/106/lecture/25_MVC.html), again putting me in a state of confusion.
If I stick to the definition of a controller given earlier in this post, I would say that the second example's controller is...."wrong". The Controller class has a view of its own. Additionally, the Controller uses a common callback for handling button events. I've read in the same article that this is bad design. The author presents some reasons, but in short, a common callback could turn into one long MONSTER IF statement mayhem.
Since the focus of MVC is on improved object reuse, model and view objects should be loosely coupled. Controller objects get reused the least. In the second example, all Views have a Model object inside of them, lessening their reusability. If in the first example, the Controller object acts as the glue that magically binds the model and view objects together, in the second example, glue is all over the place.
In the first example, if one removes the Controller class, the Model and View objects remain intact. If the Model is removed, the Controller is surely affected but the View still remains intact. We can even change the Model's API, and all that would need to be changed is the Controller.
In the second example, if one removes the Model object, the Controller and View objects are compromised. If we completely change the Model's API, the Controller and View objects would need to be changed too.
The second example has gotten me so confused I feel I need to ask these questions:
1.) Why does the second example maintain a tight coupling between the Model and the View?
2.) Why does the Controller have it's own View?
3.) Does the second example have any strengths over the first example? Or does the first example have any weaknesses too? In short, what can the first example do that the other can't and vice versa?
3.) In what types of problems is one more suitable than the other?
4.) Which is better in the long run or in larger projects (in terms of modularity, ease of coding, maintainability, etc.)?
I really need to clear this up. :)

Answer 1

MVC is a great design goal, but more often than not, you end up with model-delegate. The delegate contains controller and view, more tightly coupled than one would like in full-blown MVC.
You should avoid coupling the model and view in any way. If you have to, write the controller closely coupled to the view, and then have the controller invoke model classes. That way, you can at least keep your domain model classes if you ever switch views or add a view.
Conceptually:
View - Displays the model to the user
Model - Application data and business objects
Controller - Parses user requests and mediates between view and model
You can also check out the following URL that may explain the concepts differently (and better) than I could:
http://java.sun.com/blueprints/patterns/MVC-detailed.html
It's very difficult to totally separate the view and controller. The closest I've ever come is to implement the Command pattern and then use dynamic method invocation.
- Saish
"My karma ran over your dogma." - Anon