Should I REALLY make subclasses in this situation?

views:

answers:

Should I REALLY make subclasses in this situation?

I'm finishing a small project, an iPhone game.

I've been expanding my GameObject class to include powerups and mines. These are physically identical to each other.

Late last night I came up with the genius idea of making two subclasses of GameObject. They're each less than a hundred lines long. I also have to do stuff like cast them to their respective subclasses when iterating over a list of GameObjects, convert betweeen NSStrings and classes...etc.

Right now I just got rid of those classes and added an int (ID) and NSString (type) to my class. It's really all the information the objects need and works well so far.

Does this go against some obvious OOP, or is this normal for something so small? Or should I do something different all together?

+3 A:

I also have to do stuff like cast them to their respective subclasses when iterating over a list of GameObjects

Why?

If you have to do this, you don't really have an OO design.

Anon. 2010-02-14 20:34:25

Anon is right, the problem is in your model, you shouldn't cast at all

Pedro 2010-02-14 20:36:37

There's a function that returns an array of all GameObjects the player selected.I iterate over this list of GameObjects.I don't HAVE TO, but there are warnings if I don't.

2010-02-14 20:40:40

Yes, the idea would be to treat the objects as a GameObject without having to know that it was a subclass.Also, most of what I've read suggests that you should use inheritance sparingly, only when called for. There's nothing wrong with using other methods (e.g. composition, or an instance variable as you mention) when appropriate.

Sam 2010-02-14 20:43:49

ansaurus

tags:

views:

answers:

Should I REALLY make subclasses in this situation?

related questions