What are the pillars of object-oriented programming?

Question

In general, I’ve seen some places say that object-oriented programming has 3 fundamental pillars, in others I’ve seen saying that it’s 4 pillars.

• How many and what are the pillars of object-oriented programming?
• How these pillars relate?
• They are the same for all languages that support Object Orientation?

Answer 1

You’re asking to whom? Some people disagree.

How many and what are the pillars of object-oriented programming?

Most of the available literature cites four, the three that are more or less universal are:

• Inheritance

  It is the ability of an object to be idealized based on another object.

• Polymorphism

  It is the ability of one object to pass itself by another in a certain circumstance, provided that they are compatible.

• Encapsulation

  It is the ability of the object to put everything together into one thing, in general ends up hiding the implementation details by exposing only what should be accessed publicly, but strictly speaking this is information Hiding and somehow it’s abstraction too.

Most still accept the abstraction which is the ability to express something in general terms, without a specificity, isolated from what does not matter in that context. Not everyone agrees with this because it seems to be just the sum of encapsulation and polymorphism.

Others say it’s a little different. It’s true that the first three are very concrete mechanisms and abstraction is not so much, so it makes some sense. I’m not so sure about that phrase when I wrote it. There is a possibility that in the background all these concepts are abstract and not concrete concepts, some are confused with concrete mechanisms. What is the concrete mechanism of encapsulation? Put something like private? But this is information Hiding and not the encapsulation itself. This is a mechanism that meets the goal of encapsulation.

Some people think having one abstract in language is abstraction, but it is not so. This helps, the interface is still an abstraction, but the mechanism itself is of inheritance or polymorphism.

At a more conceptual point abstraction is closer to encapsulation since abstraction is to hide the concrete mechanism, is to hide the detail of the implementation.

Some still cite some other mechanisms such as operator overload, but some say this is just polymorphism with abstraction and who knows even encapsulation.

I’ve seen even other mechanisms being cited, but it’s much rarer.

My understanding is that these main mechanisms must be present, all of them, to say that it is object-oriented. When only one or two of them are present the code applies to other paradigms. And I have always found the fundamental heritage. Only encapsulate and leave polymorphic exists in other paradigms.

On the other hand I yielded to what many say that encapsulation, in the way it is defined, is the best definition of object orientation, because it does everything that refers to this object being together, it is it that makes the access is always only being made from the object.

I still think that class alone does not define that something is object-oriented, as well as it is possible to be object-oriented without class. The way the class is mounted will define what is OO or not.

Other definitions of object orientation

There is more conceptual literature, generally speaking more than design object-oriented, which does not even consider these mechanisms. Some are vague and leave room for interpretation. These literatures do not focus on code reuse, abstraction from the real world in code, language facilities, mechanisms.

There are even those who define the object orientation how to put the object as focus and the most obvious mechanism of this is you say who is the object and then indicate what you want to do with it, ie, print(objeto) is not OOP, objeto.print() is. I find it simple and too vague, but it seems that this is what most defines the subject.

How these pillars relate?

They don’t need to have a direct relationship, but they can. Every inheritance involves subtype, and the most traditional polymorphism has to do with subtype. There is inheritance without subtype, but it is not common, with mixin for example. It is possible to make subtype even without inheritance. Many languages that are not considered object oriented do this, lack the inheritance to say that it is OO.

Encapsulation is something much more orthogonal, it is not necessary for the other concepts and it does not depend on others existing.

Abstraction without encapsulation and polymorphism, takes place in another way, possible but different. Unless you’re talking about abstraction of general form, there is very simple, but I understand that in OO the concept has a stricter definition.

They are the same for all languages that support Object Orientation?

One thing I’ve said before and I’ll repeat, object-oriented programming has nothing to do with languages. It’s true that some provide facilities for OO programming, but that’s not mandatory, so these pillars exist for the code to be object-oriented, if the language has enabling mechanisms and you don’t use them, or if the language doesn’t have facilitators, but using the pillars is what defines whether the code is object oriented or not.

Already I answered a question with much more detail on the subject. And I get the feeling it’s even duplicate.