3 ms·

Psychological encapsulation

24 points by llambda 15y ago

pragmatic 15y ago
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 15y ago
  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 15y ago
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 15y ago
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.

24 points by llambda 15y ago

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 15y ago
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 15y ago

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 15y ago

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.