The Model is the part of the MVC that specifies what are the rules of its application. I don’t know what kind of game you are playing, but in a typical game, it would be on Model that you would put things like players, scoring, mapping areas dominated by each player, board, enemies, spacecraft, submarines, dice numbers, playing cards or whatever is in your game. If the Model is empty and everything is in View and in the Controller, so you didn’t use real MVC.
In a correctly implemented MVC application, the View is interchangeable without changing the Model. For example, let’s assume that your game has an Android version, one for Swing and one with a frontend with Ajax + HTML5 and one using only command line with System.out.println. All these technologies have layers View well different, but if your project was done correctly as the MVC preaches, then these two statements should be true:
- The Model does not change at all when the technology of the View.
- All the rules that govern the game and model the concepts belonging to it are within the Model.
If one of the above two statements is false, then you did not follow the MVC standard, at least not correctly. In your case, I’m sure both statements are false in their entirety, and therefore your architecture is not MVC and you must have coupled concepts and rules of the game to concepts of View.
A simple example of MVC violation is this:
import javax.swing.JOptionPane;
public class Jogador {
// ...
}
The simple presence of import there is already a serious violation of the MVC, because the Jogador is something that should be on Model whereas JOptionPane is something that is inherent in View. Other violations would be these:
public class Tabuleiro {
private JPanel[] casas;
// ...
}
public class Jogador {
// ...
public void gameOver() {
System.out.println("Infelizmente o nosso herói se foi sem concluir a sua missão."
+ " Uma pena. GAME OVER!");
}
}
public class MonstroInimigo {
private int hp;
// ...
public void colocarDadosNaRequisicao(HttpServletRequest rq) {
rq.setAttribute("mostroHP", hp);
}
}
public class MesaDePoker extends Activity {
private List<Carta> baralho;
private List<Jogador> jogadores;
// ...
}
Note that in all these cases, when placing JButton within the Model, it gets stuck wearing a View based on Swing. When placing System.out.println, he gets stuck wearing a View console-based. When using HttpServletRequest, he gets stuck wearing a Controller and a View servlet-based. When using Activity, he gets stuck wearing a Controller and a View based on Android. In all of them, lose the feature of having a View interchangeable and thereby lose the MVC. In addition, Jogador, Tabuleiro, MonstroInimigo and MesaDePoker are things that shape the functioning and the rules of the game, and therefore should be in the Model, otherwise there will again be a violation of MVC.
EDITED:
Although your code is incomplete and uses several variables that you did not define in the code you presented, what you present clearly violates the MVC model. The modeling of the levels of your game should be within your Model, while things like buttons should be on View. The fact of the object tfo, whatever it is, have methods desaparecerFase1 and getBtVoltarTutorial highlights that concepts of Model were mixed with concepts of View in the same class.
When you create your project, you should create a set of classes that model your business rules without using any concept referring to the graphical interface, which would be the Model. Concepts such as clicks, screen taps and etc are also outside the Model.
Then, to make the graphical interface is that the View appears, responsible only for rendering on the screen (or in anything similar). In View is that you put Labels, buttons, menus and etc. However, you do not add the behaviors of these menus, Labels and buttons on View. This behavior stays in the Controller, which is also possible by translating the Model to the View and vice versa.
In fact, the fact that there are methods tfo.desaparecerFase1();, tfo.desaparecerFase1_1(), tfo.desaparecerFase1_2(), etc, is already a strong indication of a bad modeling and an inadequate orientation to objects. The right, in my view, would be you have an object of a class Fase (in his Model) and in it have methods aparecer() and desaparecer(). These methods of Model would then be used by Controller, that could maintain an instance variable of the type Fase. Similarly, the View should also have similar problems as evidenced by the presence of methods getBtJogarNovamente(), getBtJogarNovamente_1() and getBtJogarNovamente_2(). He should know what stage he’s at when he consults the Model, without the View or the Controller had to have specific methods for different stages of the game.
As for this comment:
This tfo.sumirFase1() is the following: it gives a setVisibleTrue in the view components (they are set in the view as false, when the control activates, it becomes true). That’s why I thought I had to stay inside the view, the control only activates these components. But the model I don’t really understand, I’ve read, I’ve reread on the subject, but I still can’t apply to my project
What happens is that you seem to have the view components of all phases simultaneously. That is, instead of loading a phase and creating the elements of its view and when it finishes destroying them, you are loading all the phases and placing all the elements of all the phases on the screen and giving setVisible(true) and setVisible(false) in them.
If you have an object Fase within your Model, this kind of thing will naturally end up stopping at some other place than View and Controller will know how to create the View looking at the Fase in the Model whatever.
Hard to say without knowing the whole context, but it probably did wrong, it seems like it didn’t need MVC. Most cases don’t have to, but people do anyway.
– Maniero
but what could I put in the Model? is a little game of matching the pairs of cards, these common ones, what should go in the Model?
– Gabriella
If you don’t have anything to put in, don’t put anything in. If you don’t need a model, you probably don’t need an MVC.
– Maniero
Got it. No model, no MVC! This?
– Gabriella
Not necessarily, but if it’s something simple, why use a complicated architecture?
– Maniero
in this case it was not even complicated... all buttons and so in the View and I treated the events in the Controller... but I did not find what to put in the Model, you think that without user interaction, it may still be that I have not put what should in the Model?
– Gabriella
This code you posted is too little to determine whether or not you needed Model.
– Victor Stafusa
put a little more!
– Gabriella
I edited my answer.
– Victor Stafusa