>If you have classes which require constant mutable access to internal state, your design is probably flawed.

How do you account for value objects in that statement? Are you saying there should be no such thing?

There's no reason value objects need to be mutable. In fact, they shouldn't be mutable. They're just data. Why would you need to mutate them?

Well, in the strictest since, I suppose a "value object" is technically one that is immutable by definition. So, to your point, I should clarify that here I'm instead speaking more loosely of an object that is chiefly comprised of data elements vs. behaviors.

So, a common use case might be loading data from a DB, changing several fields, then writing updates back to the DB.