I was never formally taught object orientated programming, and so I always face this question with doubt in my mind...

Let me try to illustrate the question with an example.

Suppose I have a class called House which is meant to represent a house in my virtual world. The House class might have some stuff like this:

class House
{
  char house_map[house_width][house_height];
  std::vector<Door> house_doors;
  std::vector<Object> items_on_the_floor;
  std::vector<Person> people_inside_the_house;
  ...
};

My question is about what each class should be responsible for. In particular, if a Person in the house wants to do something, who should control the action? Should it be like house.MovePerson(person_number, action); or person.Move(action)?

It seems to me that the person's actions should be taken care of by the Person class, but many actions depend on the person's surroundings, which the Person class does not have direct access to.

I've experimented with different approaches and I've found that if I let the House handle the Person's actions (metaphorically speaking) then I end up with a bloated House class and a thin Person class. But if I let the Person handle its own actions then I find I end up needing to provide the Person class with a pointer to the House that it resides in, so that it can do stuff like house_pointer->OpenDoor();

So the question sticks in my mind. Should each Person have a pointer to the house, or should the house just control what happens to the person? Or am I making a more fundamental mistake in this kind of design?

I don't think this is abstract enough.

I would have a middle man which would abstract the logic from the objects. Essentially what you want is Person and House classes not to want to know anything about each other. So the player would move forward, the engine might take care of collision so the game then looks for overlapping objects and can send a collision resolver an event, it would then resolve overlapping objects, unless you have a physics engine or something. In terms of actions, each entity can send out an action, you can then send these actions to mediators that can do logic: If the Person sends an Action withing Radius of Door, send player through door.

This is how I'd do it. Not saying its right, but it works for me.

But in RealLife, if you decide to walk through a solid wall, the laws of physics won't let you. What happens is you initiate a movement, and world produces the consequences.

It makes sense to me that a person class should be able to interact with the objects around them, so I would go with Person::CurrentHouse->OpenDoor().

You need to define what interaction the Person (or perhaps any moving object) needs with the House (or perhaps any navigable area), and then encapsulate this into an interface and pass this interface to the person object.

For example, you might write an interface called Navigable with methods:

//returns whether a move is possible in the given 
//direction from the specified location
bool ClearToMove(Location location, Direction direction); 


//Identifies what objects surround the given location
//(e.g. doors etc which implement the Interactive interface)
Interactive[] IdentifySurroundings(Location location);

You then have your House class implement this interface, and cast your house object to a Navigable before passing it to the person. Your person then uses the methods exposed in this interface to navigate the house without actually knowing anything about the house (or even that it is a house). You can also see that the logic is then split reasonably between the two class: the House class has to implement an interface, defining what a house is like to be navigated. Similarly, the Person class must define how it generally navigates anything that is Navigable.

Can you see how this also saves you a lot of work in future? - If you then add a Hotel class, instead of having to define how a person navigates a Hotel, you simply have the Hotel class implement the Navigable interface. Suddenly your Person class can navigate a Hotel too.

At this point you spot that the House and Hotel classes implement Navigable in nearly identical ways. You generalise this by creating a Building base class which implements the Navigable interface, and have both House and Hotel extend this.

You then decide to add an Animal, which you soon realise uses very similar logic to move around Navigables as Person. So, you extract the methods into an interface called Moveable and implement it in a base class called, say, Creature which both Animal and Person extend.

Earlier I stated that you "pass this interface to the person". Actually, it doesn't matter that much what you do: as long as you have generalised the interactions between these classes, then it should be easy to refactor as you wish.

For example, you've now got a general way to move any Creature around any Navigable, and you want to actually control this. So, you might create a PlayerMovementController which defines the logic for moving the player around his present location. Perhaps it could have the constructor:

PlayerMovementController(Moveable creature, Navigable area)

You now realise that your creature can only be controlled in a single House/Hotel (area) at one time. However (and this is the cool bit!), you realise that you can create a new class: World which also implements Navigable, which contains all areas (such as houses hotels etc), and which contains the logic for gluing these contained Navigable objects together.

You can now pass world (cast as a Navigable) into your PlayerMovementController, and suddenly your player can move around the world seamlessly. What's more, the code is in all the right places: how to generally navigate a House/Hotel is in the Building base class. How to generally move a Person/Animal around a Navigable area is in the Creature base class. How to glue all navigable areas together into one seamless Navigable is in the World class.

This isn't necessarily the design I would choose, I've just followed through one scenario to illustrate how powerful it is to generalise interfaces between objects.

Which door?

I'd treat doors as entities, fetch the closest entity, and when the player hits the action button, it does something like near_entity->doAction(player), if the entity is a door, it'd open, or not depending if its locked, or what have you. If it is locked, the door could check the player entity you pass in to see if it has a key. etc.

That's just off the top of my head though. But that't in general what I'd try first.