Procedural vs. Object-Oriented Programming (OOP)

Having trouble making the leap from procedural to object-oriented programming (OOP)? In this tutorial, I'll explain the difference between the two styles of programming and give real-world examples on how and why you might use each. This tutorial isn't language-specific and I won't use any code examples, but by the end of it, I think you'll have a better understanding of object-oriented programming and how you can apply it in your own code projects.

If you're just starting out, chances are that you are programming in a procedural manner. In a way, procedural programming could also be called linear programming. One thing happens and then the next. Code is executed from the top of the file to the bottom.

OOP isn't as linear as procedural programming. Code is often broken up and distributed across multiple files, each one with a single purpose. OOP is also more abstract than procedural programming because it looks for patterns and reusability. The same code can be loaded and executed many times to accomplish a task without having to retype it.

A Crash Course In OOP

Before we get too much further, let's define a few terms. The most basic set of vocabulary for OOP is a class, an object, a property, a method, and a parameter. One of the key concepts for OOP is inheritance.

  • A class is a set of functions that work together to accomplish a task. It can contain or manipulate data, but it usually does so according to a pattern rather than a specific implementation. An instance of a class is considered an object.
  • An object receives all of the characteristics of a class, including all of its default data and any actions that can be performed by its functions. The object is for use with specific data or to accomplish particular tasks. To make a distinction between classes and objects, it might help to think of a class as the ability to do something and the object as the execution of that ability in a distinct setting.
  • A method simply refers to a function that is encased in a class.
  • A parameter is a variable that is passed into a function that instructs it how to act or gives it information to process. Parameters are also sometimes called arguments.
  • A property is a default set of data stored in a class. A class can have multiple properties and the properties can be changed dynamically through the methods of the class.

Inheritance is one of the keys that make OOP tick. Simply put, classes can inherit methods and properties from other classes by extending them and each class can be extended by multiple classes. This means that you can start with a base (or parent) class that contains shared characteristics among several classes. That base class can then be extended by other classes (children) that are similar but are meant for slightly different purposes. Any changes in the parent class will automatically cascade to its children.

There is certainly a lot more that could be written about the above terms and how they should best be used, but those will have to be saved for other tutorials. For now, we're going to leave them behind and move on.

A Few Things To Remember

If you do a bit of digging, you'll find a wealth of information about design patterns and people often point to them as a good way to learn OOP. Some of these might be useful to look at, though I'd be careful about getting into them too much at first because they can be overwhelming. Many of the patterns lack clear-cut examples of how they can be used and so the result can be confusion or frustration if you're trying to learn them by yourself.

Once you start to get a feel for OOP and want to know how you can improve what you already have, that's when I'd recommend really diving into patterns. You'll recognize the need for certain patterns from problems that you've faced with your own code and the pattern will represent something of an 'Aha!' moment.

Instead of going into specific patterns, I'm going to share two helpful (and somewhat overused) acronyms you might keep in mind when trying to get yourself into an OOP mindset: DRY and KISS.

DRY stands for Don't Repeat Yourself and it means just that. If you write some code, you shouldn't have to repeat that particular code ever again. In practical terms, it means thinking more abstractly and planning a little better at the outset. I'll give an example shortly.

KISS stands for Keep It Simple, Stupid and means that you should try to write code that accomplishes its goal in the simplest manner possible. Simpler means fewer possibilities for errors and easier maintenance. In the context of OOP, this usually means making sure that each method has only one task. If you find that a method does more than one thing, it usually means that it can be refactored into several smaller methods, each dedicated to a specific task.

A Real-World Example

Okay, that's enough theory. We're going to put both types of programming to the test with a real-world example. Let's say that you are working for a vehicle parts manufacturer that needs to update it's online inventory system. Your boss tells you to program two similar but separate forms for a website, one form that processes information about cars and one that does the same for trucks.

For cars, we will need to record the following information:

  • Color
  • Engine Size
  • Transmission Type
  • Number of doors

For trucks, the information will be similar, but slightly different. We need:

  • Color
  • Engine Size
  • Transmission Type
  • Cab Size
  • Towing Capacity

In procedural programming, you would write the code first to process the car form and then the code for the truck form.

With object-oriented programming, you would write a base class called vehicle that would record the common characteristics what we need from both trucks and cars. In this case, the vehicle class will record:

  • Color
  • Engine Size
  • Transmission Type

We'll make each one of those characteristics into a separate method. The color method, for example, could take the color of the vehicle as a parameter and do something with it, like storing it in a database.

Next, we will create two more classes: truck and car, both of which will inherit all of the methods of the vehicle class and extend it with methods that are unique to them.

The car class will have a method called numberOfDoors and the truck class will have the methods cabSize and towingCapacity.

Okay, so let's assume that we have a working example for both procedural and OO programming. Now, let's run through a few scenarios that we could come across in a normal working environment. You know the type of scenario because it always begins with the thought: I really wish my boss didn't send this in an email request at 4pm on a Friday afternoon.

Scenario 1

Suppose that we suddenly need to add a bus form, that records the following information:

  • Color
  • Engine Size
  • Transmission Type
  • Number of passengers

Procedural: We need to recreate the entire form, repeating the code for Color, Engine Size, and Transmission Type.

OOP: We simply extend the vehicle class with a bus class and add the method, numberOfPassengers.

Scenario 2

Instead of storing color in a database like we previously did, for some strange reason our client wants the color emailed to him.

Procedural: We change three different forms: cars, trucks, and buses to email the color to the client rather than storing it in the database.

OOP: We change the color method in the vehicle class and because the car, truck, and bus classes all extend (or inherit from, to put it another way) the vehicle class, they are automatically updated.

Scenario 3

We want to move from a generic car to specific makes, for example: Nissan and Mazda.

Procedural: We create a new form for each make, repeating all of the code for generic car information and adding the code specific to each make.

OOP: We extend the car class with a nissan class and a mazda class and add methods for each set of unique information for that car make.

Scenario 4

We found a bug in the transmission type area of our form and need to fix it.

Procedural: We open and update each form.

OOP: We fix the transmissionType method in the vehicle class and the change perpetuates in every class that inherits from it.

Wrapping It Up

As you can see from the above scenarios, employing an OOP style has significant advantages over procedural programming, especially as your scale increases. Consider the savings we would receive from OOP in terms of repeated code, flexibility, and maintenance if we also had to add forms for boats, motorcycles, planes, go-karts, ATVs, snowmobiles, etc. Objects and methods are also far easier to test than procedural programming by using unit testing to test results.

Does this mean that you should never use procedural programming? Not necessarily. If you're doing a mockup or a proof-of-concept app, you might not have the time to make everything object-oriented and so I think it might would be better to use procedural programming for a prototype, but it would be best to make the production product in an OO-manner.

This has been just a brief foray into a very large subject, but I hope that you've been able to get a better understanding of procedural vs. object-oriented programming and when and how to use each. If this tutorial has been helpful to you, please bookmark it for your reference and share it with your friends and colleagues.


  • Benjamin Kuker

    Benjamin Kuker

    Benjamin Kuker is the co-founder of Virtuosi Media and is married to his beautiful wife, Johanna. He is responsible for the design and maintenance of this website. He enjoys reading, writing, programming, business, sports, and traveling.

    View Benjamin's Bio

Help us spread the word.

Your Comments Are Valuable - Join The Discussion!


Copyright 2011 Virtuosi Media Inc.