Design Pattern for GUI implementation

[ravindra janapreddy]

I have been following the various posting on this subject on this forum. Everyone has been talking about implementing using MVC architecture, Mediator Pattern, Observer Pattern etc.
I have tried to study each of these patterns and postings on this forum and tried to study the best way to implement the GUI.
The MVC architecture ( Model-View-Controller ) whereby the data are represented by the Model and the View by the visual component. The
Controller is the communication between the Model and View objects and may be a seperate class or may be inherent in either the Model or the View. This is the case for the JFC components, which are all examples of the Observer pattern. ------ James W. Cooper Java Design Patterns
The MVC architecture / Observer pattern is used to present different forms of the same data.
Using this pattern , We can treat the Search Criteria and Book Flight as "subject" and JTable as "observer". Thus, We can have different
views i.e JTable depending on the changes in the data objects "Search Criteria" and "Book Flight".
When a program consists of a number of isolated classes, the logic and computation is divided among these classes. Mediator pattern
promotes looser coupling between these classes. It accomplishes this by being the only class that has the detailed knowledge of the other classes. Classes inform the Mediator when changes occur, and the Mediator then passes them on to any other classes that need to be informed. ------ James W. Cooper Java Design Patterns
Using this pattern, We can treat Search Criteria, JTable & Book Flight as isolated classes and develop a FBNMediator class which has the knowledge of each of these classes and communicate the changes from the Search Criteria and Book Flight class to JTable class.
Please study this and let me know your comments.
Thanks
Ravindra

[John Smith]

You sound a bit confused. What's actually confusing is that if you really want to use MVC for this assignment, then you will have two models. One model is just for the JTable, and the other model is for the application level. But in fact, there is only one model (application level) that holds a reference to submodel (table model).
To simplify things a bit, think of a model as a class that holds all the values that are currently displayed in all the GUI controls of your application. These values collectively represent the "state" of your application. Why have a model if visual controls already represent the application state? Well, with the model, your application state and the business rules can be completely independent of the GUI. Furthermore,
your can change the rules without affecting the GUI, and you can replace or add new views (GUI screens) without affecting the business rules. This is developer dream! Things are not very rosy, however. If your model changes as a result of some operation (performed by controller), you may need to reflect the new application state in the views (GUI screens).
This is where the Observable/Observer thing come into the play. All the views that are registered with the model "observe" it. When the critical change is triggered in the model (by controller), the model announces to observers that it has changed (by calling the setChanged() and notifyObservers() methods).

You certainly don't have to implement any of these for this assignment. The much simpler way would be to have the controller or the GUI to take the Model responsibilities. Your controller, for example, may keep a reference to GUI, and if they are in the same package, the controller can request the values from the "package-private" declared GUI fields (this is how Mark did it, I think). Or, you may define public methods in GUI to return the values of the neccessary fields to controller (this is how Sai did it, I think). However, the complete MVC approach is much superior, I believe.
Eugene Kononov.