What Is Object-Oriented Programming?

A City Built From Blueprints

Imagine you are the chief architect of a city. Before a single hospital is built, you draft a blueprint. That blueprint defines everything a hospital should have: an emergency room, operating theatres, a pharmacy, a reception desk. It describes what a hospital is — but it is not a hospital itself.

When the city decides to build three hospitals — one downtown, one in the suburbs, one near the airport — each is constructed from that same blueprint. Yet each hospital is its own physical reality: different address, different roster of doctors, different patients checked in today. The blueprint is shared; the buildings are individual.

This is the central idea of Object-Oriented Programming. The blueprint is a class. Each hospital built from it is an object (also called an instance). Every object follows the same structure defined by the class, but carries its own data.

What Is OOP?

Object-Oriented Programming (OOP) is a programming paradigm that organises code around objects — bundles of data and the functions that operate on that data — rather than around sequences of instructions.

A paradigm is simply a style or way of thinking about how to write programs.

The older alternative is procedural programming, where you write a series of step-by-step instructions and pass data around as separate variables. OOP keeps data and behaviour together in one logical unit.

The Four Pillars of OOP

You will explore each pillar in depth in later lessons. For now, keep the table as a mental map.

Procedural vs OOP: The Same Problem, Two Approaches

Problem: Model a bank account that can deposit, withdraw, and show a balance.

Procedural Style

# Procedural approach — data and logic are separate
balance = 0.0

def deposit(amount):
    global balance          # Must reach for the global variable
    balance += amount

def withdraw(amount):
    global balance
    if amount <= balance:
        balance -= amount
    else:
        print("Insufficient funds")

def show_balance():
    print(f"Balance: ${balance:.2f}")

deposit(500)
withdraw(200)
show_balance()

Output:

Balance: $300.00

The logic works, but the balance variable is floating free. Any part of the program can accidentally set balance = -9999 and nothing will stop it.

OOP Style

# OOP approach — data and logic live together inside the class
class BankAccount:
    def __init__(self, owner):
        self.owner = owner      # Each account has its own owner
        self.balance = 0.0      # Each account has its own balance

    def deposit(self, amount):
        self.balance += amount  # Operates on THIS account's balance

    def withdraw(self, amount):
        if amount <= self.balance:
            self.balance -= amount
        else:
            print("Insufficient funds")

    def show_balance(self):
        print(f"{self.owner}'s balance: ${self.balance:.2f}")


account = BankAccount("Alice")   # Create an object from the class
account.deposit(500)
account.withdraw(200)
account.show_balance()

Output:

Alice's balance: $300.00

Now the balance belongs to the account object. You can create a second account for Bob and both exist independently without any global variable collision.

Line-by-line explanation:

• class BankAccount: — defines the blueprint named BankAccount
• def __init__(self, owner): — the constructor, called automatically when you create an object; self always refers to the specific object being created
• self.owner = owner — stores the owner value as an attribute of this particular object
• account = BankAccount("Alice") — builds one object (instance) from the blueprint
• account.deposit(500) — calls the deposit method on Alice's account only

When OOP Makes Sense vs When It Is Overkill

OOP shines when your program models things — entities that have state (data) and behaviour (actions). It becomes overhead when you just need to transform some data and move on.

Python Class = Blueprint, Object = Instance

class Dog:               # This is the blueprint (class)
    def __init__(self, name, breed):
        self.name = breed
        self.breed = breed

    def bark(self):
        print(f"{self.name} says: Woof!")

rex = Dog("Rex", "Labrador")    # rex is one object (instance)
bella = Dog("Bella", "Poodle")  # bella is a completely separate object

rex.bark()    # Rex says: Woof!
bella.bark()  # Bella says: Woof!

Both rex and bella are built from the same Dog class, but they are independent objects with their own data. Changing rex.name has zero effect on bella.

A Brief History of OOP

Python's flexibility is noteworthy: it supports procedural, OOP, and functional styles. You are not forced into OOP, which means when you do use it, you are choosing it because it genuinely fits the problem.

Key Takeaways

• A class is a blueprint; an object is a concrete instance built from that blueprint.
• OOP bundles data and behaviour together, reducing accidental interference between parts of your program.
• The four pillars — Encapsulation, Inheritance, Polymorphism, Abstraction — are tools, not rules. Use them where they clarify, not where they complicate.
• Python supports OOP naturally but does not force it. Choose the right tool for the job.