Code Structure Question

Hey guys,
Some background:
I just started to use unity and am trying to code a pool game. This is how I imagine it right now. It starts with a main menu that has different options like game mode. Depending on the game mode, the rules change of how to win. Functionally wise, I have a player in first person view that can walk up to the pool table. They can select which ball to hit and the camera switches to a shot came. In the shot mode, the player can pivot around the ball to determine the direction to hit the ball and the power to hit it with. After the shot is made, it switches to the first person view again.

The Question:
I am having trouble figuring out how to structure the code. I have written a script that selects the ball and a script that moves the player around. I'm not sure where to put the shot mode view scripts and where this would all tie into a game manager. How do I determine what classes there should be, and where do they belong?

My guess is have an empty gameObject with the Game Manager script attached. Then have the player movement attached to the player gameObject. Not sure what to do with the Ball Selecting script and the Shot mode script or if I should combine them all into the game manager.

 

There really is no right answer. Best practices dictate that you divorce the game from the presentation and the presentation from the player input. However, how can you (or anyone else here) know what that specifically entails?

Realistic practices dictate starting small, testing and discovering what Unity can do for you, and keep moving forward in small iterative steps until your game is done. When you detect an architecture pain point, decide how to address it and refactor accordingly.

 

These kind of questions can only be solved by experience, agreeing with @Kurt-Dekker , a big part of programming at the beginning is trial and error.
But to confirm your guess, yes it is a common thing to have some types of Game Managers scripts that don't necessarily have visual objects attached to them.
A nice trick is to have that object accessible through all objects(make a static definition for your game manager), so you can communicate with each other easily, having instances of the scene objects referenced in it, this way you can save time and processing instead of doing functions like Find, or defining redundant references.

More on that, in most cases, objects manipulation should be independent from managers, like movement of a ball should be in the ball itself and public methods to be called from other classes to interact with.

Also, in regards to code readability and re-usability, if you see yourself creating code that is too similar to another, don't hesitate to make it into a method, or even better in some cases a static method that can be used anywhere else. (like simple math functions, or type conversions.)