Home/ Questions/Q 7750407
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T11:17:03+00:00

I’m making a customer administration software. There are several JPanels with much content on

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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

    • 0