Object-Oriented Programming
Everything Is a Blueprint
There is a blueprint for a house. The blueprint defines how many rooms it has, where the doors go, the size of the windows. But the blueprint is not a house — it is the plan from which houses are built. Ten houses can be built from one blueprint, each with its own colour and furniture, yet all sharing the same fundamental design.
In object-oriented programming (OOP), that blueprint is called a class, and each house built from it is called an object (or an instance). OOP is a way of organising code so that related data and behaviour travel together — just as a real-world dog carries its own name, age, and the ability to bark.
Classes and Objects
A class defines two things:
- Attributes — the data an object holds (a dog's name, its age, its breed)
- Methods — the actions an object can perform (
bark(),fetch(),eat())
Once a class is defined, you can create as many objects from it as you need. Each object gets its own copy of the attribute values, but all share the same method definitions.
In pseudocode:
CLASS Dog
ATTRIBUTE name
ATTRIBUTE age
METHOD bark()
OUTPUT name, " says: Woof!"
ENDMETHOD
ENDCLASS
rex ← NEW Dog("Rex", 3)
bella ← NEW Dog("Bella", 5)
rex.bark() // Rex says: Woof!
bella.bark() // Bella says: Woof!
rex and bella are separate objects — each holds its own name and age — but both use the same bark() method defined once in the class. If the bark behaviour needs to change, updating the class updates every Dog at once.
The Four Pillars of OOP
Object-oriented programming is built on four core ideas.
1. Encapsulation
Encapsulation means bundling an object's data and the methods that operate on that data together inside the class. It also means hiding the internal details — other parts of the program interact with an object through its methods rather than reaching directly into its data. This is like a car: you use the steering wheel and pedals without needing to understand the engine internals. The engine is encapsulated; only a clean interface is exposed.
2. Inheritance
Inheritance lets one class build on another. A Dog class might extend an Animal class, automatically gaining Animal's attributes and methods, then adding its own on top.
CLASS Animal
ATTRIBUTE name
METHOD breathe()
OUTPUT name, " breathes"
ENDMETHOD
ENDCLASS
CLASS Dog EXTENDS Animal
METHOD bark()
OUTPUT name, " says: Woof!"
ENDMETHOD
ENDCLASS
rex ← NEW Dog("Rex")
rex.breathe() // Rex breathes (inherited from Animal)
rex.bark() // Rex says: Woof! (Dog's own method)
Inheritance avoids duplication: write breathe() once in Animal and every animal subclass — Dog, Cat, Bird — gets it automatically. Adding a new animal type means writing one new class, not rewriting shared logic.
3. Abstraction
Abstraction hides complexity behind a simple interface. When you call rex.bark(), you do not need to know exactly how the bark is produced — only the method's name and what it does. Abstraction is how OOP lets programs grow large without becoming unmanageable. It connects directly to the computational thinking idea of abstraction: focus on what matters, ignore what does not.
4. Polymorphism
Polymorphism (meaning "many shapes") means different classes can respond to the same method name in their own way. A Cat and a Dog both have a speak() method, but the cat meows and the dog barks. Code that calls speak() on any animal works the same way regardless of which specific type it is dealing with — each object knows how to handle the call in its own appropriate fashion.
Why OOP Matters
Most modern software — websites, mobile apps, games — is written using OOP. It organises large codebases into manageable chunks, mirrors how humans think about the world (objects with properties and behaviour), and makes code easier to test and extend. The direct connections to other ideas are everywhere: methods are functions and procedures that belong to a class; designing a system as classes is a form of decomposition; hiding the insides of objects is abstraction made concrete.
Without OOP, a banking app might have dozens of functions all operating on the same raw data, each one depending on the exact format of that data. With OOP, a BankAccount class encapsulates its own balance and exposes deposit(), withdraw(), and getBalance() — anyone adding a new feature works through those methods rather than manipulating the raw data directly. The result is code that is far easier to test and debug, because each class is a self-contained unit.
Try It Yourself
Design a BankAccount class on paper. What attributes would it need? (Hint: a balance and an owner name.) What methods would make sense? (deposit(), withdraw(), getBalance().) Now create two account objects with different owners and trace what happens when both call deposit(100). Notice that each object's balance updates independently — they share the method definition but their data is separate. This simple design appears, almost unchanged, in real banking software.
Worked Example — A Class with a Meaningful Method
Here is a Rectangle class that stores its own data and can calculate from it:
CLASS Rectangle
ATTRIBUTE width
ATTRIBUTE height
METHOD area()
RETURN width * height
ENDMETHOD
METHOD perimeter()
RETURN 2 * (width + height)
ENDMETHOD
ENDCLASS
r1 ← NEW Rectangle(5, 3)
r2 ← NEW Rectangle(10, 2)
OUTPUT r1.area() // 15
OUTPUT r2.area() // 20
OUTPUT r1.perimeter() // 16
Both rectangles use the same area() and perimeter() methods. Change those formulas once in the class and both objects benefit. Neither method needs to know anything about the other — each is focused, testable, and reusable. This is the day-to-day payoff of object-oriented design.
Key Words
- Class — a blueprint defining the attributes and methods shared by all objects of that type
- Object / instance — a specific thing created from a class, with its own attribute values
- Attribute — a piece of data an object stores (its state)
- Method — a function that belongs to a class and operates on its objects
- Encapsulation — bundling data and methods together; hiding internal details
- Inheritance — a subclass automatically gaining the attributes and methods of its parent class
- Abstraction — exposing a simple interface while hiding complexity
- Polymorphism — different classes responding to the same method name in their own way