Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

One day I went to a Stack Overflow chat and saw a phrase, that was stating that inheritance, incapsulation and polymorphism are the pillars of OOP (in the sense that they are fundamental, a construction sole).

Also, there's a similar question, that I have been asked very often on college exams and job interviews, and the right answer always was the statement pronounced in the title of the question ("Yes, inheritance, encapsulation and polymorphism are the pillars of OOP).

But in the Stack Overflow chat I was severely ridiculed, participants strongly disagreed with such a statement. So, what's wrong with this statement?

Does programmers seem to be trained in different things in post-Soviet and United States colleges?

Are inheritance, encapsulation and polymorphism not considered to be the pillars of OOP by US/UK programmers?

share|improve this question

closed as primarily opinion-based by Robert Harvey, MichaelT, Jesse C. Slicer, GlenH7, gnat Aug 13 at 6:02

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

7  
Your question has no context; we don't know what the folks in SO chat were thinking, or what they were responding to. Maybe you can link to the conversation in the chat room, so we can have a look at it? That said, I think this is best resolved in the chat room, rather than here. –  Robert Harvey Aug 12 at 18:16
1  
@Robert, too many time past. I doubt if I even can found the link to the conversation at all. But I agree that context is important. It's not to blame someone, or to present myself as a innocent victim of a chat aggression, I just want know the truth. –  Jesus Christ Aug 12 at 18:18
    
The phrase "inheritance, encapsulation and polymorphism are the pillars of OOP" is not meaningful without some additional context. Why did you say it? –  Robert Harvey Aug 12 at 18:19
5  
The Lounge. Did you put on your flame-proof suit first? –  Robert Harvey Aug 12 at 18:23
1  
The only meanings I can give to the sentence is either "you can have OOP without any of them" (true, but makes no sense at least for encapsulation) or "you can use them outside OOP as well", or something like that. –  SJuan76 Aug 12 at 18:23

2 Answers 2

up vote 27 down vote accepted

Are inheritance, encapsulation and polymorphism are not considered to be the pillars of OOP by US/UK programmers?

They are considered to be pillars by many programmers, and many colleges teach OO that way.

Unfortunately, it is also a shortsighted view.

  • Inheritance is but one mechanism used to implement OOP and can be abused to not do OOP.
  • Encapsulation is a concept, useful for programming of all sorts, OOP and not.
  • Polymorphism is a... trait(?) to describe how computation behaves. There are many ways to achieve polymorphism, not all of which are OO specific.

OOP has very little foundation, since in reality, it's very conceptual: "Approach the design of your program by thinking of things as objects - cohesive bundles of data and functionality."

And while modern program design takes a poor view of doing things in a "purely OO fashion", most skilled programmers will agree that the SOLID principles (or some subset) are better candidates for the "pillars of Object Oriented Programming" (even though they apply well to non-OOP). These don't work with these terms at all. Instead they use the concepts of software entities (of which, objects are one), interfaces (of which, a C#/Java/etc. interface is one), abstraction and sub-typing (of which, inheritance is one form).

share|improve this answer
6  
Decent answer to an essentially unanswerable question. –  Robert Harvey Aug 12 at 18:24
3  
Does OOP exist ? –  user61852 Aug 12 at 18:45
5  
I would argue that only encapsulation is a "pillar" of OOP. The biggest difference between OOP and structural programming is the idea that objects contain code and data, not just data (e.g. a classic C struct). The other two concepts are primarily used in OO languages, but are neither restricted to OO or required by it. –  Snowman Aug 12 at 20:23
3  
@Snowman Encapsulation isn't restricted to OOP either. People implement abstract data types in C and functional languages all the time. –  Doval Aug 12 at 21:11
1  
Any OO language I know of allows encapsulation without data hiding. Simply declare everything public and voila, nothing is hidden. Data hiding is a separate concept, that encapsulated data must be manipulated via public functions. The intent is to allow those functions to protect class invariants (e.g. employee salary or age cannot be negative). Sure you can contrive examples to get around this, but I am talking about the intent of these features. –  Snowman Aug 13 at 1:42

tl;dr: You can have inheritance without OO, you can have encapsulation without OO, you can have polymorphism without OO, you can even have all three at once without OO. On the flipside, you can have OO without inheritance. Plus, there are different kinds of encapsulation (ADT-oriented and OO), IOW not all encapsulation is OO.

Long version:

The term "Object-Oriented Programming" was invented by Alan Kay, so he gets to decide what it means. And he defines it this way:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

Implementation-wise, messaging is a late-bound procedure call, and if procedure calls are late-bound, then you cannot know at design time what you are going to call, so you cannot make any assumptions about the concrete representation of state. So, really it is about messaging, late-binding is an implementation of messaging and encapsulation is a consequence of it.

He later on clarified that "The big idea is 'messaging'", and regrets having called it "object-oriented" instead of "message-oriented", because the term "object-oriented" puts the focus on the unimportant thing (objects) and distracts from what is really important (messaging):

Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.

The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word -- ma -- for "that which is in between" -- perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas.

(Of course, today, most people don't even focus on objects but on classes, which is even more wrong.)

Messaging is fundamental to OO, both as metaphor and as a mechanism.

If you send someone a message, you don't know what they do with it. The only thing you can observe, is their response. You don't know whether they processed the message themselves (i.e. if the object has a method), if they forwarded the message to someone else (delegation / proxying), if they even understood it. That's what encapsulation is all about, that's what OO is all about. You cannot even distinguish a proxy from the real thing, as long as it responds how you expect it to.

A more "modern" term for "messaging" is "dynamic method dispatch" or "virtual method call", but that loses the metaphor and focuses on the mechanism.

Similar points are also made in On Understanding Data Abstraction, Revisited by William R. Cook and also his Proposal for Simplified, Modern Definitions of "Object" and "Object Oriented".

Dynamic dispatch of operations is the essential characteristic of objects. It means that the operation to be invoked is a dynamic property of the object itself. Operations cannot be identified statically, and there is no way in general to exactly what operation will executed in response to a given request, except by running it. This is exactly the same as with first-class functions, which are always dynamically dispatched.

In Smalltalk-72, there weren't even any objects! There were only message streams that got parsed, rewritten and rerouted. First came methods (standard ways to parse and reroute the message streams), later came objects (groupings of methods that share some private state). Inheritance came much later, and classes were only introduced as a way to support inheritance. Had Kay's research group already known about prototypes, they probably would have never introduced classes in the first place.

Every programmer should read On Understanding Data Abstraction, Revisited. It explains in detail what exactly the difference is between Objects and Abstract Data Types. He gives examples using Java, and that is extremely relevant to this question, because in both the ADT examples and the Object examples he uses inheritance, encapsulation and polymorphism, but only one of the examples is object-oriented! In other words: you can have inheritance, encapsulation and polymorphism, you can even have all three at once and still not have OO.

On the other hand, you can have OO without inheritance. Like I hinted at above: the original versions of Smalltalk (the language designed by Alan Kay, the inventor of the term "Object-Oriented Programming") didn't have inheritance.

Last, but certainly not least, The Treaty of Orlando discusses delegation as an alternative to inheritance and how different forms of delegation and inheritance lead to different design points within the design space of object-oiented languages. (Note that actually even in languages that support inheritance, like Java, people are actually taught to avoid it, again indicating that it is not necessary for OO.)

share|improve this answer
    
You can have "inheritance","polymorphism" and "inheritance"... methinks there's a typo in there somewhere :) –  slebetman Aug 13 at 4:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.