views:

130

answers:

3

I'm working on a project in C# w/ XNA, and I want to reorganize it and divide parts of it into classes.

At present, it's just one game.cs file, but I want to clean it up a bit. Unfortunately, I'm not too familiar with classes. Perhaps someone can help me figure out how to do this, or direct me to some tutorial of some sort?

+1  A: 

Classes are a pattern for an object that can be created, an abstract description of an entity. When a class is instantiated and populated, it then contains the data that describes that entity.

An object typically should encapsulate one literal "thing", or be responsible for managing one specific set of functions.

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

A good example would be a class that represents a playing field, or a class that provides helper functions for a specific type of math operation.

Tim
Classes != Objects … it's more like Object ∈ Classes
Marcel Benthin
The OP asked for some simple guidelines on OOP using C# classes. Correct or not, the beginner is going to hear the terms used interchangeably. When a class is instantiated in c#, it literally IS an instance of type object. However, it's a valid distinction and I will update my answer to be more accurate.
Tim
+4  A: 

Well, start off by thinking of which bits of data go together naturally. For example, if you have a player's name, score, position, number of lives etc, that would suggest you should have a Player class. So take a look at all the state, split it up into different groups, and then check which of your existing methods only work with one group of state or another... and put the methods with the state they're interested in.

It gets trickier when one method needs to deal with state from multiple objects, of course: typically that means you'll put the code in one type and pass the other type in as a parameter.

A lot of this is gut feeling, to be honest - the above are only starting points. Over time it gets somewhat easier, and you'll probably start to think more in terms of responsibilities than just data - but it's a good starting point, as you probably already have the data you need, just not organized in the right way... whereas deciding on the responsibilities within the system can be a lot harder.

Jon Skeet
That and for further detailed study he should probably read something like "Object-Oriented Analysis and Design with Applications" by Grady Booch or other books on the subject.
Grozz
+1  A: 

There's a useful principle in software design known as "Zero, One, Many".

  • Either you have zero of something - so you don't bother implementing it in the first place
  • Or you have one of something - you probably don't need to make this a class.
  • Or you can have many of something - you probably should make this a class.

(The important take away is that there's no case for having two, or three, or four of something.)

Looking at your website, I see you are making a Pong clone. You've got two paddles - so this falls under the "many" case - so make yourself a Paddle class. This way you can create two instances of the class, one for each player.

This way each paddle shares the same functions, but uses different data. Reducing code duplication (which is a good thing).

You've also got one ball. Whether you make this a class or not is probably a matter of taste (and what kind of ambitions you might have for adding a "multi-ball" mode). I would suggest not making this a class, until you find you have a need to do so.

Andrew Russell
At least in XNA, it would make a good deal of sense to encapsulate the ball in a class too, even if its members were static or it was a singleton. But I like the observation of "no two, three, or four".
Tim
@Tim - maybe. But this would be more for compartmentalising it conceptually, than data structure thing. Other options include using `#region` or maybe `partial class` in a separate file. I have found that, for games (as opposed to, say, writing a library for external consumption), staying as light-weight as possible is a huge benefit (why write and manage a Ball class when a couple of `Vector2` and a `Texture2D` will suffice). Now if my game had a ball *and* a spoon *and* an antelope *and* a laser beam - and the lack of delineation started to slow me down - then I'd start breaking off classes.
Andrew Russell
@Andrew - The performance hit of creating a single instance of a small class or struct and accessing its members (versus local variables) would be negligible. I'd be open to a benchmark that proved otherwise. But in the purest sense, yes, sometimes even the smallest amounts matter.
Tim
@Tim - oh - I didn't mean code-performance-wise. I meant from a developer-agility standpoint. The performance implications of what you make a class or a struct or a direct member is an interesting, but unrelated discussion. (Slateboard: I wouldn't worry about this yet.)
Andrew Russell