One day I went to a Stack Overflow chat and saw a phrase, that was stating that inheritance, encapsulation, 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?

Do 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?

  • 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. Aug 12, 2014 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.
    – PaulD
    Aug 12, 2014 at 18:18
  • 5
    The Lounge. Did you put on your flame-proof suit first? Aug 12, 2014 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, 2014 at 18:23
  • 2
    Imo OO has only one pillar and that's: "State". Once your brain thinks in state you get OO.
    – Pieter B
    Aug 13, 2014 at 8:41

2 Answers 2


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

  • 11
    Decent answer to an essentially unanswerable question. Aug 12, 2014 at 18:24
  • 3
    Does OOP exist ? Aug 12, 2014 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.
    – user22815
    Aug 12, 2014 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, 2014 at 21:11
  • 2
    And @JörgWMittag had a good answer with regards to messaging. The idea of messaging necessarily requires encapsulation. Messages are typically passed to a function or method on an object, which then acts on the state that is encapsulated therein. That is not to say that non-OO languages cannot have message passing or encapsulation as well, only that these are foundational ideas of OOP.
    – user22815
    Aug 13, 2014 at 1:44

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

  • You can have "inheritance","polymorphism" and "inheritance"... methinks there's a typo in there somewhere :)
    – slebetman
    Aug 13, 2014 at 4:36
  • 1
    This answer makes me wish we could 'favorite' answers too. Oct 18, 2015 at 21:12
  • Alan Kay's definition is outdated. OO needs inheritance, and if you can do both run-time and compile-time binding as in C++, you get performance on par with C too. Feb 1, 2017 at 14:22
  • No, his definition is the correct one. You don't need inheritance at all to be OO. Prototype languages don't use inheritance like C++ and they're still OO. Inheritance is only used to implement code reuse, it's not even the best way, there are a lot of better languages that have mixins, for example. It also has nothing to do with binding, as you can have dynamic dispatching, not even in C++ when you can use virtual methods. Performance has nothing to do with any of this, those are high level concepts, they have no performance. In fact, you could implement message passing in C and be OO Sep 15, 2017 at 1:18

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