Object Oriented Programming and its merits over Procedural Programming

After talking about the basics of computer programming, we will today dive into the second most important concept of the course – Object Oriented Programming.

Computers aren’t people, they don’t understand English! And humans don’t understand the language of computers (which is the binary number system). If we have to tell a computer to do certain things, we’ve got to have a middle ground!

How Humans talk to Computers

When sophisticated processors were first introduced (talking about the early 70s), a short code was established called the Assembly Language. It is basically a set of symbols/phrases using the English language alphabet to denote commands for execution on the processors.

Assembly language basically involves a set of instructions written for a specific processor using the English alphabet. Each processor has its own Assembly Language instruction set. However, as processors grew, in processing power as well as number of components, Assembly Language was not able to meet the demands of modern processors – think about constructing a building not with bricks, but with pebbles! As the demands of programmers grew, it became difficult for them to learn a new instruction set.

As CPUs evolved, they packed a lot of functionality and hardware into a single chip. This complexity was getting tougher to code for, with every new microprocessor. There was a need for a middle ground, so that humans don’t have to care about the processor they are running on.

The Evolution of High-Level Languages

Slowly, programming languages evolved to “High-level Languages”, which used highly structured commands in English and were a lot more readable for a human. These high level commands are not readable for an electronic machine.

This presents a domain gap problem. The solution to this is a unit which translates from one language (i.e. high level commands in English) to low level machine executable instructions. This unit is called as a “Compiler”

A compiler acts like a middleman between user and the CPU.

Need of Compiler in OOP


The initial high level programming languages like PASCAL, C, and FORTRAN were all procedural programming languages. They followed the flow of the languages that came before them.

A program in a procedural language consisted of “procedures” (also known as routines/sub-routines). Each procedure performs a task and contains a sequence of commands.

A procedural program is a sequence of tasks. The data that each of these functions manipulated is kept open to all procedures through global declaration.

Object Oriented Programming – a new style to communicate with the computer

Object Oriented Programming (OOP) is a more sophisticated style of programming.

If a procedural program described “how” to do a thing, an object-oriented program described “who” will do the thing and “how”. It’s like switching to cooking in a microwave from cooking over the stove.

We know that a procedural language program basically a list of tasks given to the CPU for execution. OOP goes a level higher in that it identifies a single fundamental unit called as object (which is not present in procedural programming). An object is basically all the procedures and the relevant data operating together – as a unit.

The Switch from procedural to object oriented programming?

The procedural programming paradigm provides a very natural protocol of giving CPU a sequence of tasks to execute. When these programs are scaled up to perform more complex tasks, several problems were noticed as follows:

  • The biggest problem is that all the data is (essentially) accessible to all the procedures. This lack of boundary may ultimately corrupt the data – it’s like firing at the enemy from outside your bunker! Living without boundaries is dangerous!
  • The goal is to make modules independent of each other and simplify interaction among them. Calling a whole bunch of procedures from another block of program is a strict no-no if you want simple inter-module interfaces!
  • Procedural programming describes an action as a sequence of procedures, there is no concept of a single unit – so you cannot use it if you want to develop a program based on real world scenarios.

Leave a Reply