I'm writing a project to be graded, and one of the important parts of this project is good code structure. Good encapsulation, loose coupling, and all that. However, I have a problem when it comes to my GUI.
My program uses standard UI-model separation, and all the GUI classes are in their own package. I decided to implement my GUI actions by subclassing Swing's AbstractAction, so that I can use the same action in tooblars and menus if I like. My program is not complicated enough for a controller, so the actionPerformed method in each of these AbstractAction subclasses does all the work associated with that action. As of now, these AbstractAction subclasses are inner classes within my main GUI class.
This GUI file is getting outrageously long, and it is the only class in its package. The action classes could stand on their own, but I would have to open up my GUI's private component instance variables to package access. As a result, only classes within the package would be able to use these variables, but they would be opened up nonetheless.
<b>Bottom line: is it better design to keep all these AbstractAction subclasses within my GUI class as one enormous file, or should I make them separate classes and give my instance variables package access?</b>
Without having seen the code, I'd suspect that I'd break up the code differently - one big "gui class" sounds suspcicious to me. What does the GUI do? Can you break it down into subpanels that you could put into their own classes?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I didn't post any code because it is indeed long. My GUI class contains private references to a JFrame and all the components that it displays, which includes subpanels, a scroll pane, a toolbar, etc. The class constructor (with helper methods) initializes all these components and properly assembles them into my main window. During this initialization step, each of the Action classes is instantiated and associated with a toolbar item. Since the tasks of each of the Action classes affect elements of the GUI (e.g., opening a file displays a report in the scroll pane), I made them inner classes so they have direct access to all the component references. My initial question was whether it would be a bad idea to make these Action classes normal (non-inner) classes, and instead give the instance variables of the GUI class default (package) access so the Action classes could still function as they do now.
I definitely understand how this might sound suspicious as you say, and since I don't have much experience in this area, I'd REALLY like to hear more design ideas. I want to do this well, it's really an experience issue.