Is this a good approach for using MVC for multiple views?

Question

I'm using MVC to organise an Maths Game application that has multiple classes that are the following:

• MathsGame.java: Main class. Currently holds CardLayout which screen classes are contained in and runs the application along with other controller-like actions.
• DiffScreen.java: Implements components and contains methods for use on the difficulty selection screen. Is extended from MigJPanel and is essentially a mix of a Model/View.
• GameScreen.java: Implements components and contains methods for use on the game screen. Is extended from MigJPanel and is essentially a mix of a Model/View.
• EndGameScreen.java: Implements components and contains methods for use on the end game screen. Is extended from MigJPanel and is essentially a mix of a Model/View.
• MigJPanel.java: Extends JPanel and sets layout to MigLayout and adds a matte border.
• ScreenInterface.java: Is implemented by DiffScreen, GameScreen, and EndGameScreen and contains final variables and an enum.

I've watched some tutorials and read up on MVC, but a lot of the resources I've found on it deal with very basic programs; having one model, one view, one controller, and a main class.

I have an idea of how I must go about refactoring my program to work with MVC, but I'm unsure about a couple of things.

1. Am I right in saying that from what classes I have above, I should split DiffScreen, GameScreen, and EndGameScreen into Model and View classes for each? Additionally, would it be better to create one Controller class or—as I've seen suggested—not bother and instead combine it with my Main MathsGame class? An approach I was suggested to use in a previous question here whereby I could implement a Controller interface seems useful too, but I'm not exactly sure if/how that would work with my new code.

2. Would it be helpful/needed for a project this small to split the Model, View, and Controller classes into their own sub-packages and keep MathsGame in the main package?

Further Clarification:

I'm essentially wondering if having these classes would be a good implementation of MVC:

• MathsGame.java: As a main class, or possibly being my controller. Could also possibly implement a controller interface as suggested in the linked answer above.
• These 3 possibly being inside their own sub-packages, let's say GamePackage.Views
  • DiffView.java
  • GameView.java
  • EndGameView.java
• These 3 possibly being inside their own sub-packages, let's say GamePackage.Model
  • DiffModel.java
  • GameModel.java
  • EndGameModel.java
• Controller.java: Won't be needed if MathsGame is both my main class and controller class. Could be in its own sub-package GamePackage.Controller if needed.
• MigJPanel.java
• ScreenInterface.java

Additional:

• I've looked up on Model-View-Presenter. It looks to be similar and better suited to whole applications. It seems these questions are valid for that too. If this would be more fitted to what I want to do, I would be okay with that too.

I'm hope I've explained myself well enough. It is for a college project but I missed a lot last year due to illness so I'm a bit confused on these aspects. If I can clarify any part better, please leave a comment. Thanks in advance for any suggestions!

Answer 1

1. MathsGame.java = your most bottom layer
2. Views: DiffView.java, GameView.java, EndGameView.java
3. Model: DiffModel.java, GameModel.java, EndGameModel.java
4. Controller: Controller.java (must)
5. MigJPanel.java = layer on top of MathsGame.java
6. ScreenInterface.java = Interface to connect between your MigJPanel.java with your MVC presentation layer.

Please remember to implement Single-Responsibility pattern, in that one class serves only for one purpose only. You cannot mix your main code with controller code. Confusing and not recommended.

Thank you,

Answer 2

I'm answering based on the assumption that your user interfaces(GameView, EndGameView) contain Swing components such as JTextPane, JTextField, JTable etc..

Do you need a separate model?

The Swing components have their own models. For example a JTable has a TableModel and a JComboBox will have its own ComboBoxModel.

So I would say that having your own models that you synchronize with the UI changes are not the best way to handle things. For example if you have a list of numbers in a JList, and the sum in JTextField in your GameView, having a GameViewModel that has int sum and List<Integer> numbers will duplicate things since the JList and JTextField already have their own models.

But if you are saving this data to some persistent storage (the database maybe) and fetching the data back to show on the user interface, then having a GameData object that has int sum and List<Integer> numbers will be useful for that purpose. But synchronizing that object with the changes that happen in the UI is still not appropriate. This object should only be filled when the user saves the data(clicks on the save button).

Do you need a separate controller?

Swing already has ways to communicate between user interface components and its model via *Listeners(ActionListener,ItemListener etc..). So I don't think that you need a separate class to communicate between the user interface and the UI other than a Listener that comes with Swing.

Should you put models/views and controllers in different packages?

No. Why? Classes that communicate with each other should be in the same package. So if you have GameView, GameModel and GameController they should be in the same package. DiffView, DiffModel and DiffController should be in the same package etc.. You shouldn't put GameView and DiffView in the same package because they are both views and all models in another package etc... If you do that you will have to make most methods public in order for GameModel and GameView to communicate whereas if you had those in the same package, you could have given them default access. Why is this useful? Because the users of your classes(people who will make changes in the future) will know which methods are meant for use outside the package and which methods are not.