When I was first introduced to object-oriented programming techniques, the major difficulty I experienced was learning how to think in an OOP-y manner. At first, the idea of everything being an object was weird, and capturing the behavior in my code felt non-intuitive and awkward.
As I gained experience, I ran into the road-block that most people run into at some point - it's one thing to define the behavior of a system object in code (such as a DNS record or a user account) but real-life objects can be exponentially more difficult. When it comes down to having an object make some sort of decision you frequently end up bogging yourself down in code, getting frustrated, and eventually giving up.
This represents a fundamental problem in how we think about program and object structure. I had one of those eye-opening moments yesterday (much like when I discovered cheese) that makes you pull back and think about how you do everything for a second.
When you work with anti-objects, the logic is pushed out of the obvious location and typically distributed over a number of smaller 'background' objects.
The example I read about was Pacman. The Pacman object would be easy - it just responds to user's commands. The ghost is the hard part, since it has to chase Pacman around and make decisions about where is the best place to go. The logic for that can get unwieldy pretty quickly. Here's where it gets weird.
When Pacman moves over a floor tile object, it leaves behind a little 'Pacman scent' that is diffused over the neighboring tiles. The tiles that are walls block the scent. The logic in the ghost tells it to follow the smell.
You really should read the full paper by Alexander Repenning at the University of Colorado.
