Maybe writing code for a company will better enlighten me on the benefits of parents handling child logic
Textbook OOP modelling is often inconvenient, inefficient, or plain old wrong.
Consider the typical moving ball problem. Many OOP textbooks model a moving ball like this:
class Ball {
public:
virtual void move() { x += dx; y += dy; }
};
Very nice, the ball moves itself. Awesome. We can even implement a bunch of moving objects, each with a different implementation of the polymorphic move() method, and they will all move differently.
But then we want to do collisions, and the thing breaks. The ball moves, but in order to check if it can actually move, it needs to know a lot about its environment: the position and type of all the other objects, the walls, and maybe a lot more. We can, of course, change the move method's signature to:
virtual void move(World& world);
...but this means we have to open up a whole bunch of internals of both the world and its objects so that individual objects can read and manipulate them. The benefits of encapsulation are mostly moot this way. Another ugly spot is that if two object collide, the design mandates that one of them is the 'bouncer' and one is the 'bouncee': it's ball1->bounceWith(ball2);, even though they are really equal partners in the collision.
If we take a step back, we might observe, though, that in the real world, a ball does not in fact move itself. It is a passive object, subject to physical effects such as elasticity, inertia, in short, mechanics. The ball does not move itself: the ball has a bunch of properties, and the laws of nature act upon it.
Taking this back into the OOP domain, we end up with a design where the ball is just a data object with little functionality; it has a position and a velocity, and a few immutable properties such as mass, elasticity, etc. Movement is not handled by the ball itself, but by the Physics class: this class reads the object's parameters, and performs suitable physics calculations, something like this:
class Physics {
void updatePositions(Object[] objects) {
foreach (objects as object) {
object->position += object->velocity * deltat;
foreach (collidingObjects(object, objects) as cobject) {
handleCollision(object, cobject);
}
}
}
};
The Physics class can act upon all the objects, without knowing too much about them (e.g., it doesn't have to know the color of a ball to calculate how it bounces, so the ball can keep that information to itself), but it can naturally operate on two objects at a time - the bouncer/bouncee problem goes away, as it is now physics->bounce(ball1, ball2);.
If you're a keen observer, you may notice something: the ball is a plain data object with little or no functionality; the physics class is pure functionality with little or no state. This means that we have separated state from behavior, exactly the opposite of what OOP tries to do (bundle state and behavior into classes). We could just as well have written this in a procedural paradigm or, in fact, if we ignore the OOP boilerplate, we actually have: class Physics is basically just a function (or a set of functions), and class Ball is just a record type (polymorphic, if you have different object types, but still just a record type).
]]>
It just was trial & error at its core. Some casual players I've tried it with liked it, but I didn't end up liking it later. It was quite a relaxing game tho. 
I loved OpenLayer. 
Though you do have me beat in one regard, you have a family, I don't 
