Classes and Objects — The Mental Model

Classes and Objects — The Mental Model

You’ve been using objects since lesson one — "hello".upper(), my_list.append(x) — strings and lists are objects. Now you learn to build your own, which is how every large codebase stays organized.

The mental model: blueprint vs buildings

Think of a blueprint for a house:

• The blueprint defines: every house has rooms, a door, an address
• Each house built from it has its own actual rooms, door, and address

A class is the blueprint. An object (or “instance”) is each real house built from it:

# The blueprint
class Student:
    pass        # "pass" means "empty for now" — a legal placeholder

# Three real students from one blueprint
s1 = Student()
s2 = Student()
s3 = Student()

print(type(s1))      # <class '__main__.Student'>
print(s1 == s2)      # False — different objects, same blueprint

One class, many objects — each independent. Change s1’s data and s2 doesn’t notice. This is why apps are built this way: one Student blueprint, thousands of student objects.

Objects hold: data + behavior

Every object combines two things:

• Data (attributes) — what it has: name, age, marks
• Behavior (methods) — what it does: introduce(), study()

You’ve used both forever:

"hello".upper()          # upper = a behavior (method) of strings
my_list.append(5)        # append = a behavior of lists

Now you’ll design both:

class Student:
    def introduce(self):
        print("Hi, I'm a student!")

s1 = Student()
s1.introduce()       # Hi, I'm a student!

A method is a function defined inside a class — called with a dot: object.method().

Adding data to objects (the quick-and-dirty way)

Python lets you attach data to any object directly:

class Student:
    pass

s1 = Student()
s1.name = "Aarav"       # attach an attribute
s1.marks = 92

print(s1.name)          # Aarav
print(s1.marks)         # 92

It works — and it’s how you’ll first feel the object idea. But it has a flaw: nothing forces every student to have a name and marks. The professional way — the __init__ constructor — fixes that in the next lesson.

Why OOP? (the honest answer for beginners)

At small scale, functions and dicts work fine — you’ve built real apps without classes. OOP earns its keep when:

1. Many things share the same shape — 500 students, each with name/marks/behavior. One class defines the shape once.
2. Data and the logic belong together — a student’s calculate_average() lives with their marks, not in some distant function.
3. You’re reading big codebases — Streamlit, requests, every framework is classes. OOP is reading comprehension for real code.

Don’t panic about using it perfectly. This module’s goal: read classes comfortably and write simple ones. That alone unlocks every framework tutorial on the internet.

The vocabulary card

✅ Checkpoint

1. What’s the difference between a class and an object? (Blueprint vs real instance)
2. Are s1 and s2 from the same class equal? (No — different objects)
3. What’s a method? (A function defined inside a class, called with a dot)
4. What does pass do in a class body? (Placeholder — “empty for now”)

Next: __init__ and self — giving every object its data properly.