1

I'm making a customer administration software. There are several JPanels with much content on it, constantly communicating with a database. In the database is customer data, products etc.
For a faster access to the database data, at first I load it all in its own ArrayList, e.g. ArrayList<Customer>. If the user changes this data, it has to be changed in both the class and the database.
As the JPanel View looks very "full" (crammed with other JPanels and JTabbedPanes, switching through with the CardLayout), I thought it would be better to create an own class for every "main" JPanel and link them all with View.
For example an own class for the JPanel Customer, where all the customer data can be seen and edited, the same for products etc.

Does is make sense or is it inconvinient? I only want to do so to outsource the code and to make the classes clearer, especially View.
Is there something like a design pattern dealing with this problem?

chubbsondubs
  • 37,646
  • 24
  • 106
  • 138
Evgenij Reznik
  • 17,916
  • 39
  • 104
  • 181
  • Are you looking for ORM (Object Relational Mapping) ? – SALMAN Apr 06 '12 at 20:30
  • How convenient or inconvenient it is can be easily found out by doing it. Then you can compare how easy it is to find or change things in the two sets of code. My educated guess is that you'll find the decomposed code many times easier to read and maintain. – biziclop Apr 06 '12 at 20:47

2 Answers2

6

So your program consists of a single class that subclasses JPanel and that contains references to all other components used in your UI? And you want to know if you should break out portions of that UI into other classes.

In short YES. You can always decompose any class into aggregated classes by moving portions of that code out into a new class, and have the original class contain a reference to the new class. This is called delegation or Extract Class refactor. You can read about this technique in Martin Fowler's Refactoring book.

Creating other UIs that are parts of the total UI, like CustomerPanel, is a good way to think about it. By doing this you can also decouple parts of your UI. Be careful when you create these smaller classes to move all dependencies to the new class. If you feel like passing a reference back to the main UI to the aggregated class then you probably haven't fully decoupled your classes. That should be a sign either you haven't given enough responsibility to the class you are extracting, or there is some other dependency they should be sharing.

Basically the rule is if you extract a class, it shouldn't have a reference back to the class that contains it. References should be more of a tree than a graph. It's ok for them to share a model class, but its not ok to create cycles between views.

You probably would find this interesting: GUI guidelines for swing

Community
  • 1
  • 1
chubbsondubs
  • 37,646
  • 24
  • 106
  • 138
  • Very well written. Thanks and 1+. – Hovercraft Full Of Eels Apr 06 '12 at 20:43
  • I'm curious about one statement in your guidelines post linked to above. You state to never use `SwingUtilities.invokeAndWait()`, however I've read that this should be used when starting up GUI code in the init method of a JApplet as noted [here](http://docs.oracle.com/javase/tutorial/uiswing/components/applet.html). – Hovercraft Full Of Eels Apr 06 '12 at 20:56
  • @HovercraftFullOfEels They're two different use cases. In the applet guide they say the reason you should use it, but only from the lifecycle methods, is that these methods are invoked by the applet container itself and not by the event dispatcher thread. However during the normal operation of your Swing app (or applet), you will only ever have to react to events coming in that thread. Essentially the applet case is a workaround for the deficiencies of the applet container. – biziclop Apr 06 '12 at 21:05
  • 1
    @HovercraftFullOfEels good question. There are use cases where invokeAndWait() is needed, but they are often corner cases like the one you point out. UI dev like Swing requires you become comfortable with giving up absolute control over timing of things. This is uncomfortable for new developers that believe rigid control over when things happen is key which means invokeAndWait() gets used when it shouldn't. That's really the intent of my advice. – chubbsondubs Apr 07 '12 at 23:53
1

I am not sure if I understood your intent, but looks like you want to achieve the level of decomposition which will allow you to outsource certain UI components and reuse them, well, basically achieve as lower coupling as possible. Apart from what @chubbard said, I would suggest you to look into MVP pattern and use event-based interaction between components rather than referencing them. This can eliminate unwanted dependencies and bring more reusability.

ahanin
  • 892
  • 4
  • 8