Well, encapsulation was one of the three legs of the OO stool, especially at a time when languages like C/C++ offered no protection against reading/writing memo

Well, encapsulation was one of the three legs of the OO stool, especially at a time when languages like C/C++ offered no protection against reading/writing memory anywhere in a program's data or code segments. Encapsulation back then literally meant keeping the representation of the data close to the code, i.e. in the same class that implemented the interface on the data or a closely-related specialty class. So I would say the author is not incorrect in looking askance at "value objects" that are passed around, from that perspective. On the other hand, I'm not sure the perspective is quite as important as it used to be. Modern dynamic languages make it harder to do bad things in memory, and passing value objects around is pretty much the arterial life force of the entire Internet. In any case one thing is sure: the more pieces of code that know the internal structure of a bit of data the more dependencies there are, and the harder the program is to work on. So to the extent you can have that knowledge in one place - the implementation of an interface - you're better off. Perhaps more importantly, OO purism just seems a little anachronistic to me today. I think the key things that OO had to teach us have been mostly absorbed, and we've moved on. It's still there, but now it's part of the fabric of the art and not as obtrusive as it was in the 90's.