Skip to main content

Why OOP? Classes & Objects

Before touching any code syntax, we must answer one fundamental question: Why did programmers invent Object-Oriented Programming (OOP), and what exact problem does it solve?


1. Learning Objective

By the end of this lesson, you will understand:

  • The real-world problem of procedural programming (loose variables floating everywhere).
  • What a Class really is conceptually (a design blueprint, not data).
  • What an Object really is in memory (a physical entity created from a blueprint).
  • Why dictionaries alone are not enough for complex applications.

2. Why This Concept Exists

Imagine you are building a student management system for a university with 5,000 students.

Without OOP, you have to store data using separate variables and standalone functions:

# Student 1
student1_name = "Sai"
student1_age = 21
student1_marks = 85

# Student 2
student2_name = "Ananya"
student2_age = 20
student2_marks = 92

def print_student(name, age, marks):
print(f"Student: {name}, Age: {age}, Marks: {marks}")

The Problem: Chaos at Scale

  1. Loose Variables: With 5,000 students, you would have 15,000 loose variables floating randomly in memory.
  2. No Data Protection: Any function can accidentally overwrite student1_age = -500.
  3. No Automatic Grouping: Data (name, age) and behavior (print_student) are disconnected.

Object-Oriented Programming was invented to bundle related Data (Variables) and Actions (Functions) together inside a single, neat package called an Object.


3. Common Beginner Confusions

Confusion 1: "Why do we need classes? Why can't we just use dictionaries?"

  • Answer: A dictionary can hold data ({"name": "Sai", "age": 21}), but it cannot enforce a structure or attach custom actions. If one dictionary spells "name" and another spells "student_name", your code breaks. A Class enforces a mandatory structure and binds actions (methods) directly to that data.

Confusion 2: "Is a Class the same thing as an Object?"

  • Answer: No! A Class is a paper blueprint. An Object is the physical house built on land. You cannot live inside a paper blueprint.

4. Mental Model: Blueprint vs. Real House

Think of the relationship between a Class and an Object using two relatable real-world analogies:

  1. House Blueprint vs. Physical House:

    • Class = House Blueprint: Drawn on paper. It defines that every house must have 2 bedrooms, 1 kitchen, and a front door. The blueprint takes up no land space.
    • Object = Physical House: Built on actual land using cement and bricks. House 101 and House 102 are two distinct physical objects built from the same blueprint.
  2. Cookie Cutter vs. Cookie:

    • Class = Metal Cookie Cutter: Defines the star shape. You cannot eat the metal cutter.
    • Object = Baked Cookie: Stamped out of dough using the cutter. You can bake 50 individual cookies from 1 cutter.

5. Internal Python Execution Flow

When Python reads code that defines a Class and creates an Object, here is what happens internally behind the scenes:

Code Written: s1 = Student()



1. Python reads the 'class Student' blueprint definition.
2. Python allocates a fresh block of memory in Heap Space.
3. Python constructs an empty Object in that memory block.
4. Python assigns a unique Memory Address (e.g., 0x7FFF) to the Object.
5. Python stores that Memory Address inside the variable 's1'.

Note: The variable s1 does NOT hold the object itself; it holds a reference (memory address) pointing to where the object lives in RAM.


6. Memory Visualization

Let's look at how RAM is organized when creating an Object:

RAM Memory Visualization (Stack vs Heap)

STACK MEMORY (References)

s1  =>  0x7FFF

HEAP MEMORY (Actual Objects)

Object Memory Address: 0x7FFF
Type: <class Student>
Attributes: (empty initially)
  • Green (Heap): Holds the actual physical Object data in RAM.
  • Purple (Stack): Holds the variable reference storing the memory address 0x7FFF.

7. Python Code Implementation

Now that you understand the mental model and memory layout, here is the minimal Python code:

# 1. Defining the Blueprint (Class)
class Student:
pass # Placeholder for empty class body

# 2. Creating an Object (Instance) from the Class
s1 = Student()

# 3. Inspecting the Object and its Type
print(s1)
print(type(s1))

Output:

<__main__.Student object at 0x0000021F7B8E07F0>
<class '__main__.Student'>

8. Line-by-Line Execution Analysis

Let's trace s1 = Student() line by line:

Line: class Student:

  • What Python does: Registers a new data type template named Student in global memory.
  • Memory impact: Zero object instances are created yet.

Line: s1 = Student()

  • Right side Student(): Python allocates a new empty memory box in Heap RAM.
  • Left side s1 =: Python stores the memory address of that Heap box inside the variable s1 in Stack RAM.
  • Why Python does this: To decouple variable names from actual object memory blocks.

9. Before / After Memory Visualization

Before Executing s1 = Student()

  • Stack: Empty (s1 does not exist).
  • Heap: Empty (No Student object exists).

After Executing s1 = Student()

  • Stack: s1 contains reference memory address 0x0000021F7B8E07F0.
  • Heap: Address 0x0000021F7B8E07F0 contains a live Student object.

10. Illustration Prompt for Diagram Generation

If you want to visualize this concept in an Excalidraw-style diagram generator, use this prompt:

Excalidraw Diagram Prompt: A clean white-background hand-drawn diagram showing Python Class vs Object memory layout. On the left side, draw a box labeled "Stack Memory (Variables)" containing a purple box labeled "s1" with an arrow pointing right labeled "0x7FFF". On the right side, draw a large green rounded container labeled "Heap Memory (Objects)" at address "0x7FFF". Inside the green container, draw an object labeled "Student Instance". Include a blueprint drawing above labeled "Class Student (Template)" with a dashed arrow showing "instantiates". Use minimalist colors: Green for Objects, Purple for Variable References, Blue for Execution Arrows. Hand-drawn clean aesthetic.


Quick Summary

  • Procedural code creates loose, unmanaged variables that break at scale.
  • OOP groups related data and actions together inside objects.
  • A Class is a paper blueprint (template).
  • An Object is a physical entity allocated in Heap RAM.
  • A variable like s1 holds a memory address reference, not the physical object itself.

What's Next?