A simple mental model for Object Oriented Programming

Since my childhood I struggled to understand object oriented programming. I thought I understood it very well but I had it wrong for a very long time. It took me some time to understand what object oriented programming is and my goal here is help you understand it in the simplest way possible.

This article covers several programming languages at once so I am not going to publish any code examples. I will explain about different technical jargons used in object oriented programming. This will help you figure out the concepts in the language that you work with.

Object oriented programming

Have you heard of namespaces? They are interfaces that scope a certain feature and prevent it from leaking. For example:

Please turn on the tap!

Which tap? We don’t know.

There’s a solution to it. We provide a name to each tap. The problem is there can be thousands of taps and we have to somehow remember which tap to turn on. That’s not how things work in the real world. It’s a programmer’s nightmare.

A solution to it is that we assign a room and refer to anything in that room using its name. This is called a “namespace”. For example, it’s much easier to remember “common bathroom tap” instead of a uniquely assigned name.

Another example is that there are thousands of people named “John”. How do we identify which one? We don’t assign a unique name to every John we know, right? We identify certain attributes like which city does he live in, who are his relatives, what’s his origin country, etc. so many different identifiers to single out which “John” are we talking about.

Namespaces makes it easier to manage conflicting properties/names and makes it easier to find the property we want to work with.

Namespace has another name in object oriented world. It’s called “object”. Before, you start disagreeing with me, here’s the mental model:

Everything is an object in this world. A room is an object, a knife is an object, even people are objects too. What’s inside a room are called properties of that room. They helps us identify what kind of room it is. For example if a room contains a bed, it’s highly likely a bedroom. You can apply this analogy to any object. A watch consists of an hour, minute and seconds hand, a machine that runs the watch and a battery that powers it. The contents of the watch is what makes it a watch.

The only reason object oriented programming exists is because it makes it so much easier to manage and identify different properties and functions that we need to run in that program.

Classes

Here’s a simple definition of the class: “A blueprint of an object”. But a blueprint is just a piece of paper right with some designs, rules and instructions? We just use to it to build actual objects. Well! There you go. In programming world, you use a “class” to create new objects.

But why do we need to create new objects all the time?

Consider this: if you had one car for everyone to use, not everyone could use it at the same time. Same thing applies to objects in programming. For every consumer to have their own object, we have a concept called factories. I wanted to discuss this term because many people think that a class is a factory as it produces object. Not really! It’s just a blueprint by definition. A factory is a function that returns a new object every time it’s called. The following pseudocode will help you build that mental model.

define factoryFunction { // factoryFunction is a factory
  return MyClass() // MyClass is a class
}

Encapsulation

A watch consists of a dial and internal machinery. The only visible element is the dial because that’s what most users care about. The internal machinery is strictly meant to run the watch and is invisible to outside world. This is a crude definition of encapsulation. In object oriented programming, encapsulation behaves the same way. Any class definition contains internal business logic, and an external interface meant for others to use. We assign the contents of class several permission levels called access modifiers: Private, Protected and Public. Private means strictly confined to the class definition alone. In other words, no visibility to the outside world. Public, on the other hand, means this is meant for public use. What is “Protected”? Before we understand that let’s understand another important concept.

Inheritance

Inheritance means owning something that didn’t originally belonged to you. But somehow you became a legal owner. For example, you can inherit your father’s property. You are its legal owner but in essence it belonged to your father. Inheritance in programming is a feature which allow objects to access properties and methods of another class is if it was its own. Here’s a psuedocode to build the mental model.

class ParentClass { 
  func parentFunc() { /*...*/ }
}

class ChildClass extends ParentClass { /*...*/ }

obj = ChildClass()
obj.parentFunc()

Inheritance gives ownership of something that did not belong to the object. This let’s programmers to build complex logic split into multiple classes, without needing to re-write everything from scratch. For example a parent class might already have a way to convert current object into readable string. A child class inherits the parent class method and only implements what’s specific to child.

A real world example of inheritance would be: “Sport bike” inherits the class of “Bike”. The Bike class brings in the basic functionality. A “Sports bike” adds additional features like a better chassis to reduce air friction, or a “sports mode” to provide more power to the engine. I am not a sport bike enthusiast but you get the gist.

Inheritance also has a special encapsulation mode called “Protected”. Consider this: Your father’s property cannot be used by everyone. It is protected and can only be used by his legal heirs. In programming world, a protected property is like a “private” property but can be used by objects that inherits them.

Polymorphism

A polymorph is something that has more than one shape. In programming world this apply to class methods as well as functions (in some languages). It means a method can have more than one shape. A method can allow different arguments. It’s return type can also change. This improves flexibility in terms of what a function can do. It’s just another feature of object oriented programming that let’s you keep the same method name and get varying output depending on what you provide as the arguments.

Polymorphism is of two types:

1. Overloading (same class has method of same name but different parameters and return type)
2. Overriding (a inheritance concept where you can replace a parent method with child’s implementation).

Overriding is like having a different version of same method. It is still polymorphism because you keep both versions of method and use them according to context.

Abstraction

This is an interesting topic which is usually covered under inheritance. Imagine your grand father built a house but left some door installations incomplete. May be he ran out of funds, OR may be there was some technical limitation that prevented him to complete the work. That responsibility fell onto your father who had all the means to complete the work except for the door locks. That responsibility fell onto you. What do you understand by this?

Some classes are limited by design. They can tell you that a method must exist to do the work, but it cannot provide an implementation because it’s too abstract. In other words, it doesn’t know how something must be done, and it leaves it upto the inheritor to decide.

Abstraction is quite heavily used in library projects. Here’s a simple pseudocode that will help you visualise abstraction.

class AbstrClass {
  define abstrMethod(); // No definition provided
}

class ChildClass extends AbtrClass {
  define abstrMethod() { /*...*/ } // Actual definition
}

Interfaces

Interfaces extended the idea of abstraction and used it to define a template a class must follow. If you want a class to define certain properties and methods, interfaces are pretty useful in enforcing that. This feature solely exists as a safety feature to minimise errors in production. Some languages don’t even implement this feature at all.