I think you've got it for the first three. The polymorphisim, however, is missing something. This means that objects can change (morph) into different types (poly) at runtime:

int main(void)
{
    A a = B;
    a.talk(); // calls B.talk()

    a = C;
    a.talk(); // calls C.talk()

 
    return 0;
}

That sounds reasonable. I'll look into it. Thank you.

If it seems that no one can agree what the "four pillars of OOP" are, perhaps you should take that as a sign that the idea of "four pillars" is bullshit.

LOL, perhaps that's true. :)

I reimplemented the polymorphism example to take into account multiple types, like Glass_Knife suggested (I think):

#include <iostream>
using std::cout;
using std::endl;


// Base class with virtual member function
class A
{
public:
    virtual void talk(void)
    {
        cout << "Class A" << endl;
    }
};
 
class B: public A
{
public:
    void talk(void)
    {
        cout << "Class B" << endl;
    }
};

int main(void)
{
    A a;
    B b;

    A *a_ptr = &a;
    a_ptr->talk();

    a_ptr = &b;
    a_ptr->talk();

    // Also see function overloading as an example of polymorphism
    // ie:
    // int add(int a, int b) { return a + b }
    // float add(float a, float b) { return a + b }
    //
    // Also see templates
    // ie:
    // STL containers

    return 0;
}

If it seems that no one can agree what the "four pillars of OOP" are, perhaps you should take that as a sign that the idea of "four pillars" is bullshit.

Not a sign of that at all. There are four pillars of OOP, but just like vendors implement the C++ standard differently, OOP languages implement their own version of the four pillars. The fact that there is overlap in them shows it isn't completely bullshit.

If it seems that no one can agree what the "four pillars of OOP" are, perhaps you should take that as a sign that the idea of "four pillars" is bullshit.

LOL, perhaps that's true. :)

I have heard all kinds of definitions and descriptions over the years. Most of them are garbage.

The paradigm of "object oriented" is that actions are based around a consistent clump of data called an object. The object is treated as a whole rather than as parts. You do operations on the object generally. One person I recall had a long story about it involving a gorilla, based on the old "teach a pig to sing" story. You treat the gorilla as a single object, rather than trying to pass around the individual eyes when you want the gorilla to see, passing the stomach when you want the gorilla to eat, or passing the limbs when you want the gorilla to walk. Constantly reaching into the internals is inconvenient to the zookeepers and it annoys the gorilla.

You can try to add things to make a formal definition for yourself, but over the decades most people realized this is futile. There are always exceptions to the rules, there are things some people want to add, things other people disagree with. Ultimately there is no formal definition for the paradigm, just a general concept of "objects are independent chunks of data that are treated as a unit."

There are many paradigms. Some of them work well together, others do not. Event driven paradigms, for example, can play very nicely with object oriented paradigms. An event happens, generating an event object. The object is passed around in response to the event, often with a chain of command pattern, until it is processed. If you consider functional paradigms, they often do not play well with imperative paradigms. Parallel paradigms may or may not play well with linear paradigms.



The C++ language, for instance, can be used for object oriented paradigms. The classes that contain data and operations for that data are useful to the paradigm. But that does not mean you need to follow it. You can treat data as raw data rather than cohesive objects. You can pass around object internals rather than full objects. You can follow non-OO paradigms if you want. Just because the language is designed toward the paradigm does not mean the code actually uses the paradigm.


I can very easily write code that uses classes, encapsulation, inheritance, polymorphism, and everything else listed above, and craft the code so that it quite clearly does not follow an object oriented paradigm.

I can also use languages that are not built around object oriented themes, but then organize the data and code to clearly perform object oriented work.

If it seems that no one can agree what the "four pillars of OOP" are, perhaps you should take that as a sign that the idea of "four pillars" is bullshit.

Not a sign of that at all. There are four pillars of OOP, but just like vendors implement the C++ standard differently, OOP languages implement their own version of the four pillars. The fact that there is overlap in them shows it isn't completely bullshit.

People can't even agree as to how many "pillars of OOP" there even are (some say three, or five, or even eight), much less what those pillars are. Not to mention the lack of clarity as to what a "pillar" even is - ranging from "defining feature" to "guideline for good code design".

The idea of "languages implement the four pillars differently" is irrelevant, given the fact that people can't even agree as to what the pillars are within the context of a single language.

Any overlap is a result of trying to describe the same underlying concept, not an indicator that the idea of "four pillars" is meaningful.

Whoa, whoa whoa, OP.

Inheritance, abstract classes and polymorphism are not the core or most important parts of OO. They're rarely used compared to the rest of OO!!

As mentioned earlier, composition is the killer feature, and SOLID is the 5 pillars.
http://en.m.wikipedia.org/wiki/SOLID_(object-oriented_design)

Honestly it depends on who you read. Just doing a google search for "Pillars of object oriented programming" gives you books that talk about "The three pillars of OOP", "The four pillars of OOP", etc. Again, I wouldn't say it is complete bs, but it does appear the different programmers, groups, etc. pick and chose what "pillars" they consider to be the pillars. Then you also get results about pillars of OOP in <language>. I'm sure there was an actual set of pillars for OOP, but with so many people picking and choosing for their preferences, I'd say it is hard to find the definitive pillars of OOP.

Case and point, here is a site that claims there is only three pillars of oop for C++ (which after looking, may really be only three base pillars): http://cs.smu.ca/~porter/csc/common_341_342/notes/oop_3pillars.html

So depending on who it is, you could have a ten pillars of OOP if they can find the ten things to name off.

@Anthony Serrano

Just because they can't agree doesn't make the pillars bs though. Just means they have their own idea of what they are. Again, if you look there is a base group that is in all of the pillars and then more added on. So I would say there is a base set of pillars and that people just add to them depending on their opinion. For example, in all the different <number> of pillars I've seen all had Encapsulation, Inheritance, and Polymorphism so I'd say those are the three base pillars and the people just add what they think should be pillars on top of that.

OK, I got it:

5 pillars of OOP:

• encapsulation
• inheritance
• composition
• abstraction
• polymorphism

5 pillars of OOD:

• Single Responsiblity
• Open-Closed
• Liskov Substitution
• Interface Segregation
• Dependency Injection

Got it.

So if I write a program, in order for it to be OOP, I must use all of encapsulation, inheritance, composition, abstraction, and polymorphism. If for any reason I do not include any one of those features, my program is not OOP compliant. As long as I include all of those features, my program is 100% OOP and the gods of OOP are satisfied.

Similarly, if I use all the features (or do not use all the features) of the second set, my design is similarly satisfying the deities of OOD.

For some reason, that doesn't sit well with me.

There are lots of programming languages that don't support all of the first five language items, and yet people seem satisfied that they can be used for object oriented programming.

The design pillars are generally good principles of design for object oriented programs, but are you suggesting that if I give a class more than one responsibility it suddenly ceases to be object oriented? If my interfaces are not completely segregated, my design ceases to be object oriented? I don't think so.

These are paradigms and general principles, not stone-etched laws.

Object oriented is a term from the 1960s, used to differentiate from other practices of using memory. There are many other data-centric ways to process data. Lots of stream-based and DSP-based algorithms work better without discretizing the data. And that's okay too.