Everyone claims to understand Object-Oriented Programming (OOP), it is taught on nearly every programming course and is supported by nearly every programming language in general use. However, if my own experience is anything to go by, then there are very different levels of understanding as to what it means to practice OOP.

I’ll outline the 3 levels of understanding as I see them:

1. Objects represent actual objects

Most courses I know start by introducing the idea of objects being used to represent real objects. They are used to explore the more advanced concepts of inheritance and polymorphism and tend to use objects such as cats and dogs as the items represented as objects. Great theory, but I want my program to do something!

2. Objects as groups of functions

This is the answer to getting objects to achieve the goals of the program – group all those procedural functions together into something called an object. Now we can at least get something done and that is often enough to add OOP to our CV. However, whilst you may be programming with objects, this isn’t really OOP.

I will confess, this was my level for many years. I’d done the theory of OO on my University course, I’d joined a small team of developers writing C++ and risen through the ranks to the point where I was leading the team, but still our programs were little more than objects being used to group functions.

The turning point for me was reading Design patterns : elements of reusable object-oriented software

3. Objects as conceptual items

Having read Design Patterns I noticed a whole new way of using objects to get a task done. These objects represented conceptual items and worked together in such an elegant manner that I was embarrassed by some of the previous objects I’d produced! Being able to produce programs that make use of objects as a way to model real-world items, can get the job done and also model the concepts of the program is the level of understanding that OO programmers should be achieving.