Question

I’m trying to design a simple game —Pong, Arkanoid— using strictly ‘Proper OO’, whatever that means.

So, by designing myself to death, I’m trying to get to a point where I’ll know what to do or not do next time…

Who should handle, for example, colissions? And scorekeeping?

My first idea was giving a couple jobs to the ball, but that started expanding exponentially into a god object: The ball’d know where it is, who it crashed into, and report to the scorekeeping objects.

And that’s too much for the poor ball.

Answer 1

rule of thumb:

• if an object logically owns all of the state involved, then it owns the methods that use that state
• if a method requires state from more than one object:
  • if a container object owns all of the objects used by the method, then it owns the method, too
  • otherwise you need a ‘bridge’ object to own the utility method
  • unless there is a strong argument for one object to be the ‘controller’ for the method (can’t think of an example offhand though)

in your case, the ‘gameboard’ or ‘game environment’ would probably have a ‘game physics’ class (or group of methods) that owned the collision-detection (utility/bridge) methods