Let's Begin with a Tangible Example
Imagine building an enterprise School Management System. Our institution serves thousands of students—such as Rahim, Karim, Salim, Ayesha, and many others.
Now consider a critical dilemma: If we have 10,000 enrolled students, do we duplicate bespoke variables and functions 10,000 times across our codebase? Absolutely not. This is precisely why software engineering invented Classes and Objects.
01 What is a Class?
In crisp, formal engineering terms:
Before an architectural firm erects a modern skyscraper, architects draft an exact blueprint detailing the dimensions, materials, and structural load pathways. In the exact same way, before creating living objects in software, we define a Class.
- • name
- • age
- • student_id
- • enroll()
- • submit_assignment()
- • view_result()
02 Then What is an Object?
If the Class is the blueprint, then:
When the language runtime allocates heap memory according to the class specification and assigns distinct attribute values, an Object is born.
Notice: All three students originate from the identical Student class specification. Every one of them has fields for name, age, and ID. Yet each individual object manages its own private, isolated state.
03 A Classic Real-World Analogy: The House Blueprint
To permanently crystallize this mental model, consider residential architecture:
Architectural Blueprint (Class)
The architect's paper schematic specifies: 3 bedrooms, 2 bathrooms, 1 kitchen, and 1 living room. You cannot live inside a blueprint, sleep in its bedrooms, or cook on its schematic kitchen. It is an abstract specification.
Physical Houses (Objects / Instances)
Using that single blueprint, construction crews build 100 actual physical homes across different neighborhoods. Though sharing an identical floor plan, they are distinct physical entities: different physical locations, different owners, and different interior decorations.
04 The Anatomy of an Object: Identity, State, and Behavior
In computer science, any true object is rigorously characterized by three fundamental dimensions:
Every object in RAM occupies a unique memory address. Even if two students possess the exact same name ("Rahim") and age ("20"), they remain completely distinct entities. Mutating one never leaks or mutates the other.
The collection of values currently stored inside the object's instance fields. For a bank account, a balance of $50,000 is its current state. After withdrawing $10,000, the balance becomes $40,000—the object's state has mutated.
The defined actions an object is capable of performing. Methods inspect or mutate the object's internal state. For example, invoking deposit() modifies the account's balance state according to valid domain rules.
| Domain Entity | Identity | State (Attributes) | Behavior (Methods) |
|---|---|---|---|
| Bank Account | Account No (AC-101) | balance: 50000, status: "active" | deposit(), withdraw(), transfer() |
| Shopping Cart | Session ID (sess_982) | items: [...], total_price: 1250 | add_item(), remove_item(), clear() |
| Video Stream | Video ID (vid_771) | duration: 360s, is_playing: True | play(), pause(), seek(position) |
05 Working Code Walkthrough in Python
Let us observe how classes are formally defined and instantiated using modern Python syntax:
# 1. Define the Class Blueprint
class Student:
# Constructor: invoked automatically when instantiating a new object
def __init__(self, name, student_id, major):
self.name = name # Instance attribute (State)
self.student_id = student_id # Unique identifier
self.major = major # Academic department
self.enrolled_courses = [] # Initial dynamic state
# Defined Behavior (Method)
def enroll(self, course_name):
self.enrolled_courses.append(course_name)
print(f"[{self.name}] successfully enrolled in '{course_name}'.")
def introduce(self):
print(f"Hello, I am {self.name} (ID: {self.student_id}), majoring in {self.major}.")
# 2. Instantiate Living Objects from the Blueprint
s1 = Student("Rahim", 101, "Computer Science")
s2 = Student("Karim", 102, "Data Engineering")
# 3. Invoke Methods and Observe State Mutability
s1.introduce() # Output: Hello, I am Rahim (ID: 101), majoring in Computer Science.
s2.introduce() # Output: Hello, I am Karim (ID: 102), majoring in Data Engineering.
s1.enroll("Algorithms 101")
print(s1.enrolled_courses) # ['Algorithms 101']
print(s2.enrolled_courses) # [] — Karim's state remains completely untouched!
Observe three fundamental mechanics:
-
class Student:specifies the shape and capabilities of all students. -
s1 = Student(...)creates an independent instance with its own memory allocation. -
When invoking
s1.enroll(), onlys1's internal course list mutates.s2remains completely isolated.
06
Verifying Memory & Identity: id() and the is Operator
A common conceptual question arises: "If two distinct objects hold identical data in every field, are they the same object?"
The answer is an unequivocal No. Let us verify this directly in Python:
student_a = Student("Ayesha", 500, "Math")
student_b = Student("Ayesha", 500, "Math")
# Do they hold equal data values?
print(student_a.name == student_b.name) # True
# Are they the same physical instance in memory?
print(student_a is student_b) # False!
# Inspect their discrete memory addresses:
print(hex(id(student_a))) # e.g., 0x7f9a2b8c41f0
print(hex(id(student_b))) # e.g., 0x7f9a2b8c4d90 (Discrete memory cells!)
07 Are Classes Only for Physical Real-World Entities?
Beginners often assume classes can only represent tangible physical objects you can touch with your hands (such as cars, dogs, books, or people).
In production software engineering, the vast majority of classes actually model abstract conceptual and architectural components:
Tangible real-world items possessing physical presence:
Abstract software services, pipelines, and stateful processors:
A PaymentGateway has no physical embodiment in the real world. However, it holds vital state (API credentials, active session tokens) and executes mission-critical behavior (charge_card(), refund()). Therefore, it is an exemplary object.
08 Quick Mental Anchor: Recipe vs. The Cooked Meal
Whenever you need an instantaneous, foolproof heuristic to differentiate Class and Object, recall the culinary world:
Class = The Culinary Recipe
The printed recipe lists required ingredients and step-by-step instructions. But you cannot eat the recipe card for dinner!
Object = The Cooked Dish
Following that recipe, a chef serves a fragrant bowl of steaming biryani. It is tangible, distinct, and ready to be consumed!
Concept Verification
Test your understanding of Lesson 02
Question 1: Which statement accurately defines the relationship between a Class and an Object?
Question 2: If two independent Student objects have identical names and IDs, which statement is true?