Growing object-oriented software vs. what I would do

It's true, "good" Object-Oriented Java code is hard to find, because it's not taught very well (or is taught completely wrong, e.g., using "getters" and "setters" to "encapsulate" data).

However, I think it's also true what the author says in terms of not everything is like an object, thought I would say that Domain-Driven Design's idea that there are multiple _kinds_ of objects: Entities and Value Objects, and that they serve different purposes. In addition, there are data-only things used to carry data around and especially across internal/external boundaries, those are Data Transfer Objects. With those three, I've found I can teach OOP to folks and get them to understand it as long as I get across one last concept: all method calls should be Commands or Queries.

When the author says:

> All calls between objects are unidirectional: no public method of an actual object (not a plain data class) returns any value.

That's close, because _most_ of the methods are Commands (requests for an object to change the state for which it's responsible), and anything left are Queries (what's your current state?).

> Does everybody else find it so obvious that it's not worth mentioning and I'm the clown that didn't realize it?

No, it's not said enough, and you're not a clown. The clowns are those that teach getters and setters right after they teach you about classes and don't tell you that the _entire_ purpose of an object is Behavior not Data. Alas, they teach this because it's what they were taught (and it doesn't help that the AP Computer Science curriculum in the USA explicitly teaches this).