Hi all

Is it possible to use only the classes you need in a panel or something? I'm finding it hard to explain my question, i'll give an example:
We need to make a program to organise swimming competitions. When you want to (as a user) edit or create a new event, the GUI needs to work with the Event class and it's related classes.
But when the user only wants to create or edit a swimming pool, the GUI only needs to work with the SwimmingPool class.

Is it possible, when you create panels for each action (like "creating an event", "editing a swimming pool"), to only include the classes you need for the action (for example, only the SwimmingPool class) in the JPanel, without having them all in the GUI class.

Thx in advance
Greets, Kenny.

PS: If it's not clear yet, please tell me

Dani AI

Generated

As asked, the goal is modular UI that only depends on the model classes needed for a particular task. That is the correct direction. Splitting the GUI into focused editor panels keeps dependencies small, makes testing easier, and avoids a monolithic "GUI" class — exactly the kind of separation hinted at.

Prefer a small interface for editors and constructor (or setter) injection of the model or service they operate on. This keeps panels independent of the rest of the application and makes them reusable and testable.

public interface EntityEditor<T> {
    void setModel(T model);
    T getModel();
}
public class SwimmingPoolEditorPanel extends JPanel implements EntityEditor<SwimmingPool> {
    public SwimmingPoolEditorPanel(SwimmingPool pool) { /* bind fields to pool */ }
    public void setModel(SwimmingPool pool) { /* update UI */ }
}

Use a layout that swaps whole panels rather than toggling lots of components. CardLayout is simple and fits many cases:

CardLayout cards = new CardLayout();
JPanel container = new JPanel(cards);
container.add(new EventEditorPanel(), "event");
container.add(new SwimmingPoolEditorPanel(), "pool");
cards.show(container, "pool");

Practical tips: keep business logic out of Swing components and run slow work off the EDT (SwingWorker). Remove listeners when panels are discarded to avoid leaks. Use dialogs for one-off edits and a controller layer to handle persistence and validation. If true runtime modularity (load/unload classes) is required, consider a modular classloader solution (OSGi), but for typical apps the per-panel, constructor-injected approach is sufficient. As noted, this pattern also makes it easier to learn and evolve the codebase.

Recommended Answers

All 4 Replies

Just create two separated classes that extends JPanel add necessary components as need it. Then display them depending on selected action in your JFrame.

Ok, thank you :)
I'll be trying that out ;)

Greets
Kenny

Great post dude, I can increase my knowledge.

Great post dude, I can increase my knowledge.

Now you either

  • Mocking the answer
  • You serious
  • You posting to just flash your signatures
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.