Object oriented programming – by Ashith Bolar

I thought I would write few words on Object-oriented programming. Now you might ask me why I am spending my time talking about a technology that’s almost as old as computer programming itself — an idea that has an all-pervasive nature to it in the industry, there is no need to flog the dead horse one more time. Here’s the reason. I can’t tell you how many times I’ve talked to software developers and designers, who know the text-book description of OOP, but have a very limited insight into it.

When you talk to someone who dabbles with OOP, you hear polymorphism, method-overloading, dynamic-dispatch, public and private methods. But these are not what set OOP apart from its predecessors. I am in no way implying that these are not significant additions that came out of OOP. These concepts are just derivatives of the bigger idea of OOP.

Encapsulation is the primary idea behind OOP. Encapsulation simply means bundling of data and associated methods.

Let me explain: Before OOP, computer programming was a series of instructions written one below the other. This is like a two-way communication. You, the developer, is telling the computer what to do in a series of instruction. The idea goes back to the 8th century Arabic mathematician al-Khwarizmi (which is where we purportedly get the word algorithm). This is all good if you’re writing a program to determine the greated common divisor of two numbers. But over time computers have gone on to solve bigger problems, and procedural programming just doesn’t cut it.

So let’s say you’re writing a computer simulated solar system. In a purely procedural language set up, you would write a big program called “solar_system”, which controls all the planets and the sun, with a main function ‘run_solar_system()’. On the other hand, if you write a program, one that is influenced by object-oriented paradigm, it would contain encapsulations of the class of planets, with particular instates of each of the planets.

Compare the two very simplistic example codes of how each one of them looks:

Procedural paradigm:

currentPosition = getCurrentPosition('jupiter')
gravitationalField = getGravitationalField('sun')
jupiterNewPosition = 
  getNewPosition(currentPosition, gravitationalField)

Object-oriented paradigm

jupiter.calculateNextPosition(sun.gravitationalField())

Notice that in the first case, solar_system is doing the calculations for all the planets – a one way communication. In the second case, the communication is between the planet and the sun – direct communication. This code, if well written can be extended between any two (or three of four) objects within the solar system.

It is true that the expressive measure of both the paradigms is identical. What you can write in the OO paradigm could just as well be written in the procedural one. What makes the OO stand out, is its readability.

The line of code in the OO paradigm can be read as “Let Jupiter calculate its next position based on the gravitational field of the sun). Compare that to the lines of code in procedural paradigm would read something like this: “Take Jupiter’s current position, and take the gravitational field of the Sun, and using both, do some calculations and determine the next position Jupiter ought to take.”

By extension of it being readable, OO lends itself to thinking in terms of how we perceive the real world. And all this is achieved primarily by a single concept – encapsulation. By making a class called Planets, and instantiating Earth and Jupiter as Planets, the programmer has enabled the individual objects to communicate with each other, rather than letting an overarching program do all the dirty work. A clean readable code, implemented by a clean and organized underlying objects.