The actual application, the program you’re making, starts in main.cpp. You very well could have absolutely everything in that file. In fact, many moons ago, in the 70s and early 80’s, everything was in one file. Then people found that they couldn’t manage change well that way. Updates and maintainability, the ability to easily understand what a program does, was steadily eroded with that way of programming.
If you think of main.cpp as the scaffolding for your application, in the case of a console application anyway, then it starts to make more sense. The main.cpp file is just the frame of the car, to hold up the wheels, suspension, steering wheel, gas tank and the radio…oh yeah, seats might be nice. Wait, maybe a seatbelt? See what I’m doing? Each addition to the ‘car frame’ makes it more like a final product. You can think of BullCowGame.cpp as yet another component, another additional piece towards the final product.
If you get very finicky about what belongs where, with all these components, which you should, then BullCowGame.cpp should only have the parts and pieces to do exactly what it’s concerned about. The rules of the game ‘view’ (MVC). How the application uses those rules should not be in there. You may want to tell different types of users different things, or loop 50 times for a guess, so the way the ‘View’ & game rules work shouldn’t be affected by those things. Again think of ‘rules’ like how to play chess. If you make a chess game, the rules would exist in a class for the ChessGame.cpp. If you want a pink, and lavender chess board, or steel and copper chess board, or have a hillside scenery, or a 70’s speak-easy instead, none of that should affect the rules of the game. This is called separation of concerns.
I probably paraphrased too much or missed a few things there, but you can look up that breakdown of code in any software development guide book.
)