Rob Brew wrote:
But if you can't think of good reason not to, The ControlClass and the Model can be instantiated in the StockCheckGUI constructor (like JTable and TableModel) and you have better encapsulation with all the benefits.
Would you instantiate each separately within the GUI or pass the controller class to the model?
The answer to most questions like this is "it depends".
If the situation is as simple as your example:
then I would put the "new Model()" in the ControlClass constructor and the "new ControlClass()" in the StockCheckGUI constructor.
But that assumes that StockCheckGUI always takes the same ControlClass which always takes the same Model. I'm going to go far out on a limb and assume from "StockCheck" that this is some sort of database controlled inventory system. And that the Model is somehow related to which table in the database or which subset of the table is being presented in the GUI.
Even in that case I see a slight advantage to creating the Model and ControlClass inside the StockCheckGUI and passing the GUI constructor some kind of specifier like column value in the database.
In general I like to keep my GUI as separate and sparse from program logic as possible. I've run into the situation where too much logic is scattered throughout event processors like button pushes or entry field focus lost events. Then I find I need to add a different user interface but want to keep the program function. Just for example if this were an Inventory Control program and you write it for a workstation with the idea people come in with all the info on forms in a clipboard. Now someone has the brilliant idea of using an iPad or an Android Tablet while they're walking through the warehouse. How much code can you reuse to translate your GUI classes into mobile friendly web pages?
I've become a real fan of refactoring especially with the tools NetBeans provides to help. The concept is to write code as quickly and conceptually simple as possible. The go over and over it to make it more robust, maintainable and clean from a design stand point. There's a lot of advantages to this. The biggest one is we get out of the mindset that once we write code we should carve it in stone to allow future generations to bask in our brilliance.
Another is a working prototype is much more understandable to end users, management and even other software designers that written specifications. I find I can usually produce a skeleton UI with some basic functionality as fast I can describe in enough detail what I want to do. I can get lots of people to download a jar file and try it but I can't get anyone to read the spec let alone understand it and provide constructive criticism. That's not to say I don't write development plans and architectural designs, it's just they they describe things at a higher level than what one set of screens is supposed to do.
So try it one way, once it works, look and see if you think of advantages to doing the other way (that make it worth changing). When you start making changes it becomes obvious where the real problems are. If you change something in one Class the fewer things that impacts the better. How much duplicate code do you have? Does this thing really need to depend on that thing? And so on.
Once you see how the Classes interact in the prototype don't be afraid to throw away everything you don't like and redo it. That possibility is why you want to get the prototype to people who will use it with a minimum of effort.
Sorry for going so far off on a tangent. I hope a little of that addresses your question.
Joe