There's not really a best solution, but there are a few ways that have proofen themself good. Very often people use some kind of a state machine, where a state could be the intro screen and nother the menu and another the game itself. But there are again thousands of diffrent ways to implement such states.
But there are then again way diffrent approaches to the task where you could implement some MVC framework.
Those questions are rather advanced which shows that you're on a good track to dig deeper into the C++/programming world.
Most of the time there's nothing wrong with implementing everything in the game loop, that's where the action happens. Another good practice is to keep the update (handling events, resetting positions, calculation collisions etc) seperated from the drawing. Other than that there aren't many other generic 'rules' for structuring a game. It's adviced to encapsulate as good as possible and work with easy/intuitive interfaces. How you do it varies widely from game to game and specially from the degree of complexity.
For a simple pong game (like the one that's included in the SFML examples) you don't need some big structures and you can more or less just implement things.
As for your code example, it doesn't make so much sense, because you can't react to events within the game class and your updates happen inbetween a 'draw' call (window.clear()
thus there's not seperation of the update and draw phase.
A few other details I'd point out is the naming of the header file. Programming in C++ it's better to use the *.hpp ending and keep the *.h ending for C code. In modern C++ you shouldn't work with raw pointers. For instance you don't even delete your allocated memory (that's what
new) does). You should use instead:
std::unique_ptr<Game> game( new Game( window ) );
And for the Game constructor you should take a reference of the render window instead of a pointer.
Game( sf::RenderWindow& window );
