Results 1 to 8 of 8
  1. #1
    manji51 is offline Member
    Join Date
    May 2011
    Posts
    8
    Rep Power
    0

    Default 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.

    How complex is too complex for a single class?-panels.jpg

    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!

  2. #2
    Jodokus's Avatar
    Jodokus is offline Senior Member
    Join Date
    Jan 2011
    Location
    Amsterdam, the Netherlands
    Posts
    230
    Rep Power
    4

    Default

    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:
    Java 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
    Last edited by Jodokus; 07-06-2011 at 10:50 PM. Reason: spelling
    No bug ever had to calculate its fitnessfunction.

  3. #3
    manji51 is offline Member
    Join Date
    May 2011
    Posts
    8
    Rep Power
    0

    Default

    Beautiful! Thank you very much.

  4. #4
    Jodokus's Avatar
    Jodokus is offline Senior Member
    Join Date
    Jan 2011
    Location
    Amsterdam, the Netherlands
    Posts
    230
    Rep Power
    4

    Default

    You're welcome.
    No bug ever had to calculate its fitnessfunction.

  5. #5
    manji51 is offline Member
    Join Date
    May 2011
    Posts
    8
    Rep Power
    0

    Default

    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 View Post
    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:
    Java 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

  6. #6
    Jodokus's Avatar
    Jodokus is offline Senior Member
    Join Date
    Jan 2011
    Location
    Amsterdam, the Netherlands
    Posts
    230
    Rep Power
    4

    Default

    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.)
    Last edited by Jodokus; 07-08-2011 at 04:33 PM.
    No bug ever had to calculate its fitnessfunction.

  7. #7
    manji51 is offline Member
    Join Date
    May 2011
    Posts
    8
    Rep Power
    0

    Default

    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.

  8. #8
    Jodokus's Avatar
    Jodokus is offline Senior Member
    Join Date
    Jan 2011
    Location
    Amsterdam, the Netherlands
    Posts
    230
    Rep Power
    4

    Default

    Bingo.
    xyz (Message has to be 10 characters at least ;>)
    No bug ever had to calculate its fitnessfunction.

Similar Threads

  1. Complex GUI 60 JComboBox + 40+ JTextBox
    By Paul_White in forum New To Java
    Replies: 8
    Last Post: 05-12-2011, 08:51 PM
  2. Complex file input
    By JMaste in forum Advanced Java
    Replies: 4
    Last Post: 12-08-2010, 04:55 AM
  3. Replies: 7
    Last Post: 10-12-2010, 09:34 AM
  4. Creating a complex toolbar in SWT
    By Java Tip in forum SWT Tips
    Replies: 0
    Last Post: 07-02-2008, 09:09 PM
  5. Complex proximity Clauses
    By peiceonly in forum Lucene
    Replies: 1
    Last Post: 08-07-2007, 06:43 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •