This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have started researching the topics that I need to know for the SCJD. I have done a lot of research on MVC and swing, and I think I understand it, but I am not sure (Yes I have checked out the previous postings on this topic in this forum, and suggested readings in the postings). I have written a small application that I believe is MVC compatible. It just displays a frame with 2 input TextBoxes, and 2 output TextBoxes (one each for Fahrenheit, and Celcius). The end user just enters a value in one of the input TextBoxes, hits [Enter], then the output TextBoxes have the appropriate values displayed. This application isn't directly related to the SCJD, and doesn't use JTable, although the MVC concepts involved are highlighted. The application has the following 3 source files :
The questions I have are : 1) Is this MVC ? 2) Should the controller be less dependant than it is on the View (if so how would you do it) ? 3) How would you improve on it ? Thanks for any suggestions.
[code tags inserted by Jim] [ July 15, 2003: Message edited by: Jim Yingst ]
Hi Brad, Welcome to JavaRanch. When you post code, please put it into UBB code blocks. That way your formatting will be preserved. You may want to look at the Observer interface and the Observable class. Using them will allow you to remove some code from your model. In the view you provided, you may want to use the setDefaultCloseOperation() method of JFrame rather than creating a windowListener. This may be different in the assignment though. The only thing that I would change in your MVC is that the view itself can receive notification of changes to the model. The changes do not have to be sent from the model to the controller and then to the view. Regards, Andrew
Thanks for the suggestions, Andrew. Isn't the placement of the ChangeListeners in the View a judgement call (some of the samples of MVC I have seen include it in the view, some include it in the controller) ? What is the advantage of placing the ChangeListeners in the View (If you do place the ChangeListeners in the View, you need a reference to the Model inside the View, in order to add the ChangeListener to the Model's list of ChangeListeners) ? Thanks for any suggestions. Brad Smith
author and jackaroo
Isn't the placement of the ChangeListeners in the View a judgement call (some of the samples of MVC I have seen include it in the view, some include it in the controller) ?
I have also seen examples where the programmer has not had any link between the model and the view. However whenever I have found documentation describing the concept of MVC, it invariably states that there is a link between the model and the view. The "Design Patterns" book (GOF) describes the link as: "MVC decouples views and models by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever the model's data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. This approach lets you attach multiple views to a model to provide different presentations. You can also create new views for a model without rewriting it.". The Sun MVC Blueprint shows that the model "Notifies views of changes", and describes two ways this can be achieved: "This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data". There is an analogy of MVC in a book I am reading at present (which I won't name because I cannot recommend it). The analogy is that the MVC is "like an Automobile. The speed of the car is affected by the accelerator pedal (Controller), the speed is shown by the speedometer (View) and the speed is manifested by the engines (Model).". If you think about it like that, the change in speed is not passed from the accelerator (controller) to the spedometer (view).
What is the advantage of placing the ChangeListeners in the View
Turn the question around: what is the advantage of having changes go through the controller? There may be times when you can find a reason for doing that, but normally you would not. The controller is only concerned with handling actions and events. It normally doesn't have to do anything with the data itself. Normally all the work on the data is performed by the model. All the work displaying the data is done by the view. It makes sense for the model to automatically notify views if the data they are meant to be displaying has changed. By the way: a model may have more than one controller and view attached to it. So something action performed in "view A" may change the data currently being modeled, which would have to be updated in "view B". The model is going to need some way of notifying affected classes that the data has changed. So you are going to have to register classes that are interested in observing changes with the model. Since you have to register anyway, why not have the view doing the registration?
(If you do place the ChangeListeners in the View, you need a reference to the Model inside the View, in order to add the ChangeListener to the Model's list of ChangeListeners) ?
Again: look at the Observer interface and the Observable class. If the view implements Observer, then the controller can create an instance of the view, then register that instance with the model's Observable methods. (This is using push model). The view itself does not need to have any knowledge of the model at all - it is simply receiving data through it's update() method. Of course, if you decide to use the pull method, or 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). Regards, Andrew