Procedural Programming vs Object Oriented Programming

Posted on 28.02.2015 by Kim N. Lesmer.
What are the facts about procedural programming versus object oriented programming?

On the Internet everybody seems to be an expert and forums, blog posts, and YouTube are filled with tutorials, guides, and documents about the difference between procedural programming and object oriented programming.

Especially in the PHP community much misguidance exists, and as if that was not enough, many people are flamed for deviating from the mainstream view upon things. However, mainstream view upon things only seldom represents the truth.

As with everything else it is important to get the facts straight. So lets take a look at the facts.

The first fact is that nobody agrees on what object oriented is. The second fact is a natural consequence of the first fact, and that is that many different definitions for object oriented exist.

If you take the time to really read those two articles, which presents the real facts about object oriented definitions, then you'll understand that most of what you read on the Internet about Object Oriented Programming is just plain nonsense.

One of the greatest ways to understand a specific programming paradigm is to look at how it first evolved. What was the reason for its development? What problems existed with other programming paradigms that needed a new way of thinking? Was it a real world problem or simply an academic problem? And how has it since evolved?

Nothing else really matters!

It doesn't matter what person X says or what definition person Y gives.

Simply take a look at history!

In the past, before the advent of object oriented programming, around the end of the fifties, much software was developed using programming languages that emphasized unstructured programming, sometimes are referred to as first- and second-generation languages. Unstructured programming (or non-structured programming) is the historical earliest programming paradigm. It was heavily criticized for producing "spaghetti" code.

There are both high- and low-level programming languages that use non-structured programming. These include early versions of BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, machine-level code, early assembler systems (those without procedural meta operators) and some scripting languages.

A program in a non-structured language usually consists of sequentially ordered commands, or statements, usually one in each line. The lines are usually numbered or may have labels which allows the flow of execution to jump to any line in the program (like with the unpopular GOTO statement).

Then in the sixties structured programming emerged - mainly due to the famous letter by Edsger W. Dijkstra Go To statements considered harmful.

Structured programming is a programming paradigm that improves the clarity, quality, and development of software by making use of subroutines, block structures and loops. This is contrast to using simple jumps such as the GOTO statement.

Later procedural programming was derived from structured programming. Procedural programming is based upon the concept of "procedure call". A "procedure call" is just another name for a "function call". Procedures are also known as routines, subroutines or methods. A procedure simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a programs execution, including by other procedures or itself.

In the beginning all procedures were available to any part of a program as global data. In small programs this didn't present a problem, but as things got more complicated and the size of the program grew, small changes to one part of the program greatly effected many other parts.

Nobody was planning for changes in the program and lots of dependencies existed. A minor change to one procedure would result in a cascade of errors in lots of other procedures that depended on the original code.

A new technique evolved which allowed data to be divided into separated scopes called "objects". Only specific procedures belonging to the same scope could access the same data. This is called data hiding or encapsulation. The result was much better organized code.

In the beginning objects where not called objects, they where just viewed upon as separate scopes. Later when dependencies were reduced and connections between procedures and variables inside these scopes where viewed upon as isolated segments, the result gave birth to the concepts of "objects" and "object oriented programming".

Later, mainly due to the development of Java, certain "buzzwords" arose and "a procedure" or "a function" was no longer called a function, but was renamed "a method" when it resided inside a separate scope. Variables was also no longer called "variables", but was renamed "attributes" when they resided inside a separate scope.

So an object is in essence simply a collection of functions and variables now called "methods and attributes".

The way methods and attributes are kept isolated inside a separate scope is by the usage of "a class". A class, once it is instantiated, is called an object.

Objects can reference each other and by such a reference the methods (functions) inside can "communicate" with each other. Objects can also "inherit" methods from other objects thereby extending such, this is called "inheritance". It is a way to reuse code and allow independent extensions of the software via public classes and interfaces. The relationships of objects give rise to a hierarchy. Inheritance was invented in 1967 for the programming language Simula 67.

Objects can also inherit methods from other objects and "override" these with added or changed functionality, this is called "polymorphism".

How these different ideas are implemented vary greatly from programming language to programming language.

Object oriented programming is about organizing code in another way than before. It is an extension of procedural programming, and it is about hiding data (encapsulation) and avoiding a global scope. It is about extending functions by "borrowing" their blueprints without actually affecting the original code (inheritance). And it is about overriding functions without affecting the original code (polymorphism).

A funny thing to think about is that many object oriented programming languages are developed in a pure procedural programming language. PHP for example is developed in C and the object oriented features of PHP is a result of a pure procedural implementation.

These are the facts about procedural programming versus object oriented programming.

Programming languages like PHP and C++ has build-in constructs that makes both procedural and object oriented programing possible. And if you are feeling compelled to ask which programming paradigm to make use of simply follow two of the best principles in the world:

  • Always use the best tool for the job (which might be a completely different programming paradigm and different programming language all together).
  • Keep it simple, stupid (KISS).

If you have any comments or corrections feel free to email them to me.