Reflection – do you really understand Object Oriented Programming (OOP)?

This Quora link set me back.

After you read through the above link, I believe you may be humbled enough to gauge whether or not you understand OOP. Personally, I have been humbled because now I do not really know whether I know enough of OOP. It is possible, however, that I may have just been confused as a result of reading the link.

Prior to reading the above link, my belief for long has been that I understand OOP quite well – at least enough to make me a more productive developer (to be modest). The reason is that I always thought I was good to go with my theoretical and practical knowledge of the following:

• OOP (a programming paradigm based on objects, just like real-world objects which have state and behavior)
  
  
• class (blueprint from which individual objects are created)
  
  
• object (instance of a class)
  
  
• constructor (a method/function used for initializing object's properties upon object creation)
  
  
• property (used for storing object's state)
  
  
• method (used for exposing object's behavior)
  
  
• interface (a contract between the class and the outside world; a collection of method signatures that should be provided by the implementing class; a group of related methods with empty bodies, implemented outside the class)
  
  
• encapsulation (bundling properties/state with their methods/behavior, and enclosing them in the class. Exposure/interaction to the outside is done through public properties/methods)
  
  
• abstraction (abstracting away implementation details within a class, and presenting only the interface through public methods; abstraction is a consequence of encapsulation)
  
  
• inheritance (common properties and methods can be defined in a superclass and inherited by subclasses)
  
  
• polymorphism (many forms - provision of a single interface to objects of different classes or the use of a single symbol to represent multiple different types; polymorphism makes it possible to have a method that does different things depending on the class of the object calling it e.g. method for area, called by an object of type Square, Circle, Triangle, etc; polymorphism implementations are overloading and overriding)
  
  
• overloading (function/method overloading: having more than one function/method with the same name but different parameters/implementations; operator overloading: having many implementations for the same operator (e.g. + for integer addition and string concatenation)
  
  
• overriding (method overriding: where a child class has a a parent method re-defined with the same method name but different implementation)
  
  
• access modifiers (public, protected, private - for restricting access to variables and methods of the class)
  
  
• etc, etc

Every time I practice the above, it gets easier and easier to appreciate OOP. I understand that it will be pretty difficult to appreciate the above unless you try to use OOP practically in a real-world project. Talk less, do more!

Personally, I also only started to appreciate OOP after I did some real-world projects in Java and Groovy back then. The classroom lectures that I attended on OOP never helped me at all in understanding OOP. It was just too complex and meaningless –  and the animal, dog, vehicle and car examples of classes/objects sounded more abstract like pure math –  until I started doing practical projects.

Now, it goes without saying that the taste of the pudding is in the eating. I have developed many systems using OOP. It feels professionally rewarding and satisfying that I have practically implemented several successful systems using the OOP paradigm where applicable.

So, where is the difficulty in understanding OOP? It makes me ask these questions:

Is it possible that I have only understood OOP superficially, in which case I have not acquired the capacity to reason and question the OOP philosophy? I really want to rule out the possibility that my understanding of OOP may be an illusion.

Is it possible that those who have failed to understand OOP have failed because they only try to understand it theoretically without doing it practically? This would make sense because thinking that one would easily understand OOP without practicing it is a tall order.

Is it possible that someone could have failed to understand OOP because they are a genius, and therefore they understand OOP too much and too easily, to the extent that they start questioning it?

I am still deeply pondering in thoughts about the above questions. Is it possible?