Game game? This is so confusing.

I know what is being done in the program, but I didn't understand why, what's the purpose. I have spent two days already trying to understand this by googling, but nothing helped.

I want to know Why Private Game game is created, what's the purpose of it. I know Game game = new Game(), its meaning and purposes. But I don't understand what's the purpose of private Game game. I have gone through explanation of all heap and stack memory, instance and reference variable. But nothing has helped me with this. Life has stopped at this.

OK. I'll try to explain the logic behind it, if anything is confusing tell me and I'll try to explain it better.

You create a Prompter class in the video. The job of the prompter is to read the input of the user, and give output to the user (print in the console), so that the user can play the game. Right?

The Game class that you created earlier contains the game logic itself: What is the answer, what happens when you guess wrong, what happens when you guess right, and so on.

So in order to allow the user to play, the prompter needs to read user input, pass that input to a Game object, then print the result for the user. That means the prompter needs to have a Game object. The prompter can then use the methods of the Game object to find out what it should tell the user.

So with 'private Game game', we create a private variable of type 'Game' called 'game' inside the Prompter class. Then we add a constructor with a parameter of type Game, so we can set the value of the private 'game' variable when a prompter object is created.

In order to have a usable prompter, you need first to create a Game object, and then pass that object to the prompter when you create it. Now the prompter object will have a reference to that game object. It will be able to use that game object and its methods. So for example, when the user enters an answer, the prompter can use the game object to find out if the answer is correct or not. Then it can print the result in the console, so the user knows if they were right or wrong.

//We create a game
Game game = new Game(); 
//We create a prompter with a reference to that game we just created
//We can do that because the Prompter class has a variable of type Game
Prompter prompter = new Prompter(game); 

Yeah, that's it, except I wouldn't say "to enforce MVC". There are lots of reasons to do it this way that have nothing to do with the MVC pattern. Basically you don't want a class to have too many jobs, it's called the Single Responsibility Principle. The Prompter's job is to manage the input and output. It's not to instantiate a Game object. If the Prompter also needs to instantiate a Game object, it has two jobs. Suddenly it might have to know about things that have nothing to do with input and output: how to create a Game objects? What parameters are needed? And so on.

For now creating a Game object is not so much work and it might seem convenient to create it directly inside the Prompter class. But later maybe I want to add new features and change the Game class: now it needs a new parameter. If the Prompter creates the Game object, then I also need to change the Prompter class. More things get added to the Prompter class that have nothing to do with prompting. Several years later, nobody knows what is happening in there any more unless they spent hours going through the code.

That's why we like to keep things nice and separate. A lot of code design is about keeping your code easy to change and to maintain, because software is never finished. It changes constantly. When a software is no longer updated it usually means nobody uses it anymore.

These are pretty advanced concepts though! It will only really start making sense when you have more and more projects and experience behind you.

Totally agree with Quinn - the word "game" is used so many times in this exercise between the three files that it becomes hard to understand the flow properly. Livia's explanation definitely helps to visualize the different parts and how they fit together.