Saras Growth Space

Posted on May 19

LLD Object-Oriented Design: Thinking in Objects, Not Code

#lld #systemdesign #softwareengineering #codinginterview

Low-Level Design is not about writing classes or memorizing patterns.

It is about a fundamental shift in thinking:

Designing systems as a collection of responsibilities, not functions.

Most beginners start with code:

functions
APIs
logic

But real system design starts before that. It starts with how you model the problem itself.

Why Object Thinking Matters

A system designed around functions tends to:

scatter logic across multiple places
lose control over state
become hard to modify safely

A system designed around objects tends to:

keep data and behavior together
enforce rules at one place
make behavior predictable

The difference is not syntactic—it is structural.

The Wrong Mental Model (Function-Centric Design)

deposit(account, amount)
withdraw(account, amount)
update_balance(account)

At first glance, this looks simple and readable.

But it raises deeper design issues:

Who owns the account state?
Where are validation rules enforced?
What prevents invalid updates?
What happens when business rules change?

The logic is distributed, not owned.

The Correct Mental Model (Object-Centric Design)

class BankAccount:
    def deposit(self, amount):
        ...

    def withdraw(self, amount):
        ...

Now the design changes fundamentally:

state and behavior are encapsulated together
rules are enforced inside the object
external code interacts through controlled methods

The system becomes self-governing at the object level.

Core Idea: Responsibility Ownership

The most important question in object-oriented design is:

Which object owns this responsibility?

Not:

where should this function go
how should I structure files
how many layers should I create

Instead:

which entity is responsible for this behavior in the domain?

This shift determines the quality of the entire design.

Objects Represent Real-World Systems

A good mental model is to map systems into interacting entities:

Example: Food Delivery System

User → initiates actions
Restaurant → prepares food
Order → maintains lifecycle state
DeliveryPartner → fulfills delivery

Each object:

owns state
exposes behavior relevant to its responsibility
does not manage unrelated logic

Class vs Object (Core Understanding)

Class

A blueprint that defines structure and behavior.

Object

A real instance with actual state.

class BankAccount:
    def __init__(self, balance):
        self.balance = balance

Objects created from this class:

Account A → 5000
Account B → 12000

Same structure, different state.

The Most Important Rule in OOD

A class should represent a single, meaningful responsibility.

When a class:

handles too many responsibilities → it becomes fragile
knows too much about unrelated domains → it becomes hard to maintain

Good design is not about size. It is about focus.

A Practical Design Flow

Before writing code, a structured approach helps:

Understand the problem clearly
Identify core entities
Assign responsibilities to each entity
Define interactions between entities
Only then move to implementation

Skipping these steps leads to incorrect abstractions and redesign later.

Real Insight

In object-oriented design, correctness is not about syntax or patterns.

It is about:

clarity of responsibilities
consistency of state management
predictability of interactions

Good design is what remains stable when requirements change.

One-Line Takeaway

Object-oriented design begins when systems are modeled around responsibilities, not functions.

DEV Community