[Tloewald]

In a sense the OP is making a point about which paths are paved in most OOP languages. That said, one of the problems I often see in user interfaces is "runaway metaphors". The "objects" and "messages" in question are _metaphors_ and it's important not to let a concept be taken hostage by the metaphors used to describe it.

The main reason controllers exist isn't (or shouldn't be) because of a failure of OOP as a concept, but because of efficiency or complexity. Going back to the baseball example, while it might make intuitive sense for the player to send a "running to first" message, simulating a team's reaction to that event by having player objects communicate purely by messages is horribly complex, whereas a fairly decent simulation can be quickly created by "cheating" with a team controller object (or game controller or whatever).

Even in a "pure" implementation, objects will want to examine each other ("how fast can that player run? Where is she right now? Now? Now? Where's the ball? Who has it? How good an arm do they have?")

If anything, the baseball metaphor shows how complex things can get, and quickly reveals cases where almost any programmer would choose to violate encapsulation to make things work.

[Retric]

how fast can that player run? Is asking about internal state. When can you get to X is not.

The internal vs. external separation can often greatly simplify things. A player does not care where another players feet are they care where the best place to toss the ball is.

PS: In an actual game there is a lot of communication going on. You don't want to throw a ball at someone looking in the wrong direction. So, at some level you're stuck dealing with innate complexity.

[Tloewald]

Of course there's innate complexity, but pursuing encapsulation for its own sake adds complexity you don't need (just like using functional programming techniques for intrinsically non-functional use-cases adds complexity for no good reason).

Again, "messages", "objects", etc. -- these are metaphors. They should be abandoned as soon as they stop being helpful.

[Retric]

Generally, if you don't want encapsulation then your not dealing with an independent object. You could write a game using 2 objects or 2,000, but building complex systems without partitioning becomes incredibly difficult. At the core Objects are a very basic abstraction. It can be as basic as Simulation <-> Rendering, but it's hard to point to a complex system and say this really is best represented by a big ball of mud.

So, sure not everything should be an object. But, saying nothing should be is a much higher hurdle than that.

[Tloewald]

Of course, but this guy is saying nothing shouldn't be, which is an even higher hurdle.