Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to structure my game object classes similar to how it is done in this article. One way to implement this strategy is discussed in this StackOverflow question.

Following the strategy proposed in the linked question above, how would I control how objects are handled based on their implementations?

For example: suppose I have a base class Item and two subclasses ItemPhys and ItemStatic. These two subclasses both extend Item. ItemPhys implements the interface Moveable, but ItemStatic does not.

If all of the Item's in my game world are stored in a single ArrayList of Item objects, how do I make it so Item::update() will only try to call Item::updateMovable() if the Item in question implements Moveable?

share|improve this question
up vote 3 down vote accepted

Beware, so that you don't create any tight coupling you are trying to avoid by using this kind of object hierarchy.

I'd suggest you use a uniform way of updating all the components. Let all your entities (e.g. ItemMovable and ItemStatic) implement an Item::Update() method. Then call Update on every entity in your system. Do what you have to do for Movable ones and leave the implementation of the ItemStatic::Update() empty.

If you're worried about performance (i.e. it turns out to be slow specifically because you're calling too many empty methods), you could keep two lists of entities; one that contains all the entities with meaningful Update() method implementations, and one for the rest.

share|improve this answer
This sounds like a great idea! – Kyle V. Feb 2 '12 at 17:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.