Object Oriented Programming (OOP) - Enemies of Object Orientation

Article Understanding Prerequisite - Understanding of Programming and basic understanding of OOP

Object Orientation - Even after so many years of being introduced and being used extensively since, many times you'll find code which does use classes, objects, inheritance etc. but is not actually object oriented. Is it that the object oriented paradigm is tough or there exist certain enemies of object orientation?

The learning material which is easily available, including most of the reference books too, stresses on language constructs instead of object orientation. Sometimes it is understandable too that in the beginning when only one step at a time is being taken, certain illustrative examples are not focusing on Object Orientation, but will only discuss the syntax etc. But later on also, when the reader has sufficient understanding, no attempt is made to undo the prior incomplete understanding.

A classic example of this is the illustrative example of Runtime Polymorphism (can be found in many C++ and Java Books and tutorials) - where in a for loop different shape objects are assigned to a base class pointer/reference, and the area function of each is invoked. What's the point of assigning the objects to reference when the object itself is available? It's only to illustrative what can be achieved, but in what situation will it be effective, powerful is left to imagination of learner. As a result, most people are unable to appreciate the true power of polymorphism for a long time.

Seriously now, most of the new programmers (for that matter even pros) simply turn to Google when they are stuck. What do they find out? A lot of articles written by people who themselves don't understand the core concepts of object orientation.

On many article writing websites, to get hold of some easy money, sadly, many people write the complete source code of programs which are supposed to be standard assignments. While this hampers the learning of the students, the incorrectly written programs set the wrong concepts firmly in place.

As an example, I once saw a program for swapping two numbers in C++. The writer used two different classes to hold two numbers, created one object each of the classes and swapped the numbers, which were public data members, directly from the main function. That was major.

Unfortunately, the code would work fine, and thus most of the beginners won't be able to ask these questions from themselves after reading the code.

* Why create two identical integer classes with different same names, when one class with two objects would suffice?

* If you're accessing the numbers directly in main program (making them public), without any getters/setters, why encapsulate them in a class? Why not use the integers directly?

Such code can however be great case study if you're trying to tell your students/trainees/colleagues how not to write code which is not object oriented despite of the use of classes and objects. The questions like above can set the thinking pattern which will help to drive towards object orientation.