That's true, and often a well-designed object needs setters, but I think what the parent is getting at is using objects to model dumb data instead of behavior e

That's true, and often a well-designed object needs setters, but I think what the parent is getting at is using objects to model dumb data instead of behavior encapsulating state. If an object has getters and setters for all its members, then it isn't really an object. It's a degenerate object that is equivalent to naked data. Not much changes if it has only getters: then it's just immutable naked data. (Which I think is a good thing, and I hate it when people make blanket assumptions otherwise! And I hate it when languages like Java make it awkward to express dumb immutable data. I think the pieces in a program that are best modeled as "behavior" and "state" is a subset, usually a proper one, often a small one, of the data and functionality that needs to be modeled in a nontrivial program. Often there's a lot of data in a program that is most clearly modeled as dumb data, or at least as transparent data packaged together with some common operations. "Behavior" and "state" is mental overhead that only pays for itself when you have to express a certain amount of complexity. That's why it's so important for a language to let you start in one style, with plain transparent data (and lots of immutability), and switch to encapsulated behavior when you discover that part of the code is complex enough to benefit from it. Otherwise you pay a high mental cost to future-proofing every piece of data with getters and setters and private data when it's possible that only a small portion of your code will ever benefit from it.)