In more general terms, what OOP is meant for and what it handles perfectly is exposing functionality of an isolated data structure. When, however, it comes to i

In more general terms, what OOP is meant for and what it handles perfectly is exposing functionality of an isolated data structure. When, however, it comes to interaction between separate objects OOP poses dilemmas like those described in the post. As a classical example, when you define a basic API for a graphical object you usually have no doubt on where and how to define draw(), getBoundingRectangle() etc. as long as the methods operate within the object, i.e. use the properties of one isolated object. Doubts arise though when it comes to things like removing a child object from its parent, for example. Should it be parent.removeChild(child) or child.removeFromParent()? Or both? Or perhaps environment.remove(parent, child)? And Steve's authentication example is probably the most compelling one. How can you trust a polymorphic call to visitor.hasMachineGun()? So yes: "It's not the way things work in the real world, and OOP is supposed to model the world." The world is not just objects, it's also interaction and interoperability that makes it an interesting place.