10. Introduction to Object-Oriented Thinking

Modelling the world as objects

So far we have kept data (variables, lists) and behaviour (functions) in separate places. Object-oriented programming (OOP) bundles them together into objects: self-contained units that hold both the data describing something and the operations that act on that data. This mirrors how we think about the real world — a car has a colour and speed, and can accelerate and brake.

Dog (class) attributes: name, breed methods: bark(), sit() blueprint → instances rex (object) name="Rex" breed="Collie" bella (object) name="Bella" breed="Boxer"

Class vs object

The two core words confuse everyone at first, so anchor them with an analogy. A class is a blueprint — a general description of what every dog has and can do. An object (or instance) is a specific thing built from that blueprint — this dog named Rex. One class, many objects: the blueprint for a house is drawn once, but you can build many houses from it, each with its own address and colour.

Attributes and methods

An object's data are its attributes (sometimes called properties or fields) — name, breed, age. Its behaviours are its methods — functions that belong to the object, like bark() or sit(). A method can read and change the object's own attributes, which is exactly the point of bundling them together.

class Dog:
    def __init__(self, name, breed):
        self.name = name        # an attribute
        self.breed = breed

    def bark(self):             # a method
        print(self.name + " says woof!")

rex = Dog("Rex", "Collie")      # create an object
bella = Dog("Bella", "Boxer")   # another, independent object
rex.bark()                      # Rex says woof!
print(bella.breed)              # Boxer

Notice that rex and bella are built from the same class yet hold their own values. Calling rex.bark() uses Rex's name, not Bella's, because the method works on the specific object it is called on.

Encapsulation (a gentle first look)

Encapsulation is the principle of keeping an object's data and the code that manages it together, and controlling access from outside. The idea: an object exposes a tidy set of methods — a public "control panel" — while hiding its inner workings. You can drive a car through the steering wheel and pedals without knowing how the engine works; if the engine is redesigned, your driving does not change. In code, this means other parts of the program interact through methods rather than poking at attributes directly, so you are free to change the internals later without breaking everyone else.

Why think in objects?

  • Organisation: related data and behaviour live in one place instead of scattered across the program.
  • Reuse: define a class once, create as many objects as you need.
  • Modelling: code mirrors the real-world things it represents, so it is easier to reason about.
  • Maintainability: encapsulation lets you change an object's internals without disturbing the rest of the system.

OOP is a large topic with more ideas ahead — inheritance, polymorphism and more — but it all rests on this foundation: an object is data plus behaviour, built from a class blueprint, interacted with through its methods.

Key idea: a class is a blueprint describing attributes (data) and methods (behaviour); objects are concrete instances of that blueprint, and encapsulation keeps each object's data and logic bundled behind a clean interface.