Java GUI Design - "Wasted" Inheritance?

Question

I am new to GUI design and am struggling a little to decide whether my intended use of inheritance is acceptable (I am familiar with the general concept of favouring composition).

For example, if I have a GUI that will feature 3 JToolBars (two toolbars at the top and a status bar at the bottom) as I see it I have 2 obvious options:

• Simply instantiate 3 JToolBars, add various components to them (buttons, etc), then add these to the parent panel. The code to do all this would probably be in the parent panel (i.e. a number of private methods).
• Create 3 new classes - UpperToolBar, LowerToolBar, StatusBar. Each would sub-class JToolBar and contain the necessary code to 'build themselves' (probably in private methods called from the constructor in each case).

My immediate preference is the 2nd option, simply in terms of encapsulation, modularity, etc. However, it sort of seems wrong to be sub-classing JToolBar but not actually adding any functionality? Is this acceptable or is there a better alternative.

Answer 1

It sounds like in the second option, you are creating a class where you really want an instance. In particular, I would say that if the custom code for a class such as UpperToolBar is only ever applicable to this one particular instance of a JToolBar, then there is no point in creating a new class.

On the other hand, if you intend to instantiate UpperToolBar many times, in different forms, then it could be appropriate to have a class (such that you did not need to keep rewriting the code that is specific to UpperToolBar).

Answer 2

Perhaps you want the third option of a Factory with methods to get an UpperToolBar that instantiates and configures a JToolBar for you.

Initially, you could use simple factory methods in the class that is going to make use of the JToolBars and call those methods to configure them to spec (this is similar to Option 1).

As your project grows and you want to reuse the UpperToolBar, LowerToolBar, and StatusBar instances that you are creating in your initial panel, you can refactor the tool bar creation out to a Factory class (Can be static or concrete factory depending on whether there is any configuration that would be common to types that would be created by the factory). Your GUI classes would each be able to make use of similarly spec'd UpperToolBar instances.

public class ToolBarFactory {
  public static JToolBar getUpperToolBar() {
    //create and configure a JToolBar to be used as an upper tool bar
  }

  public static JToolBar getLowerToolBar() {
    //create and configure a JToolBar to be used as a lower tool bar
  }

  public static JToolBar getStatusToolBar() {
    //create and configure a JToolBar to be used as a status tool bar
  }
}

Once you want to start customizing many different types of GUI components with variant instances, you can organize their configuration in a set of factory classes. e.g. ToolBarFactory, MenuFactory, ButtonFactory, etc. This would serve to break up the construction code rather than having it in only one place.

Answer 3

If your concern is by choosing option 1 you are writing lot of boiler plate code for toolbar creation then you can think of using "Factory method' pattern for creation of tool bars. In a situation some what similar to yours I had used the approach outlined in the article GoF Factory Method in writing GUIs which I found helpful.

Answer 4

Presuming that there will be some common design elements among your use of toolbars (e.g. they'll always have borders, or always have background images, or whatever), it might make sense to have a factory class for JToolBars. It would have common code, and specific methods for constructing the top left bar, the top right bar, and the bottom bar.

This would then be a pattern you could follow for other UI elements you want to re-use. A factory class for scrollbars, another for text boxes. That way, you have a place to store common code for any particular UI element, and a place to put a specific method to make a particular element for a particular context. If you find that text boxes and tool bars have something in common, you can then give them a common base class that encapsulates the sharing.