Question

I am just about done with our exam project, and when looking back at what I coded, I feel I did quite alright. Though, stuff could obviously always be alot better. But maybe that’s just me.

I was in charge of coding the GUI, and coupling it with the application logic. When making the GUI I made the decision that I would make a class file for every window (e.g. LoginWnd.java), and actually build the GUI in the constructor. I would initalize everything and set all data inside this constructor.

Then in order to navigate through the application, I would set actionlisteners on the jbutton. For example, in SearchWnd, hitting the “Search” jbutton would create a new object of ResultWnd with some specified parameters.

Now i’m kinda wondering: Was this design decision bad in any way? Are there any design paradigms that I should’ve been aware of?

Thanks.

Answer 1

Your approach sounds fine overall – as long as it works you’ve achieved the main goal! So my comments here are more about fine-tuning / broader design aspects.

There’s nothing fundamentally wrong with doing GUI construction in the constructor providing that the GUI doesn’t subsequently change during program execution. The rationale here is that constructors should be reserved for “one-off” construction activities. So it’s probably fine for dialog boxes and suchlike that have a pre-determined layout.

If you have a more dynamic GUI where components are frequently being added and removed throughout program execution, then I’d strongly suggest moving this to a set of methods outside the constructor so that they can be called independently of object construction. The constructor itself can still call these methods if needed to do initial setup, but subsequently you have the ability to call these methods later to add new components, refresh the layout etc.

The good news is that this stuff isn’t hard to refactor if you get it wrong – it’s usually trivial to pull setup code out of a constructor into separate methods later if needed.

Another thing to be aware of is the oft-repeated mantra “prefer composition to inheritance”. That is to say, if you can make your GUI work by assembling existing components rather than inheriting and overriding your design will probably be better/more easy to maintain in the long run. For example, I don’t think I’ve ever subclassed JFrame – it’s almost always cleaner to just add JPanels within it that contain all the application-specific components.

Finally, be cautious of coupling your GUI components too closely to your application logic. Swing actually does a pretty good job of encoraging you to separate out your data model from the presentation code (e.g. with ListModel and friends). It’s worth studying and understanding that approach. The point is that you should usually build GUI components in a way that is fairly application-agnostic, but give them application specific behaviour by connecting them to the right data model and event handlers etc.