answer-in-context-of-LoD-discussion.txt

> Encapsulation cannot ensure that some behavior is stable to a contract. 
> If you want to ensure that the behavior is stable to a contract 
> you need property-based testing and test the behavior.

> Forbidding access to internal members means you end up with a tightly coupled system.

> Read: http://mergeconflict.com/coupling-in-object-oriented-programming/

Yes, encapsulation cannot ensure that some behaviour is stable. But nobody said it should.
It should ensure that "internal structure" is hidden and so "effectively" stable for the client.

There is no way to ensure that behaviour is stable. But at least there is an OOP convention, 
that once we create a contract and implement it for some object - we will do our best not to change it. 
And actually thinking in granular enough "SRP" contracts leads to making them pretty stable. 
Contract is an abstraction that define some abstract behaviour, and abstractions tend to be stable in our world... 
And by convention, once we implemented a contract for some object - we have to keep this contract 
for the whole object's "history".

And yes, "making object implement contract" is coupling, forbidding assess to internal structure - is coupling.
But LoD and other "anti-tight-coupling" stuff are not about "removing coupling completely" - it is 
about "loosing coupling to value, secure enough".

The article you provided seems to me as another extreme. 
Someone says - coupling is cool. 
Someone - full decoupling is cool.

But in real world there are different contexts. And that's why there is a phrase: "High cohesion, loose coupling".
In fact, imho cohesion - is also coupling, but "useful" coupling, coupling "correspondent to context".
And that's ok. In real world it's useful sometimes to hide something, and sometimes to reveal. It depends.

And by the way, this makes me not believe in "everything is object = good design". 
IMHO - there are different contexts. 
Sometimes object with encapsulated internal structure and strictly defined behaviour via contract - is useful. 
Sometimes just a data structure is completely Ok. 
Real world has both data-structures+functions and "OOP Objects with own coupled behaviour".
Though I still have to admit that in java world "everything is object = good design" seems to be pretty effective 
way of programming... Still I am not quite experienced to be sure... Just learning...

By the way, the problems described by the author of the article you provided, 
can be solved with Yegor's printers ( http://www.yegor256.com/2016/04/05/printers-instead-of-getters.html ). 
Yeah, that printers seem to me as bulky spikes from java world, and I would prefer decorators as functions. 
But Yegor's solution also makes sense taking into account that for some reason 
you want to restrict direct access to object's internal structure... 
E.g. if you assume that it gonna change one day...