Hmmm if I was making a 2D platformer with traps I would...
Have the GameStates.
I would probably have a class for terrain and either have it able to be all types of terrain (via passing variables) or have classes that extend it to the various types of terrain.
If you are loading maps from a file, I would have a class for that.
I would have at least one class for enemies and I probably would extend it for each type of enemy.
I would probably have the AI in the enemy classes themselves. Unless you want the enemy's to act together, in which case I would have a master control AI that would give orders to each of the individuals.
General rendering order.
1. Render background
2. Render terrain.
3. Go through the enemy's and render them.
4. Render the player.
5. Render foreground elements of the terrain.
6. Render the user interface (Health, HUD, etc)
You're gamestate should contain the input code. You'll be detecting input events there anyway for the gui elements, so you might as well have it all there and pass commands to the other classes (like the player, enemies, bullets, etc)
General rules of thumb:
If it is only 1 method or only a couple paragraphs long that's used only in that class... you don't need a separate class to hold it.
If it is something you reuse everywhere... then you might want the code in one spot to make reusing it and debugging it easier. It will reduce the chances of bugs as well.
You might consider shunting code into a new class if a class is getting very large and hard to read.
Stuff in a class should be related and make sense that they should be together.Comment
, Comment, Comment you're code. You might not remember what a particular method does when you go back and try to debug some code you haven't looked at in a month. So remember to Comment it! /** **/ is your friend.
<- This is an awesome tool that catches some bugs before you run the code. Easy to install if you use eclipse, though you will have to enable it to run automatically for each project.