Java Swing architecture problem?

Question

Till now, I have developed simple swing applications so there was no need to break the GUI code into diff. classes but as this application is going to be very large, I decided to break the code into diff. classes so as to make the code more manageable.

But before proceeding, I have some doubts in my mind which are as follows:

Brief description of GUI

It will have a main JFrame (MainFrame). On that a JPanel(MainJPanel) is set whose layout is to be CardLayout. It will contain 25 cards (each card is in the form of JPanel which contains its own swing components).

Q1. I have decided to make 25 classes (each for one JPanel card). Is it correct approach?

Q2. If the above answer is correct, then how can I write code of xxxxActionPerformed() methods of buttons which are on those cards (25 cards) as these methods need access to the object of MainJPanel

e.g.

public void buttonActionPerformed(ActionEvent evt) {
    java.awt.CardLayout c = (java.awt.CardLayout) mainJPanel.getLayout();
    c.show(mainJPanel, "card1");  // card1 is this card
    mainJPanel.updateUI();
}

I googled for swing examples but almost all of them shows the use of diff. swing components. Can you also please suggest me a link that shows some swing examples that contain GUI codes in diff. classes.

Answer 1

I would say you are correct in creating a class for each card. This is a logical way to split up the code.

If you need to reference the MainJPanel then simply pass it into the constructor of each card class and keep a reference to it.

Answer 2

Q1) That sounds like quite a lot of classes. While it's possible that each class has distinct functionality I find it more likely that you could combine some of those into more common classes. For example instead of YellowCard and BlueCard you could simply have ColorCard where color is a parameter.

Q2) Model View Presenter (MVP) and Model View Controller (MVC) are two (or one, depending on your view) common design patterns which help design GUIs so that everyone has the data they need.

More specifically, you might not need all cards to have a reference to the parent panel. For example, if you have a BurgerPanel which allows the user to order burgers and a StatusPanel which shows how many burgers have been ordered you can communicate between them as follows...

Create a StoreStatus object and pass it to both BurgerPanel and StatusPanel. When the user orders a burger with burger panel it updates the store status. The store status notifies the StatusPanel of this update via the observer pattern and then the StatusPanel reflects the change.

UPDATE: In regards to your specific example you would either some kind of reference to the parent class or you could notify it of updates with the observer patterns. (The advantage of the observer pattern is that any changes to the parent class couldn't create changes in the child classes.)