If you read further, and go on to the follow-up articles, you'll find that all is not as it might appear to such a shallow glance.

Really?

4. The Teller object asks the Bank_records object for an empty Withdrawal_slip. (This object will be an instance of some class that implements the Withdrawal_slip interface, and will be passed from the Bank_records object to the Teller object by value (using RMI). That's important. All the Teller knows about the object is the interface it implements -- the implementation (the class file) comes across the wire along with the object itself, so the Teller has no way of determining how the object will actually process the messages sent to it. This abstraction is a good thing because it lets us change the way the Withdrawal_slip object works without having to change the Teller definition.) 5. The Teller object tells the Withdrawal_slip object to display a user interface. (The object complies by rendering a UI on the ATM screen using AWT.)

Looks like not seperating display and implementation to me. The Withdrawl_slip object is working directly with the UI. I don't see any way to interpret the above differently.

How about trying not to have too much of a knee jerk reaction to something you admittedly know so little about.

Then please, enlighten me: What is OO? Don't use metaphors--I've read way too many of them, all of them unsatisfying.

Saying traditional OO concepts (like accessors/mutators) aren't OO doesn't strike me as a useful definition.