1

I have an application that is a Maths Game for kids. Since I'm in college, I've usually only had a god object for all my past projects but for this applciation I've split my code into multiple classes:

  • MathsGame.java: main class which initialises components and constructs and controls the UI.
  • DiffScreen.java: contains methods for use on the difficulty selection screen.
  • GameScreen.java: contains methods for use on the game screen.
  • EndGameScreen.java: contains methods for use on the end game screen.
  • MigJPanel.java: extends JPanel and sets layout to MigLayout and adds a matte border.

Each screen that the 3 XScreen classes control is simply an instance of MigJPanel and screens are switched to using a CardPanel container JPanel.

I'm wondering how I can divide my code to each class so that they are properly abstracted but I'm not entirely sure how to approach this.

  1. Should my 3 screen classes be extending from my MigJPanel so these then can be instantiated?

    So instead of having my DiffScreen, GameScreen, and EndGameScreen classes solely containing methods related to each screen which are then called from MathsGame, each screen will control itself within its own class.

  2. If yes to the previous question, should the UI components for each screen be made inside that screen's class?

    At the moment, all components for each of the three screens are created in my MathsGame constructor. This makes the connection between a screen and the class which 'controls' (I use this word very lightly at the moment) it even further apart. So each screen is just an instance of MigJPanel whose components are constructed in MathsGame. The only relation the EndGameScreen class—for example—has to the End Game screen is that when the MathsGame causes the End Game Screen to be displayed, anything done there makes a method in EndGameScreen be called from MathsGame.

I hope I explained myself well. If not, leave a comment and I'll clarify. Any help would be greatly appreciated!

DagdA
  • 484
  • 1
  • 7
  • 25
  • 2
    1- Yes, 2- Yes. Focus on self containment and maintain areas of responsibility. It is the responsibility of each UI screen to manage it's content, no one else, in fact, you should guard against allowing unrestricted modification to these components and provide access only through managed methods indirect (setters and getters), which allow the modification of the properties you want to be changed, and not simply providing the component via a getter, this prevents problems with people removing components you don't want removed... – MadProgrammer Dec 18 '14 at 21:09
  • 1
    You could also use interfaces to maintain common functionality if required, so if the `MathsGame` really only wants to deal with a certain amount of the information/functionality, you can use an interface that all the other screens use which will simplify the process, as the `MathsGame` only needs to know about the class that implement the interface and not EVERY thing else that might be going on...as a suggestion... – MadProgrammer Dec 18 '14 at 21:11
  • @MadProgrammer That helps greatly, thanks! Would you like to put that as an answer so I can accept it? Also, where should I put the code for switching between screens? I'm getting an error on my `ActionListener`s in each of the screen classes for putting `MathsGame.switchToGame(btgrpDiff.getSelection())` as that method is non-static, but I can't make it static as it's performing `show()` for my `CardLayout` which is created in my `MathsGame` class. I'm assuming I should have 3 methods for switching between classes, but where should I put them and my `CardLayout`? – DagdA Dec 18 '14 at 23:01

1 Answers1

2
  1. Yes
  2. Yes.

Focus on self containment and maintain areas of responsibility. It is the responsibility of each UI screen to manage it's content, no one else, in fact, you should guard against allowing unrestricted modification to these components and provide access only through managed methods indirectly (setters and getters), which allow the modification of the properties you want to be changed, and not simply providing the component via a getter, this prevents problems with people removing components you don't want removed, for example.

You could also use interfaces to maintain common functionality if required, so if the MathsGame really only wants to deal with a certain amount of the information/functionality, you can use an interface that all the other screens use which will simplify the process, as the MathsGame only needs to know about the class that implement the interface and not EVERY thing else that might be going on...as a suggestion..

Also, where should I put the code for switching between screens?

From my perspective, it's the responsibility of the MathsGame game to determine when and to which screen should be shown. What I would normally do, is provide some kind of notification process that the current screen can ask the MathsGame to switch screens, maybe via a listener or other agreeded interface. This would mean that each screen would need reference to MathsGame.

Instead of passing it (MathsGame) directly, I'd create an interface that MathsGame would implement (say NavigationController), which defined the calls/contract that each sub screen could use (nextScreen/previousScreen) for example.

Take a look at Model-View-Controller for more ideas

MadProgrammer
  • 343,457
  • 22
  • 230
  • 366