I handle it similarly as OniLink10: I've got an abstract base class Surface.
class Surface
{
public:
virtual void Run();
};
Then, there are multiple classes which inherit from Surface, such as MainMenu, OptionMenu, Game, Editor. They implement the Run() method. The class Game is the essential one for gameplay: It stores several game-related states, such as player or enemy data (for example in an STL container) or what game mode has been chosen. Additionally, it contains methods to handle input, compute the game logics and draw the results on the screen. For that functionality, there's in each case an own, specific class, the Game class just delegates the work to them. For example, a GraphicManager class which is responsible of drawing the objects.
An important part is to widely separate graphics and logics. Ideally, the game class shouldn't know anything about SFML. Same applies to the logic objects like Player and Enemy. They don't need to know themselves how they are drawn, that's the task of another class.
By the way, there's no need for the "C" prefix at classes. This is an artifact of the Hungarian Notation, which intends to specifiy identifiers by their types. In C++, however, this concept can't be satisfied consequently. Regarding templates and different class types (class, struct, union), when shall there be a "C" and when not? Should typedefs on classes get a prefix, too? If you say no, why not? They can be used like the class itsself, so there's no reason to distinguish. And when you suddenly change the typedef to a non-class-type? Remove the "C" and refactor all dependent code?
Originally, MFC programmers used the "C" prefix to avoid ambiguous names. In C, you don't have namespaces, so you have to think of something else. Prefixes are standing to reason, for example OpenGL uses "gl" as prefix. In C++, this problem isn't relevant any more, either. To sum up, I've made the experience that the possibility to clarify types is a) mostly unnecessary (especially when you choose good identifiers) and b) can sometimes be an unjustified obstacle regarding flexibility and consistence.
