Model the real world or the proper OOP world? Or both?

Question

I'm writing a game where the mouse-driven controller object clicks on a player object to have it do something.

There are 2 ways of initiating the interaction between mouse and player:

• Controller calls player's function:
  Controller listens for mouse events. When a mouse click occurs anywhere onscreen, the controller searches all objects under the point that was clicked. If one of the objects is a player object, and it's "clickable" property is true, then call its appropriate function.
• Player calls controller's function:
  Player listens for mouse events. When a mouse click occurs on the player, and the player's own "clickable" property is true, then call the controller's appropriate function.

My dilemma here is that the first option seems more intuitive with how I imagine the scenario happening in the real world, but the second option seems more intuitive with proper object-oriented design because it doesn't require looking into another object's property, which violates encapsulation to some extent (the controller must look into the player to read its "clickable" property). Also, the second option seems inline with the 'Controller' design pattern.

This is always a struggle for me -- do I defy proper object-oriented design (e.g. option 1) or do I use an implementation that seems counterintuitive to the real world (e.g. option 2)?

I'm hoping there's some kind of middle ground I'm missing.

Answer 1

This is always a struggle for me -- do I defy proper object-oriented design (e.g. option 1) or do I use an implementation that seems counterintuitive to the real world (e.g. option 2)?

I don't think that the purpose of object-orientation is to model the real world.

I think that a (the?) reason why an OO model often follows a model of the real-world is that the real-world doesn't change much: and therefore choosing the real world as the model means that the software won't change much, i.e. it will be inexpensive to maintain.

Fidelity to the real world isn't a design goal in itself: instead you should be trying for designs which maximize other metrics, e.g. simplicity.

The 'objects' in 'object orientation' are software objects, not necessarily real-world objects.

Answer 2

Why not go with Option 3, which is simlar to Option 1?

• Controller calls player's function:
  Controller listens for mouse events. When a mouse click occurs anywhere onscreen, the controller searches all objects under the point that was clicked. If one of the objects implements IClickable or inherits Clickable (or whatever), then call its appropriate function (or fire an event, whichever is appropriate).

Answer 3

The second method is the decidedly more idiomatic Flash way of handing things. AS3 has the event model build right into EventDispatcher and all DisplayObjects inherit from it. That means any Bitmap, Sprite or MovieClip immediately knows if it is clicked.

Think of the Flash Player as your controller. When I do MVC in Flash I almost never write a controller because the Flash Player does it for you. You're wasting cycles determining what was clicked on when the Flash Player already knows.

var s:Sprite = new Sprite();
s.addEventListener(MouseEvent.CLICK, handleMouseClick);
function handleMouseClick(event:MouseEvent):void
{
    // do what you want when s is clicked
}

I'd probably not directly access a controller from inside a sprite (probably in the view). Instead I would dispatch an event (probably a specific custom event that matched the circumstance). Make your decisions on how many times per-frame something happens. Responding to a user interaction (e.g. mouse-click) usually gives you the freedom not to worry about the overhead in event systems.

Finally - the reason I suggest this has nothing to do with some Ivory Tower concept of OOD or OOP. Principles such as these exist to help you not constrain you. When it comes down to a matter of pragmatics, go with the easiest solution that won't cause you headaches down the line. Sometimes that means doing OOP, sometimes it means functional, sometimes it means imperative.