[MartinCron]

You may have a planes-that-crash bias there. You don't notice all the times you benefit from a well encapsulated service because it just works the right way. The rare handful of times when something that would be useful is marked private is what sticks out in your mind.

I know that I would prefer to work with an interface with 10 public classes with 50 public methods than an interface with 100 public classes with 5000 public methods.

The conceptual weight of wading through all of that stuff has a cost. There is often value in not knowing or caring about implementation details.

Although I do agree that final/sealed is generally just mean-spirited and pointless.

[SoftwareMaven]

Your argument assumes that you need language-enforced mechanisms in order to define a well-encapsulated API. That is simply not that case, as the many well designed APIs in Python, Ruby, and Lisp can attest (and many poorly designed APIs in Java as well). You can use documentation, conventions, and other mechanisms to define the publicly exposed API so one doesn't have to know the guts.

But when I need to deviate from that API, for whatever reason is important to me but not to the library designer (from a bug to a weird environmental issue specific to me), if I can't get done what I need to, the language is getting in my way instead of helping me.

[MartinCron]

I totally agree that language-enforced mechanisms aren't the only way to get meaningful encapsulation. People can (and do) write good code or bad code in any language.

I was just trying to point out that there are both benefits and drawbacks to language-enforced encapsulation and the benefits may be less obvious than than the drawbacks, which are generally more painful.

[SoftwareMaven]

You have a good point there. You generally have to think about what you are exposing if the language demands it. And I think it is great when a language guides you into doing the right thing. Guides being the operative word.

Given the choice, I'll choose consenting adults. :)