Gui Guidance
So in my earliest days of programming I have had many programs with guis. These GUI classes eventually develop into code monstrosities, when compared to my other classes. I'm told that I should step away from using the GUI class to do things like interpret my programs "state" and hold other computational instructions. Instead, simply use it to record all of the settings for my radio buttons, check boxes, text fields etc.
Can anyone tell me why this is a good idea. .. or if its not .. why its a bad one... general design comments are welcome
I ask because my task now is to structure my gui in such a way that it can be controlled by inputs other than the users mouse and keyboard. I would like to have scripts be read which contain and manipulate these settings. Additionally, (and WAY further down the road) I am going to have it be set via a clent program running on across our network. Therefore, I am trying to "modulate" (i guess) the manipulation of the gui components.
thanks for the feedback
PS. also anything for / against multiple listeners of the same type on a gui component? if so what should I watch out for?
I think most of us can agree that code should be flexible and reusable in general. Reusable to me means that the code should be able to be "plugged in" or reused in any context that meets the original design intent. Flexible to me means that the code should be able to be extended to meet new requirements that extend the functionality of the original code without having to rewrite the functionality that hasn't changed. In order to achieve this the code must be modular. If the code is broken into the smallest module necessary to achieve a requirement then that code can be reused any place that requirement is necessary. However, if that code is not modular and all of the code to meet a hundred different requirements is in the same module then it can not be reused to meet only one of those requirements. I may have worded that poorly or misused terminology, but hopefully the point I'm getting at is still decipherable.
Apply that to your question. Does the program's state and logic have anything to do with the GUI itself? It's just a facade on top of the business logic. What happens when you want to change that facade? What happens when you want to change the business logic? If they're interconnected and tightly coupled then you have to change both. If they're loosely coupled then you only have to change one or at the worst have to make minor changes in one to accomodate the other. So keep the one out of the other and insert a controller in between them to deal with translating between the two foreigners and you won't have to do so much work when something needs to change.
Do a Google on "Model View Controller", you'll find a lot better information that I could ever give you.
Ok heres the thing about flexable and reusable. I am the only software developer in a startup company of three people. Thus, as long as my program works, I can get away with writing sloppy code, "brand X" documentation and code lines stretching WAY beyond 80 characters in length. (That was a requirement for readability for me at school).
Anyway, I have always seen the need for a good design. A good established software architecture is always in place before I write any code.
In my GUI I have about 30 or so "bare" gui components. They are partitioned and grouped togeather into smaller classes. Each class holds the "buisness logic" related to the settings of the gui components they control. (I hope that made sense ... heres an example)
<start example>
Like 2 JLabels -> "From" and "To"
and two JComboBoxes -> both holding years as strings -> 1996, 1997, ...2006
Therefore I have grouped these four element into a "Timer" class which will encapsulate the information held by the selections of the two combo boxes.
<end example>
Anyway I asked about Listeners in the prievious post because they act on a single radio button / check box / text area or other gui component, not on my encapsulating classes...
Thus my specific question is, can I add some sort of listener to the encapsulating class instead of just the simple "bare" gui components they manage.
Does this make sense? ...
Thanks
