Classes, Objects, Identity, State, and Behavior

So far, we have learned:

Software Design
Engineering Mindset
Abstraction
Encapsulation
Modularity
Separation of Concerns
Coupling
Cohesion

These concepts apply to all software systems, regardless of programming paradigm.

Now we begin one of the most infleuntial paradigms in software engineering:

Object-Oriented Programming (OOP)

What exactly is an object?

Most beginners answer:

An object is an instance of a class.

While technically correct, this definition is almost useless for understanding OOP.

To master Low-Level Design, you must understand:

• Why objects exist
• What problems they solve
• How to think in objects
• How objects model real-world domains
• How objects collaborate
• How objects encapsulate state and behavior

Historical Context

Before OOP became popular, software was primarily written using:

Procedural Programming

Programs were structured around:

Functions
Procedures
Global Variables

Example:

double accountBalance = 1000;

void deposit(double amount)
{
    accountBalance += amount;
}

void withdraw(double amount)
{
    accountBalance -= amount;
}

At first glance this seems fine.

However, as systems grew:

More Data
More Functions
More Dependencies
More Complexity

Problems emerged.

The Procedural Problem

Imagine a banking system.

Data:

accountBalance
accountNumber
accountHolder

Functions:

deposit()
withdraw()
transfer()
printStatement()
calculateInterest()

Over time:

50 variables
100 functions
500 fnctions

Questions become difficult:

Which functions modify accountBalance?

Who owns accountNumber?

Can anyone modify accountHolder?

Data and behavior become disconnected.

The system becomes harder to understand.

The Big Idea Behind OOP

Object-Oriented Programming introduced a revolutionary idea:

Data and behavior that belong together should live together.

Instead of:

Data Here
Behavior There

we create:

Object = Data + Behavior

This creates a more natural representation of real-world entities.

What Is an Object?

Before defining an object formally. let's examine the world around us.

Consider:

Car
Bank Account
Customer
Employee
Book
Order
Elevator

These things share an interesting characteristic.

Each has:

Identity
State
Behavior

This observation forms the foundation of OOP.

The Three Pillars of an Object

Every object has:

Identity

State

Behavior

Understanding these deeply is essential.

Identity

Identity answers:

Which specific thing are we talking about?

Example:

Car #1
Car #2

Both may look identical.

Both may have:

Same Color
Same Model
Same Engine

Yet they are different cars.

Why?

Because they have different identities.

Real-World Example

Two users:

John
John

Same name.

Different identities.

Identity distinguish objects.

Software Example

User user1;
User user2;

Even if:

user1.name = "John";
user2.name = "John";

They remain distinct objects.

State

State answers:

What does the object currently know?

State is represented through data.

Example: Car

State:

Speed
Fuel Level
Engine Status
Mileage

Example: Bank Account

State:

Balance
Account Number
Account Holder

Software Example:

class User
{
public:
    std::string name;
    std::string email;
    int age;
};

These variables represent state.

Behavior

Behavior answers:

What can the object do?

Example: Car

Behavior:

Start Engine
Stop Engine
Accelerate
Brake

Example: Bank Account

Behavior:

Deposit
Withdraw
Transfer

Example: User

Behavior:

Login
Logout
Update Profile

Software Example:

class BankAccount
{
public:

    void deposit(double amount);

    void withdraw(double amount);

    void transfer(double amount);
};

These methods represent behavior.

Identity + State + Behavior

Together:

+----------------+
|     Object     |
+----------------+

Identity

State

Behavior

This is the fundamental OOP model.

What Is a Class?

A class is:

A blueprint used to create objects.

Or:

A class defines the structure and behavior that objects will have.

Real-World Analogy: House Blueprint

Blueprint:

Rooms
Doors
Windows

Not an actual house.

Just a description.

House:

Concrete Object

Built using the blueprint.

Similarly:

class User
{
};

// defines Blueprint
// while:

User user;
// creates Object

Class vs Object

Example:

Class:

class Car
{
public:
    std::string model;
};

Objects:

Car car1;
Car car2;
Car car3;

Each object has independent state.

Memory Perspective

Consider:

class User
{
public:
    std::string name;
    int age;
};

Class itself:

Blueprint Only

Objects:

User user1;
User user2;

Memory:

user1
+------------+
| John | 25  |
+------------+

user2
+------------+
| Alice| 30  |
+------------+

Separate state.

Same blueprint.

Modeling the Real World

One of OOP's primary goals:

Represent real-world concepts naturally.

Example: Library System

Real World:

Book
Member
Librarian
Loan

Software:

class Book {};
class Member {};
class Librarian {};
class Loan {};

The software model mirrors reality.

This process is called: Object Modeling

Thinking in Objects

Beginners think:

Functions
Algorithms
Variables

Experienced designers think:

Objects

Responsibilities

Interactions

Example:

Requirement:

User places order.

Begineer approach:

Create placeOrder function

Object-oriented approach:

User
Order
Cart
Payment

Question:

How should these objects collaborate?

This shift is critical.

Object Responsibilities

A responsibility is:

Something an object is responsible for knowing or doing.

Example: User

Knows:

Name
Email
Address

Can do:

Login
Logout
Update Profile

Example: Order

Knows:

Items
Price
Status

Can do:

Add Item
Cancel
Calculate Total

Good object design revolves around responsibilities.

Responsibility-Driven Design

Professional designers often ask:

Who should do this?

rather than:

Where should I write this code?

Example:

Calculate Order Total

Belongs to:

Order

Not:

User

Not:

Database

Not:

UI

This mindset leads to cleaner designs.

Object Interactions

Objects rarely work alone.

They collaborate.

Example: E-Commerce Checkout

Objects:

User
Cart
Order
PaymentService

Interaction:

User
  |
  v
Cart
  |
  v
Order
  |
  v
PaymentService

Systems emerge from object collaboration.

Text-Based Sequence Example

User
 |
 | Checkout
 v
Cart
 |
 | Create Order
 v
Order
 |
 | Process Payment
 v
PaymentService

This interaction model is central to LLD.