Tech With Galvan

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:

code

# 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:

code

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

Now you'll design both:

code

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:

code

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:

Many things share the same shape — 500 students, each with name/marks/behavior. One class defines the shape once.

Data and the logic belong together — a student's calculate_average() lives *with* their marks, not in some distant function.

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

Term	Meaning	Example
Class	The blueprint	`class Student:`
Object / instance	One real thing from the blueprint	`s1 = Student()`
Attribute	Data attached to an object	`s1.name`
Method	A function attached to a class	`s1.introduce()`
Instantiation	Creating an object from the class	`Student()`

✅ Checkpoint

What's the difference between a class and an object? *(Blueprint vs real instance)*

Are s1 and s2 from the same class equal? *(No — different objects)*

What's a method? *(A function defined inside a class, called with a dot)*

What does pass do in a class body? *(Placeholder — "empty for now")*

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