简体   繁体   中英

Java/Swing - how to reduce size of JDialog constructor?

I am building a graphical user interface in Java and I was wondering if anyone can give me some directions. Specifically, When clicking on a button in this GUI a big JDialog (it's a class that extends a JDialog) opens up for the user to enter some information, see some information, click on some things etc.

This class has multiple JLabels and other components in it. My question is how would one create such an instance? Right now I have everything in the constructor, making it a 500(!) lines constructor. There has to be an alternative to that! The constructor is about 300 lines of code of components placement and settings for them and another 200 lines for the listeners give or take.

Also another question that comes in mind is that right now I open this window from another class by calling

MyClassExtendsJDIalog temp = new MyClassExtendsJDIalog();

but I don't use this "temp" variable at all in the class that I create it, as the constructor of "temp" does EVERYTHING. It seems like I am, again, doing something the wrong way.

Thanks for reading this.

If you want split up the code to make it more readable and manageable you can allways group the fields into subclasses of JPanel, ie Panel1, Panel2 etc and then just add those in the JDialog subclass constructor. But setting up a GUI in swing takes a lot of lines, yes...

as for the temp variable not being used, I'm guessing you call show() in the constructor? Normally I would not do that, but instead call it in the code creating the dialog, ie.

MyDialog dialog = new MyDialog();
dialog.setVisible(true);

Without seeing your code it's difficult to give you specific tips on how to improve your code and design.

I agree, ~500 lines in your constructor intuitively feels like a problem. At a minimum, you might want to defer some of that work until after the instance has been created. Moving this into a init() method (or series of methods) is one approach.

You also might want to consider designing your class such that it contains a JDialog instead of extending one (See Composition over inheritance for a discussion on this topic) I suspect otherwise you are conflating the concerns of several classes.

Finally, you might want to review the Java Swing Tutorial for general tips and techniques for creating Swing based user interfaces.

Yes you are doing something wrong, but you are in good (or bad) company.

You should apply the rules of good OO design and clean code to your swing classes as to anything else.

What exactly you can do is hard to tell without looking at the 300+ lines of code (and I really don't want to see the ;-) but here are somethings that are probably applicable.

My main design rule is the Single Responsibilite Principle. According to your description (and my guesswork), you are doing the following in your constructor:

* creating (including configuring) components

* placing them in some kind of layout

* registering Listeners

* implementing Listners

These are 4 completely different concerns.

After some heavy refactoring you might end up with something like this:

You might want to have a factory that creates your components.

You might have a Layouter class that takes a component or a group of components (like label plus matching textbox) and places them on a panel.

You might have a class takes components (and maybe models or whatever) and wires them together using Listeners.

And a class that gets passed all this uses it in a suitable way and spits out a JDialog with the panel with all your components on.

Note: Idealy nothing extends JDialog anymore. You should only extend Janything if you intend to build a new Swing component.

This example is using Scala but it still should offer some inspiration: http://blog.schauderhaft.de/2011/06/26/clean-code-with-swing-and-scala/

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM