
Psychological encapsulation - llambda
http://www.johndcook.com/blog/2011/03/02/psychological-encapsulation/
======
pragmatic
I've always distrusted the black box model of object oriented programming. It
sounds good in theory but in practice you hardly ever get it right the first
or the fifth time.

Consider a complex component like an ftp library. There are so many quirks
with hosting OS'es (e.g. VAX) that connecting to a new system may cause
something completely unexpected to happen. Unless the component author is very
good at predicting failure conditions and passing meaningful error messages to
the client, you may be completely stuck. You cannot tell if it's a
configuration issue, a library issue or if it's an issue in your code and the
way you call the library.

The ability to inspect (and fix) source code is invaluable. Even Microsoft
let's you at least look at the source code for .NET now.

~~~
julian37
You're conflating encapsulation, OOP and open source.

Encapsulation can be done (and is a good idea) in any programming paradigm,
OOP or not. For instance, in C you can use the _static_ modifier to not expose
a function to the outside world, or use a typedef to expose an opaque handle
rather than exposing the struct definition in a public header file. In Haskell
you can limit which functions and types are exposed by a module as well. These
are just two examples: languages that provide no means of encapsulation
whatsoever are few and far in between. BASIC comes to mind.

Likewise, a closed source component can expose internals in harmful ways and
an open source component can over-encapsulate things to the point where it
becomes useless for any use case except for a few select ones that the
component author anticipated.

Of course it's helpful to be able to inspect the source but that doesn't
really have a lot to do with encapsulation. (Although it does have to do with
the concept of "psychological encapsulation" established in the article.)

------
kstenerud
Sticking with an operating system is a matter of convenience. Changing to a
new OS requires learning a different way of doing things, be it different
keyboard shortcuts, different names and locations for everything, different
behaviors, and most importantly, a different set of unfixed bugs that you must
discover as landmines.

The same goes for using a new piece of software or a new programming language.
It's not so much the different paradigm that's the problem (though that does
contribute to the friction against change somewhat), but rather the myriad
different ways in which it is broken, that you must discover via trial and
error.

Black boxes are great so long as you can actually look inside them when they
don't work as expected. But even then, one approaches new things with caution
because one cannot look inside some code and instantly spot the flaws.

But hey, there's no such thing as flawless, so encapsulation or no, you'll
deal with this stuff all the time as a developer. At best, you'd restrict
yourself to using popular code (since there would have already been a lot of
pressure brought to bear to fix the most egregious flaws), well-established
code (since it would likely be more mature, and more help would be available),
or code from a reputable source.

------
johndcook
A breach of psychological encapsulation can do more harm to your career than a
breach of logical encapsulation.

Once a client or manager loses trust your code, it may not be possible to
regain their trust by doing high quality work from then on.

