4 ms·

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 th

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.)

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.)