15 min read OOP Foundations Lesson 02 (of 12)
Course 04 · Part 1 — The OOP Mindset & Foundations

What are Classes & Objects?

From conceptual architectural blueprints to living memory instances

In our previous lesson, we explored the philosophical essence of Object-Oriented Programming—organizing real-world complexity into autonomous, bounded units. But how are these objects brought to life inside computer memory? How do we instantiate thousands of collaborating components without drowning in repetitive code? In this lesson, we unpack the two foundational pillars of OOP: Classes and Objects.

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.

Common Attributes (Data): Name, age, student ID, grade level, email, blood group
Common Operations (Actions): Enroll in course, submit assignment, log attendance, view transcript

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:

A Class is an architectural blueprint or template used to construct Objects of the same category. It establishes the exact contract of what attributes (data) those objects will hold and what behaviors (methods) they will be capable of performing.

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.

What Does the Student Class Blueprint Look Like?
Attributes (State / Data):
  • • name
  • • age
  • • student_id
  • • email
Behaviors (Actions / Methods):
  • • enroll()
  • • submit_assignment()
  • • view_result()
Remember: At this stage, no actual student exists in memory! We have merely defined an architectural specification describing what any future student object will look like and how it will act.

02 Then What is an Object?

If the Class is the blueprint, then:

An Object is a living, concrete Instance created from that Class blueprint in computer memory.

When the language runtime allocates heap memory according to the class specification and assigns distinct attribute values, an Object is born.

Student Class (The Blueprint)
Rahim Object
name: "Rahim"
age: 20
id: 101
Karim Object
name: "Karim"
age: 22
id: 102
Salim Object
name: "Salim"
age: 21
id: 103

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.

Permanent Mental Anchor
Class = Specification / Type   |   Object = Concrete Instance / Allocated Entity

04 The Anatomy of an Object: Identity, State, and Behavior

In computer science, any true object is rigorously characterized by three fundamental dimensions:

1. Identity (Unique Memory Reference)

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.

2. State (Current Data Values)

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.

3. Behavior (Methods & Operations)

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.

Tripartite Anatomy Across Common Software Domains
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:

student_model.py Python 3.x
# 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(), only s1's internal course list mutates. s2 remains 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!)
Software Engineering Insight: Two identical twin brothers may share genetics, appearance, and birthdates, but in a hospital registry, they are distinct patients. Administering medicine to one does not cure the other. This independent identity provides the rock-solid boundary guarantees essential for complex distributed software.

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:

Physical Domain Entities

Tangible real-world items possessing physical presence:

Car Student Product Employee
Conceptual System Entities

Abstract software services, pipelines, and stateful processors:

PaymentGateway UserSession EmailNotifier PDFReportBuilder

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?

Key Takeaways

Blueprint vs Instance: A Class is the type definition; an Object is a concrete living entity allocated in memory.
Tripartite Anatomy: Every object is defined by Identity (memory address), State (attributes), and Behavior (methods).
Structural Reuse: By declaring a class once, we can instantiate millions of isolated objects without duplicating logic.
Conceptual Modeling: Classes model both tangible physical entities (cars, users) and conceptual services (payment gateways, sessions).