I think the problem is more that it was written with a specific conclusion in mind, without checking if the logic actually held up in the end. Terminology does

I think the problem is more that it was written with a specific conclusion in mind, without checking if the logic actually held up in the end. Terminology does get a bit stretched, at best... >> if you make the mistake of defining public “setter” methods, then the instance variables with setter methods become effectively global variables: if the value of the instance variable is incorrect at some point, that incorrect value might have been set anywhere in your code. You can end up in the same situation by spreading a pointer to your local int variable into e.g. a global pointer just as easily, without so much as a struct. Or more frequently in practice: By finding someone else's buffer overflows, when coding in C. This is a problem, but it's less of an OOP problem and more of a "mutable data with nonobvious mutators" problem (or a "OOP as practiced distressingly frequently" problem?) This starts to go away when your memory access is safe, and when your variables (be they objects or not) are constant (which you'd get enforced for free in a purely functional language - and which I enforce by overusing const in C++ - either of which is compatible with OOP). To a lesser extent, it starts to go away when your variables are only referenced locally - but that's left me wondering about previous values all too often.