{"id":5231,"date":"2024-11-20T00:35:24","date_gmt":"2024-11-20T00:35:24","guid":{"rendered":"https:\/\/algocademy.com\/blog\/procedural-vs-object-oriented-programming-understanding-the-key-differences\/"},"modified":"2026-10-15T09:07:30","modified_gmt":"2026-10-15T09:07:30","slug":"procedural-vs-object-oriented-programming-understanding-the-key-differences","status":"publish","type":"post","link":"https:\/\/algocademy.com\/blog\/procedural-vs-object-oriented-programming-understanding-the-key-differences\/","title":{"rendered":"Procedural vs Object-Oriented Programming: Key Differences"},"content":{"rendered":"

Procedural programming organizes a program as a sequence of functions that operate on data kept separately. Object-oriented programming (OOP) bundles data and the functions that use it into objects, so each object protects and manages its own state. Neither is better in general. Procedural code is shorter and easier to follow for small, linear tasks; OOP pays off when many kinds of things share behavior and the code keeps changing.<\/p>\n

The examples below are in Python, which supports both styles, so you can compare them on the same problem.<\/p>\n

The same program, written both ways<\/h2>\n

Take a bank account with deposit and withdraw operations. First the procedural version: the data is a plain dictionary, and functions take it as an argument.<\/p>\n

def make_account(owner, balance=0):\n    return {\"owner\": owner, \"balance\": balance}\n\ndef deposit(account, amount):\n    account[\"balance\"] += amount\n\ndef withdraw(account, amount):\n    if amount > account[\"balance\"]:\n        raise ValueError(\"insufficient funds\")\n    account[\"balance\"] -= amount\n\nacc = make_account(\"Alice\", 100)\ndeposit(acc, 50)\nwithdraw(acc, 30)\nprint(acc)\nacc[\"balance\"] = -999   # nothing stops this\nprint(acc)\n<\/code><\/pre>\n
Output:<\/p>\n
{'owner': 'Alice', 'balance': 120}\n{'owner': 'Alice', 'balance': -999}\n<\/code><\/pre>\n
It works, and you can read it top to bottom. The weakness is on the last two lines: the data is open, so any code anywhere can put the account in a state the functions would never allow. The rules (no overdraft) live in the functions, but nothing forces callers to use them.<\/p>\n
Now the object-oriented version:<\/p>\n
class Account:\n    def __init__(self, owner, balance=0):\n        self.owner = owner\n        self._balance = balance\n\n    @property\n    def balance(self):\n        return self._balance\n\n    def deposit(self, amount):\n        if amount <= 0:\n            raise ValueError(\"amount must be positive\")\n        self._balance += amount\n\n    def withdraw(self, amount):\n        if amount > self._balance:\n            raise ValueError(\"insufficient funds\")\n        self._balance -= amount\n\nacc = Account(\"Alice\", 100)\nacc.deposit(50)\nacc.withdraw(30)\nprint(acc.balance)\ntry:\n    acc.balance = -999\nexcept AttributeError as e:\n    print(\"AttributeError:\", e)\n<\/code><\/pre>\n
Output:<\/p>\n
120\nAttributeError: property 'balance' of 'Account' object has no setter\n<\/code><\/pre>\n
The rules now travel with the data. Callers read acc.balance<\/code> but have to go through deposit<\/code> and withdraw<\/code> to change it. That is encapsulation. One honest caveat: Python only marks _balance<\/code> as private by convention, so determined code can still write acc._balance<\/code>. Java, C++ and C# enforce private fields at compile time.<\/p>\n
The key differences<\/h2>\n\n\n\n\n\n\n\n\n\n\n
Aspect<\/th>\nProcedural<\/th>\nObject-oriented<\/th>\n<\/tr>\n<\/thead>\n
Main unit<\/td>\nFunction<\/td>\nObject (class instance)<\/td>\n<\/tr>\n
Data and behavior<\/td>\nSeparate; functions receive data as arguments<\/td>\nBundled; methods work on the object’s own fields<\/td>\n<\/tr>\n
Who guards the rules<\/td>\nConvention: callers are expected to use the right functions<\/td>\nThe class, by controlling how state changes<\/td>\n<\/tr>\n
Adding a new kind of thing<\/td>\nEdit every function that branches on type<\/td>\nAdd a new class that implements the same methods<\/td>\n<\/tr>\n
Adding a new operation<\/td>\nAdd one function<\/td>\nEdit every class (or add a visitor-style helper)<\/td>\n<\/tr>\n
Typical weak spot<\/td>\nShared mutable state spreads as the program grows<\/td>\nToo many classes and layers for simple problems<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The two “adding” rows are the heart of the trade-off, so here is what they look like in code.<\/p>\n
Where each style wins: adding types versus adding operations<\/h2>\n
Suppose you compute the area of different shapes. Procedurally, you tag each shape and branch on the tag:<\/p>\n
import math\n\ndef area(shape):\n    if shape[\"kind\"] == \"circle\":\n        return math.pi * shape[\"r\"] ** 2\n    if shape[\"kind\"] == \"rect\":\n        return shape[\"w\"] * shape[\"h\"]\n    raise ValueError(\"unknown shape\")\n\nprint(round(area({\"kind\": \"circle\", \"r\": 1}), 2), area({\"kind\": \"rect\", \"w\": 2, \"h\": 3}))\n<\/code><\/pre>\n
With OOP, each class answers the question itself. This is polymorphism: the caller calls .area()<\/code> and doesn’t care which class it holds.<\/p>\n
class Circle:\n    def __init__(self, r): self.r = r\n    def area(self): return math.pi * self.r ** 2\n\nclass Rect:\n    def __init__(self, w, h): self.w, self.h = w, h\n    def area(self): return self.w * self.h\n\nclass Triangle:  # added later, no existing code touched\n    def __init__(self, b, h): self.b, self.h = b, h\n    def area(self): return 0.5 * self.b * self.h\n\nfor s in [Circle(1), Rect(2, 3), Triangle(4, 5)]:\n    print(type(s).__name__, round(s.area(), 2))\n<\/code><\/pre>\n
Output:<\/p>\n
3.14 6\nCircle 3.14\nRect 6\nTriangle 10.0\n<\/code><\/pre>\n
Adding Triangle<\/code> required no change to existing code. In the procedural version you would edit area<\/code>, and every other function that branches on kind<\/code> (perimeter<\/code>, draw<\/code>, and so on). So OOP is easier when new types<\/em> keep appearing.<\/p>\n
The reverse is also true. If you need a new operation<\/em> across all shapes, such as to_json<\/code>, the procedural version needs one new function, while the OOP version needs a new method in every class. Neither style makes both kinds of change cheap, and knowing which kind of change your project will see most often is the real design decision.<\/p>\n
Common misconceptions<\/h2>\n