If I am not mistaken, you are basically asking how to split up a game into the Model-View-Controller paradigm.
Simply put, the Model is the state of your game. In O-O terms, you can think of the Model as all of the objects in your game.
The Controller is the set of rules that are applied to your game's state (in this case, all of your game objects) in every update cycle. This can be implemented as a method called update() in all of your objects, or it can be a function called in your game loop that systematically goes through all the objects that need updated and, well, updates them. You can also think of the Controller as the game loop itself. It calls everything to update, and then draws it on the screen and repeats, unless some conditions are met, then it tells the program to do something else. In this way, you almost have two nested MVC structures. One controlling the flow of the program through menus and such, and one dedicated to the game itself.
The View is just the graphical representation of your game. This can be as simple as text on a screen, but in your case it is 2D graphics. To implement this, you could have each object also contain their graphical state, either directly, or by encapsulation. The View would do little more than query all of the objects for their graphical state, and then shunt it to the screen. Again, this can be implemented on a per-object basis, such as a method called draw(), or another systematic function to be called directly from the game loop. A common practice is to create an object called 'Sptite' or something similar to hold the graphical information, and have every game object that is drawn have a personal instance. Also note that the View need not be an object unto itself. A mere function called in a game loop will suffice, although it is sometimes necessary to store information that directly effects the View's operation (like window size), in which case the View can be an object. The same goes for the Controller.
Also keep in mind that these divisions can be sectioned up even further to make life simpler. For example: The Controller can be divided up into AI processing, movements updating, and collision checking. The View could be separated into the game object display and the HUD, and the Model can be all the objects + all the state independent of the game objects (like the games settings for resolution, window size, key config and such).
I know this might be a little overkill, and it probably has extra information, but hopefully it answers your question and gives you ideas on where to start.
