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 a couple questions regarding the best class seperation approach for the swing classes.
In Max's book he basically has one monolithic file that contains all JDialog, ActionListener classes and that allows the action listeners to access member variables of the individual dialogs as well as serve as a central file for accessing the controller.
I like it is the respect that this is the only class which accesses the controller but I don't like that all the gui classes are within it.
What I have done is to put all my Dialogs into seperate classes. The basic flow of my application is wizard like in that you basically flow from one dialog to the other. Now if I don't mind having all the dialogs access the controller from their own inner class actionlisteners then there is no problem but if I would like to have a central class where all the controller calls are done then I need to be able to send back all required variables. I have several ideas on how to do this but I am really just experimenting right now and any insights would be appreciated.
Anyone have opinions on the best approach for the gui architecture? I have read the java swing tutorials, max's book and the definitive guide for swing 2e but none of them really talk about this aspect very much.
I have heard of and seen very different solutions to this part of the project that all got 95 % and more of the maximum points in the OO-section. Strict MVC, less strict MVC, no MVC at all ... it is all ok as long as you justify your decision in your choices.txt and as long as it reflects general OO principles.
It is in the nature of the assignment that certain parts of the model will be strictly seperated, e. g. the suncertify.db.Data. One decision you have to make is wether the GUI related classes talk to this model directly from the same classes that are responsible for the GUI or if you use some kind of front controller as a model to which the GUI classes refer. The latter would typically consist of one or more classes that reference - or are - swing model classes of type Document, TableModel or something like that. I recommend that for a project of that size, but that is just personal preference. It will not affect your score.
In a very small project, JChecksum (feel free to have a look at the source code), I decided to use the former approach, though: I have a dedicated model that has nothing to do with the GUI. The classes that are responsible for the view also hold the temporary state that later is passed to the model when the model is needed. Thus I directly set and get the data from a JTextField rather than doing that in a seperate class that references the Document of that JTextField. This is NOT MVC. (The controller is virtually entirely seperated, though, mostly having the form of classes that implement Action.)
I would not do that in a project of the size of the SCJD assignment. In my SCJD project I made a strict MVC separation. Some classes were dedicated part of the model anyway, e. g. Data, and the temporary state as entered through and reflected by the GUI (search results in the TableModel, the Documents holding the company name and location, ...) was maintained by some kind of front controller which for example had references to my TableModel implementation and to the Documents for the search criteria JTextFields. With 24 / 40 points in the GUI section I made one of the worst GUIs reported at the JavaRanch results forum in 2004, but in all other parts, including OOD, I got 100 %, thus 96 % total. (Undeserved though; imo they are not strict enough in some sections. I had an experienced software engineer review my SCJD project later and he found several major problems in my design.)
Most people get a very high score in the OOD-section, so don't worry too much about it. Take a reasonable approach you feel comfortable with.