How complex is too complex for a single class?

I am creating a GUI that, as currently built, has a wonderful hierarchy of panels for different groups of components. I have all of these panels in their own classes. Every time I look at my collection of code files, I can't help but feel that I've horribly complicated matters and have gone way overboard in creating classes for panels, instead of, for example, building the entire frame's contents in a single class.

Attached is an image of my frame, with all of the panels bordered in red. I'm counting five panels.

Attachment 1645

My question to the forums: When should a panel be in its own class and when should it be built within the class building its parent? Should I have created this frame in two classes: the JFrame class and the JPanel class, or is it right to have a million classes for all the panels that are used?

I have spent hours searching the Google to find some consensus on how to handle container hierarchies, building strategies, using nested classes, subclassing, etc., for some idea of how I should be organizing the code for building this frame. Separate classes feel more modular, but it feels almost like semantics to build panels as individual units when they will only ever be used in a specific configuration? Subclassing feels misplaced, though it does lay out things nicely in Eclipse's outline panel. I'm dying for advice that actually sounds like it fits my situation!

Quote:

---

or is it right to have a million classes for all the panels that are used?

---

No. Normally you nest methods, not classes. Only when things are getting too complicated, or panels too much an entity on their own, you split off a class (mostly extending JPanel).
I do it like this:

Code:

---

        public CalculatorGui( boolean applet ) {//constructor
                cubeController = new CubeController( this );
                isApplet = applet;
                setLayout(new BorderLayout() );
              setBorder(BorderFactory.createLineBorder(Color.black));
                add( createCalculationPanels(), BorderLayout.CENTER );
            }
        private JPanel createCalculationPanels(){
                JPanel panel = new JPanel();
                panel.setLayout(new FlowLayout() );
                panel.add( createMatrixPanel() );
                panel.add( createResultsPanel() );
                panel.add( createDashboardPanel() );
                panel.add( createGraphicsPanel() );
                return panel;
        }
        private JPanel createDashboardPanel(){
                JPanel panel = new JPanel();
                panel.setLayout(new BorderLayout() );
                panel.add( createButtonsPanel(), BorderLayout.NORTH );
                panel.add( createStateMsgPanel(), BorderLayout.CENTER );
                panel.add( createSettingsPanel(), BorderLayout.SOUTH );
                return panel;
        }
        //...and so on

---

Beautiful! Thank you very much.

You're welcome.

Sorry, I have an additional question. In the class building the panel (though your example is with an applet, I'm looking at it from the viewpoint of building a panel that you're adding to a JFrame's contentPane), where are the field variables placed? I'm assuming they'll all be placed at the top of the class.

I ask this because I started off including the sub-panels at the top of the class and realized I was making my build methods return values that existed as private variables. This does feel that it cleans up some logical questions (e.g. you don't have to worry that a sub-panel is being built before it's added, if you only add it when it's returned from its building method). I've never run into this situation before, so I wanted to make sure it wouldn't be looked at as wholly unorthodox.

Thanks again for your help!

Quote:

---

Originally Posted by Jodokus

No. Normally you nest methods, not classes. Only when things are getting too complicated, or panels too much an entity on their own, you split off a class (mostly extending JPanel).
I do it like this:

Code:

---

        public CalculatorGui( boolean applet ) {//constructor
                cubeController = new CubeController( this );
                isApplet = applet;
                setLayout(new BorderLayout() );
              setBorder(BorderFactory.createLineBorder(Color.black));
                add( createCalculationPanels(), BorderLayout.CENTER );
            }
        private JPanel createCalculationPanels(){
                JPanel panel = new JPanel();
                panel.setLayout(new FlowLayout() );
                panel.add( createMatrixPanel() );
                panel.add( createResultsPanel() );
                panel.add( createDashboardPanel() );
                panel.add( createGraphicsPanel() );
                return panel;
        }
        private JPanel createDashboardPanel(){
                JPanel panel = new JPanel();
                panel.setLayout(new BorderLayout() );
                panel.add( createButtonsPanel(), BorderLayout.NORTH );
                panel.add( createStateMsgPanel(), BorderLayout.CENTER );
                panel.add( createSettingsPanel(), BorderLayout.SOUTH );
                return panel;
        }
        //...and so on

---

---

I'm not sure I fully understand you (if not, send a SSCCE=small self contained compiling example, which shows your way of tackling it).
The flields are in the top of the class (just a convention, it doesn't really matter).
But I don't make fields or variables for every JPanel I use, only if I need references to it in the rest of the class(es). Only buttons, textFields etc. need a global declaration because you are referring to them in your code, but the panels are not relevant as such in most cases and are just anonymus panels.

(I get the feeling that you think that everything needs a field or variable not to get garbagecollected. But in this case you create a tree with a CalculatorGui instance as root, where each parent holds the references of its children. If you say panel.add(someOtherPanel), panel holds a reference to the added panel, which doesn't need its own instanceVariable (also not much more then a named reference) not to be carbagecollected.)

My example by the way isn't an applet perse, the GUI (extending JPanel) gets told by the constructor if the program is run as an application or as an applet (in an applet it isn't showing menuitems for saving and opening files for instance.)

Thank you again. You understood my question perfectly and answered it admirably. My takeaways:

1. Only create variables for fields that will need to be referenced later
2. There is usually no need to create variables for panels, since they're rather set and forget, and can be referenced through their parent.

This allows your construction methods to be very encapsulated, since it has the built-in control of being the only way to get the panel added to its parent, meaning you can't inadvertently add the panel before its time.

Bingo.
xyz (Message has to be 10 characters at least ;>)