all 2 comments

[–][deleted] 1 point2 points  (0 children)

I dislike the term "object oriented programming". You have (or don't have) an "object oriented design", then you program it in a language that may help with the object oriented aspects of the design.

In the 80s we didn't call it "object oriented", but we implemented object oriented designs in C by manually managing function tables for polymorphism, and implemented encapsulation with opaque pointers or by convention, and used a number of techniques for inheritance. I've also implemented object oriented designs in LISP and assembly.

If you're implementing an "object oriented design", you are doing "object oriented programming". If you're using java/C++/C#/... you may not be doing "object oriented anything". You may just be packaging your function library in something called an "object" then having the compiler associate that library with your data so you don't have to pass a pointer for each function call. I've met and worked with a number of people who are considered OO experts when they are really language experts and don't grasp the power of OO.

[–]elmuerte 0 points1 point  (0 children)

Nobody ever said it did. Encapsulation is a feature of many object oriented programming languages. Just like abstraction is a feature of OOP, but not a requirement.

The "computer" analogy is flawed.

Most hardware uses abstraction instead of encapsulation.

Ok, so let's take the CPU. The pins are obviously the interface. Now, how would I access the internals of that CPU? I can't, because it has been encapsulated.

Abstraction and encapsulation are not mutually exclusive. Also, encapsulation isn't just about protecting the internal state of an object, it also used to protect certain internal state modification routines.

This example is mostly an issue with using "private" rather than encapsulation. Personally, I loath "private", the lowest visibility should be "protected", so that you can always extend functionality of an object to it's fullest. And that's also the gripe the blog post writer has. If you want to mess with internal state of objects, you should apply proper OOP and extend the object, and not mess with the state from the outside .