Beginning Windows® Phone 7 Application Development: Building Windows® Phone Applications Using Silverlight® and XNA®

SIMPLIFYING YOUR CODE WITH GAME COMPONENTS

So far, you've written all your code in one file, the Game subclass. You've not done anything too complicated, but you can see how your Update() and Draw() methods get longer every time you add a feature to your game. You're going to be writing a lot more code soon, and you wouldn't be following good object-oriented design principles if you just kept tacking code onto the same method.

One of the tenets of object-oriented programming is modularity. The concept of modularity involves separating concerns into distinct areas, as well as formalizing interfaces (that is, how one module is allowed to interact with another). Normally, when two classes interact with one another through just the public methods, fields, and properties, there is a high degree of modularity. This is achieved because each class is hiding relatively numerous and complex methods and fields with the private keyword, publishing (through the public keyword) only what other classes need to know about. However, when all the code is in one big class, all fields and methods are effectively public, and there's no easy way to tell what code fulfills what concern. (Okay, you can tell what code does drawing — it's in the Draw() method — but there's no way to tell tank code from thumbpad code.)

What you need to do is separate the responsibilities out into different classes. Conceptually (and object-oriented design is about modeling concepts, not necessarily modeling physical things), ...