I've found that, for the most part, encapsulation is a solution in search of a problem. Once you stop taking for granted that it's a Good Thing because everyone knows that it is, you notice that the collisions that are supposed to be such a problem for the most part aren't, and when they do pop up it's not hard to find workarounds. What's far more common, at least in encapsulation-driven environments, is to be thwarted because you can't get at something you need. (Of course, "encapsulation" means a lot of different things. I'm not talking about, say, separation of concerns in design. I'm talking about the whole public/private/protected way of locking things away from external use.)
The value of encapsulation is in defining an interface. I mean a contract along the line of "These two blobs of code should be able to talk with each other using i, j, k, and l; if they really aren't, let's do more thinking." This is a good thing, it suggests you to think in terms of independent modules instead of spaghetti code.
However, when it comes to encapsulation by enforcing information hiding it sounds awfully lot like trying to protect random dumbfools from themselves. It certainly ought to be sufficient to define the public interface in the documentation or headers, and expect people to adhere to that.
A smart programmer really can find his way through into what was in the first place encapsulated if he really, really has to. Conversely, in the case where a dumbfool would ignore the documentation and poke around with private code he would simply do equally stupid but alternative things if he was prevented from touching any private parts (Hehe). That is, if one can't do the job he can't do the job no matter how severely his options are limited.
It depends entirely on the type of software you are creating. Encapsulation in system code (libraries, APIs, frameworks, etc.) is probably a good thing. We've seen the nightmare that comes when people exploit the full range of behavior of systems without regard to whether it's part of the official spec or the public API. You create a compatibility nightmare that forces you to do crazy things like release bug-compatible updates for the foreseeable future, and to make excessively sharp breaks between API generations.
you're absolutely right, and you present quite a compelling argument against object oriented programming itself. we're still paying the price for a prank a bunch of consultants played in the early 90s.
