How to Think in Objects

Why Most Developers Struggle with LLD

Ask a developer:

Design a Library Management System.

Most people immediately start writing:

class Book {}
class User {}
class Library {}

But if you ask:

Why is Library a class?

Many cannot answer.

They are creating classes, not modeling reality.

This is the biggest mistake in LLD.

The Core Idea

Before understanding classes, we must understand objects.

Everything in Object-Oriented Design revolves around one question:

What objects exist in this domain?

What Is an Object?

An object is:

A thing that has:

Identity
State
Behavior

Every real-world objects follows this rule.

Example: Car

Identity:

Car #112

State:

Speed = 75
Fuel = 45%
Engine = ON

Behavior:

start()
stop()
accelerate()
brake()

Example: User

Identity:

User Id = 977

State:

Name = TheJat
Email = thejat@thejat.in
Status = Active

Behavior:

login()
logout()
changePassword()

The Three Pillars of Every Object

1 Identity:

Identity answers:

Who am I?

Example:

User #77
User #78

Both may have same name.

Still different users.

Because identity differs.

Example:

Two people:

Name = Nathu
Age = 25

Can still be different persons.

Why?

Because identity differs.

In software:

userId
email
uuid
deviceId

often represent identity.

2 State

State answers:

What do I currently know?

Example:

Bank Account

State:

Balance = 500
Account Statis = Active
Currency = INR

When balances changes:

500 -> 700

State changes.

Object remains same.

3 Behavior

Behavior answers:

What can I do?

Bank Account

Behavior:

deposit()
withdraw()
transfer()

State should change through behavior.

Not directly.

Bad:

account.balance = 0;

Good:

account.withdraw(100);

Object Formula

Every object can be represented as:

Object = Identity + State + Behavior

Memorize this.

It appears everywhere in LLD.

Example: WhatsApp Message

Identity:

messageId

State:

status
content
timestamp

Behavior:

markDelivered()
markRead()
delete()

Not Everything Should Be an Object

A very common mistake.

Example:

Requirement:

User sends notification.

Many beginners create:

class User {}
class Notification {}
class Sender {}
class SendManager {}
class NotificationEngine {}
class NotificationHandler {}
class NotificationExecutor {}

Object explosion.

Question

Does every noun become a class?

Answer: No

Object Discovery Technique

Ask:

Does it have identity?

Does it have state?

Does it have behavior?

If yes:

Likely an object.

Example:

Book:

Identity => ISBN

State => title
		author
		available

Behavior => borrow()
			return()

Object.

Color:

Identity => No

State => Red
		Green
		Blue

Behavior => None

Not an object.

Usually a value.

Entity vs Value Object

Entity

Entity has identity.

Example:

User
Order
Device
Book
TransferSession

Two users are different, even if data is same.

User #1
User #2

Entities are identity-driven.

Value Object

Value objects have no identity.

They are defined by values.

Example:

Address: Street
		City
		Country

Two addresses:

Street = A
City = B
Country = C

Same values.

Therefore same object.

Identity doesn't matter.

Example

Entity:

class User {
   id
   name
}

Value Object:

class Address {
   city
   state
   country
}

Why Value Objects Matter

They reduce complexity.

Example:

Instead of:

user.city
user.state
user.country

Use:

user.address

Cleaner design.

Objects Collaborate

Real systems are not isolated objects.

Objects work together.

Example:

Food Delivery

Customer
      ↓
Order
      ↓
Restaurant
      ↓
Payment

Objects collaborate.

This collaboration forms:

Object Graph

Object Graph

Example:

Customer
   |
   +---- Orders
            |
            +---- Payment
            |
            +---- Items

This is object modeling.

Thinking in Responsibilities

Most beginners ask:

What methods should I create?

Wrong question.

Ask:

What responsibility does this object own?

Example:

Order

Responsibilities:
	Calculate Total
	Track Status
	Store Items

Not:

Send Email
Process Salary
Upload Files

Wrong responsibilities.

The Responsibility Rule

Every behavior should belong to the object that owns the data.

Example:

Bad:

class OrderService {
	calculateTotal(order)
}

Good:

class Order {
	calculateTotal()
}

Because Order owns items.