DEV Community: Saras Growth Space

LLD Object-Oriented Design: Dependency Injection (Decoupling System Design)

Saras Growth Space — Tue, 26 May 2026 15:00:00 +0000

After defining contracts using interfaces and abstract classes, the next problem appears naturally in real systems:

How do we connect all these components without tightly coupling them?

This is where Dependency Injection (DI) becomes essential.

The Problem Without Dependency Injection

When a class creates its own dependencies, it becomes tightly coupled.

Example

class OrderService:
    def __init__(self):
        self.payment = CardPayment()

What’s wrong here?

OrderService depends on a specific implementation
You cannot easily switch payment methods
Testing becomes difficult
Changes in one class affect others

This creates rigid systems.

What is Dependency Injection?

Dependency Injection means:

Providing dependencies from the outside instead of creating them inside the class.

Correct Design

class OrderService:
    def __init__(self, payment):
        self.payment = payment

Now the dependency is injected externally.

Usage

service = OrderService(CardPayment())

service = OrderService(UpiPayment())

What Changed?

OrderService no longer decides what payment system to use
responsibility is moved outside
system becomes flexible

Why Dependency Injection Matters

1. Loose Coupling

Classes do not depend on concrete implementations.

2. Easy Testing

Mock objects can replace real dependencies.

3. Flexibility

You can change behavior without modifying core logic.

Real System Example

Notification System

class NotificationService:
    def __init__(self, notifier):
        self.notifier = notifier

    def notify(self, message):
        self.notifier.send(message)

Now different implementations can be injected:

EmailNotifier
SmsNotifier
PushNotifier

Key Design Insight

Classes should focus on what they do, not what they depend on.

Dependency Injection vs Object Creation

Without DI	With DI
class creates dependencies	dependencies passed externally
tight coupling	loose coupling
hard to test	easy to test
rigid design	flexible design

Where Object Creation Should Happen

If classes don’t create dependencies, then who does?

Caller
Factory
Composition Root (central setup layer)

This separation is critical for clean architecture.

Common Mistake

Beginners often:

mix creation logic inside business classes
overuse DI without structure
confuse DI with factories

Important Clarification

Dependency Injection is NOT:

a framework
a design pattern for creation

It is a design principle for decoupling.

Design Principle

Depend on abstractions, not concrete implementations — and receive dependencies instead of creating them.

Real-World Analogy

Think of a mobile phone:

it does not create a SIM card internally
SIM is inserted externally

The phone works regardless of SIM provider.

One-Line Takeaway

Dependency Injection decouples system components by moving responsibility of object creation outside the class.

LLD Object-Oriented Design: Interfaces & Abstract Classes (Designing Contracts)

Saras Growth Space — Mon, 25 May 2026 15:00:00 +0000

After understanding composition, inheritance, and polymorphism, the next important step is learning how to define clear behavioral contracts between components.

This is where interfaces and abstract classes become essential.

They help answer one of the most important questions in system design:

“What should this component be capable of doing?”

without tightly coupling the system to a specific implementation.

Why Contracts Matter in System Design

In real systems:

multiple implementations exist
components evolve independently
implementations may change over time

If systems depend directly on concrete classes:

flexibility decreases
testing becomes difficult
coupling increases

Contracts solve this problem.

What is an Interface?

An interface defines:

A capability contract that implementing classes must follow.

It specifies:

what operations are available
not how they are implemented

Example

class Payment:
    def pay(self):
        pass

Any implementation must provide:

pay()

But implementation details remain independent.

Core Idea

Interfaces define capability expectations, not implementation details.

What is an Abstract Class?

An abstract class provides:

Partial implementation along with abstract behavior contracts.

It is useful when:

some logic is common across implementations
some behavior varies by subclass

Example

class Notification:
    def log(self):
        print("Logging notification")

    def send(self):
        pass

Here:

log() → shared behavior
send() → implementation-specific behavior

Interface vs Abstract Class

Interface	Abstract Class
defines contract	defines partial behavior
focuses on capability	focuses on shared structure
minimal implementation	can contain implementation
enables loose coupling	enables reuse + extension

Key Mental Model

Think of it this way:

Interface

“What can this object do?”

Abstract Class

“What common behavior already exists?”

Real System Example

Payment System

Contract

class Payment:
    def pay(self):
        pass

Implementations

class CardPayment(Payment):
    def pay(self):
        print("Processing card payment")

class UpiPayment(Payment):
    def pay(self):
        print("Processing UPI payment")

Usage

def process(payment: Payment):
    payment.pay()

Now the system depends on:

abstraction not:
concrete implementation

Why Interfaces Matter in LLD

Interfaces help achieve:

1. Loose Coupling

Components communicate through contracts instead of implementations.

2. Extensibility

New implementations can be added safely.

3. Testability

Mock implementations become easy.

Example:

MockPayment
FakeNotificationService

4. System Scalability

Independent teams can build implementations separately while following the same contract.

Why Abstract Classes Matter

Abstract classes help when:

logic is partially shared
duplication needs reduction
related classes have common behavior

They provide:

controlled reuse
shared structure

Common Mistake

Beginners often:

create interfaces for everything
or avoid abstractions entirely

Both create problems.

Over-Abstraction

Too many unnecessary interfaces lead to:

complexity
indirection
unreadable systems

Under-Abstraction

No contracts lead to:

tight coupling
rigid systems
difficult testing

Design Principle

Depend on abstractions for flexibility, but introduce abstractions only when variation or decoupling is actually needed.

Real-World Analogy

Think of a charging socket.

The socket defines:

voltage standard
connection contract

Different chargers:

Apple
Samsung
Laptop adapters

all work because they follow the same contract.

The socket does not care about internal implementation.

One-Line Takeaway

Interfaces define what a component must be capable of doing, while abstract classes help share common behavior across related implementations.

LLD Object-Oriented Design: Composition vs Inheritance (Choosing the Right Relationship)

Saras Growth Space — Sun, 24 May 2026 15:00:00 +0000

After learning inheritance and polymorphism, the next critical design decision is:

How should objects be connected to each other?

There are two primary ways:

Inheritance (is-a relationship)
Composition (has-a relationship)

Understanding when to use which is one of the most important skills in LLD.

Inheritance Recap (is-a)

Inheritance means:

A child class is a specialized version of a parent class.

Example:

Dog is an Animal
Car is a Vehicle

It creates a hierarchical relationship.

Composition (has-a Relationship)

Composition means:

An object is made up of other objects.

Instead of inheriting behavior, you delegate it to another object.

Example

class Engine:
    def start(self):
        print("Engine started")

class Car:
    def __init__(self, engine):
        self.engine = engine

    def start(self):
        self.engine.start()

Here:

Car HAS an Engine
behavior is delegated, not inherited

Key Difference

Inheritance	Composition
is-a relationship	has-a relationship
tight coupling	loose coupling
rigid hierarchy	flexible design
behavior inherited	behavior delegated

Why Composition is Preferred in LLD

In real systems:

requirements change frequently
behavior varies across contexts
rigid hierarchies break easily

Composition provides:

flexibility
reusability
easier maintenance

Problem with Overusing Inheritance

Inheritance can lead to:

deep class hierarchies
fragile base classes
unexpected side effects
tightly coupled systems

As systems grow:

inheritance becomes difficult to manage

Composition Enables Flexibility

With composition, behavior can be changed dynamically.

Example:

class Engine:
    def start(self):
        print("Generic engine start")

class ElectricEngine(Engine):
    def start(self):
        print("Electric engine start")

Now Car can use any engine:

car = Car(ElectricEngine())
car.start()

Core Design Insight

Composition allows behavior to be plugged in, while inheritance locks behavior into a hierarchy.

Real-World Analogy

Think of a car:

Car does NOT become an engine
Car simply uses an engine

Similarly:

objects should use components, not become them

When to Use Inheritance

Use inheritance when:

clear is-a relationship exists
behavior is stable
substitution is valid

Example:

Payment methods
Base models
Shared contracts

When to Use Composition

Use composition when:

behavior can change
multiple variations exist
flexibility is required

Example:

notification systems
payment processing pipelines
service integrations

Common Mistake

Beginners often:

force inheritance for reuse
create unnecessary hierarchies
mix unrelated behaviors into base classes

This leads to:

rigid and fragile systems

Design Principle

Prefer composition over inheritance for flexible and maintainable systems.

One-Line Takeaway

Inheritance defines hierarchy, but composition defines flexibility through collaboration.

LLD Object-Oriented Design: Polymorphism (Design Without if-else)

Saras Growth Space — Sat, 23 May 2026 15:00:00 +0000

After understanding inheritance, the next step is learning how systems can support multiple behaviors without constantly changing existing code.

This is where polymorphism becomes important.

What is Polymorphism?

Polymorphism means:

The same operation can behave differently depending on the object handling it.

In simple terms:

one common contract
multiple implementations
behavior selected at runtime

Why Polymorphism Exists

In real systems:

similar operations exist across different entities
behavior changes based on type or implementation
systems need extensibility without modification

Without polymorphism, systems usually rely on:

large if-else chains
switch-case logic
type checking everywhere

As systems grow, this becomes difficult to maintain.

Bad Design: Behavior Controlled Using if-else

class PaymentService:
    def pay(self, payment_type):
        if payment_type == "card":
            print("Card payment")
        elif payment_type == "upi":
            print("UPI payment")

Problems with This Approach

1. Every new type requires modification

Adding WalletPayment means editing existing code.

2. Logic keeps growing

The service becomes bloated over time.

3. Violates Open-Closed Principle

The class is not closed for modification.

4. Behavior is centralized incorrectly

Service decides behavior instead of objects themselves.

Better Design: Using Polymorphism

class Payment:
    def pay(self):
        pass

class CardPayment(Payment):
    def pay(self):
        print("Card payment")

class UpiPayment(Payment):
    def pay(self):
        print("UPI payment")

Usage

def process(payment: Payment):
    payment.pay()

Now the caller does not care:

whether it is card payment
UPI payment
wallet payment

The object itself decides behavior.

What Actually Changed?

Instead of:

service controlling behavior using conditions

Now:

behavior is delegated to the object

This is the essence of polymorphism.

Key Idea: Same Message, Different Behavior

The same method call:

pay()

can produce different behavior depending on object type:

CardPayment → card processing
UpiPayment → UPI processing
WalletPayment → wallet processing

Runtime Polymorphism

This behavior selection happens during runtime.

The system works with a common abstraction:

Payment

But actual execution depends on:

underlying implementation object

Important Clarification

Polymorphism is not limited to inheritance alone.

It can also be achieved through:

interfaces
abstract classes
shared contracts

The core idea is:

multiple implementations behind a common abstraction

Real System Example

Notification System

class Notification:
    def send(self):
        pass

class EmailNotification(Notification):
    def send(self):
        print("Email sent")

class SmsNotification(Notification):
    def send(self):
        print("SMS sent")

Generic Usage

def notify(notification: Notification):
    notification.send()

The calling code remains unchanged even when new notification types are added.

Why Polymorphism is Powerful

1. Extensibility

New behavior can be added without modifying existing logic.

2. Cleaner Systems

Removes large conditional chains.

3. Better Separation of Concerns

Each class owns its own behavior.

4. Improved Maintainability

Changes remain isolated to specific implementations.

Polymorphism vs if-else

if-else approach	Polymorphism approach
centralized conditions	distributed behavior
difficult to extend	easy to extend
service controls behavior	objects control behavior
violates OCP	follows OCP

Common Mistake

Beginners sometimes:

use polymorphism but still keep if-else checks
create unnecessary type validations
tightly couple services to implementations

This defeats the purpose of polymorphism.

Design Principle

Behavior should live inside the object responsible for it, not inside a centralized conditional block.

When to Use Polymorphism

Use polymorphism when:

multiple implementations exist for same behavior
behavior varies by type
extensibility is important
new variations are expected in future

One-Line Takeaway

Polymorphism allows systems to support multiple behaviors through a common abstraction without modifying existing business logic.

LLD Object-Oriented Design: Inheritance (When to Use It and When to Avoid It)

Saras Growth Space — Fri, 22 May 2026 15:00:00 +0000

After understanding how objects protect their state through encapsulation, the next natural step is learning how objects can reuse and extend behavior.

This is where inheritance comes in.

However, inheritance is one of the most commonly misused concepts in object-oriented design.

What is Inheritance?

Inheritance is a mechanism where:

A class acquires properties and behavior of another class.

This allows reuse and extension of existing behavior.

Basic Example

class Animal:
    def eat(self):
        print("Eating")

class Dog(Animal):
    def bark(self):
        print("Barking")

Here:

Dog inherits from Animal
Dog automatically gets eat()

Why Inheritance Exists

Inheritance is used for:

code reuse
representing hierarchical relationships
extending existing behavior

It models an “is-a” relationship:

Dog is an Animal
Car is a Vehicle

The Key Idea: is-a Relationship

Inheritance only makes sense when:

The child class is truly a specialized version of the parent class.

Good Use Case

class Payment:
    def process(self):
        pass

class CardPayment(Payment):
    def process(self):
        print("Processing card payment")

Here:

CardPayment is a Payment
same contract, different behavior

The Hidden Risk of Inheritance

Inheritance creates a strong coupling between classes.

This means:

changes in parent affect child
child depends heavily on parent structure
hierarchy becomes rigid over time

Bad Example

class Bird:
    def fly(self):
        print("Flying")

class Penguin(Bird):
    pass

Problem:

Penguin cannot fly
but inherits fly behavior anyway

This breaks the model.

Core Problem: Forced Behavior

Inheritance can force unwanted behavior into child classes.

This leads to:

incorrect modeling
broken assumptions
fragile systems

Why Inheritance Breaks at Scale

In real systems:

behavior varies widely
rules change frequently
strict hierarchies become restrictive

As systems grow:

inheritance trees become difficult to maintain

Better Alternative: Think Before Inheriting

Before using inheritance, ask:

“Is this truly an is-a relationship, or just shared behavior?”

If it is shared behavior:

composition is usually better

Conceptual Insight

Inheritance is not about reuse alone.

It is about:

hierarchy
substitution
behavioral correctness

When Inheritance Works Well

Use inheritance when:

behavior is stable
hierarchy is clear
substitution is valid

Examples:

Payment methods
Notification types
Base response models

When to Avoid Inheritance

Avoid inheritance when:

behavior differs significantly
future variation is expected
relationship is not truly hierarchical

Design Principle

Inheritance should represent natural classification, not convenience-based reuse.

Real System Thinking

In production systems:

inheritance is used sparingly
composition is preferred for flexibility
interfaces often replace deep hierarchies

One-Line Takeaway

Inheritance should only be used when the child truly is a specialized form of the parent without violating expected behavior.

LLD Object-Oriented Design: Encapsulation (Protecting State and Behavior)

Saras Growth Space — Thu, 21 May 2026 15:00:00 +0000

Once you understand classes and objects, the next critical step in object-oriented design is:

Controlling how internal state is accessed and modified.

This is where encapsulation becomes essential.

What is Encapsulation?

Encapsulation means:

Keeping data (state) and methods (behavior) together, while controlling direct access to internal state.

It is not just about “hiding variables”.

It is about protecting the integrity of an object.

Why Encapsulation Matters

Without encapsulation:

any part of the system can modify state directly
rules can be bypassed
invalid states become possible

With encapsulation:

object controls its own data
rules are enforced in one place
system becomes predictable

Bad Design: No Encapsulation

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

Now anyone can do:

account.balance = -5000

This breaks business rules completely.

Good Design: Encapsulation

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

    def deposit(self, amount):
        if amount <= 0:
            raise Exception("Invalid amount")
        self._balance += amount

    def get_balance(self):
        return self._balance

Now:

state is protected
modifications are controlled
validation is enforced

Key Idea: Control Through Methods

Instead of allowing direct access:

You expose controlled behavior.

So instead of:

account.balance = X

You do:

account.deposit(X)

Encapsulation in Real Systems

Example: Order System

class Order:
    def __init__(self):
        self._status = "CREATED"

    def mark_paid(self):
        if self._status != "CREATED":
            raise Exception("Invalid transition")
        self._status = "PAID"

Here:

status cannot be changed freely
only valid transitions are allowed

What Encapsulation Really Protects

Encapsulation protects:

1. State Integrity

Prevents invalid data.

2. Business Rules

Ensures rules are always applied.

3. System Consistency

Keeps objects in valid states.

Encapsulation vs Data Hiding (Important Distinction)

Concept	Meaning
Data Hiding	Restrict direct access to fields
Encapsulation	Bundle + control state through behavior

Encapsulation is broader and more important in LLD.

Common Mistake: Getters/Setters Everywhere

Beginners often do this:

class User:
    def get_name(self):
        return self.name

    def set_name(self, name):
        self.name = name

This does NOT add real encapsulation.

Why?

no validation
no rules enforced
still exposes raw state

Better Thinking

Instead of:

“How do I expose data?”

Think:

“What operations should be allowed on this object?”

Encapsulation in System Design

In real systems:

payment status cannot be directly modified
order state transitions must follow rules
account balances cannot be arbitrary

Encapsulation ensures these constraints are always enforced.

Design Principle

Objects should protect their own state and expose only meaningful behavior.

Why Encapsulation is Critical

Without it:

systems become fragile
bugs become unpredictable
debugging becomes difficult

With it:

objects become reliable units
system behavior becomes predictable
design becomes scalable

One-Line Takeaway

Encapsulation ensures that an object controls its own state and exposes only safe, meaningful operations.

LLD Object-Oriented Design: Classes & Objects (Deep Understanding)

Saras Growth Space — Wed, 20 May 2026 15:00:00 +0000

After shifting your thinking toward objects and responsibilities, the next step is to understand the most basic building block of object-oriented design:

Classes and objects are not just syntax — they are a way to model real-world systems.

Many people learn them early in programming, but never truly understand their design meaning in LLD.

What is a Class Really?

A class is not just a template for code.

A class is a blueprint for behavior and state of a real-world entity.

It defines:

what data an entity holds (state)
what it can do (behavior)

Example

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

    def deposit(self, amount):
        self.balance += amount

Here:

balance → state
deposit() → behavior

What is an Object?

An object is a real instance created from a class.

It represents a specific entity in the system with actual data.

Example

account1 = BankAccount(5000)
account2 = BankAccount(12000)

Now:

account1 → has its own state (5000)
account2 → has its own state (12000)

Same class, different reality.

Key Insight: Class vs Object

Concept	Meaning
Class	Blueprint / definition
Object	Real instance / live entity

A class defines structure.
An object carries actual data.

Why This Matters in LLD

In low-level design, systems are built using objects that represent real entities.

Example:

Food Delivery System

User → object
Order → object
Restaurant → object
DeliveryPartner → object

Each object:

holds state
performs behavior
interacts with other objects

State vs Behavior (Critical Distinction)

State

Represents data held by an object.

Examples:

balance in bank account
order status
user details

Behavior

Represents actions an object can perform.

Examples:

deposit money
place order
assign delivery

Rule of Thumb

State tells “what it is”, behavior tells “what it does”.

Common Mistake: Passive Data Classes

Beginners often design classes like this:

class Order:
    def __init__(self, id, status):
        self.id = id
        self.status = status

And then put all logic outside.

This leads to:

anemic models
scattered business logic
hard-to-maintain systems

Better Approach: Active Objects

class Order:
    def mark_paid(self):
        if self.status != "CREATED":
            raise Exception("Invalid state")
        self.status = "PAID"

Now:

object controls its state
rules are enforced locally
invalid transitions are prevented

Core Design Principle

Objects should manage their own state and behavior.

Not:

external services manipulating internal state freely

Why Objects Make Systems Scalable

When systems grow:

functions become unmanageable
shared state becomes dangerous
logic becomes scattered

Objects solve this by:

encapsulating state
bundling behavior
reducing global complexity

Real-World Mapping

Think of objects as real entities:

System	Object
Bank System	Account
E-commerce	Order
Delivery	Rider
Booking	Ticket

Each object has:

identity
state
behavior

Design Intuition

When designing a system, always ask:

“What does this entity know, and what can it do?”

If the answer is unclear, the design is incomplete.

One-Line Takeaway

Classes define structure, objects represent real instances, and together they model real-world systems through state and behavior.

Google I/O 2026 Made Me Realize AI Agents Are Becoming Real Development Infrastructure

Saras Growth Space — Wed, 20 May 2026 10:00:19 +0000

This is a submission for the Google I/O Writing Challenge

Google I/O 2026 made one thing increasingly clear to me:

AI is slowly moving beyond isolated chatbot experiences and becoming part of actual development infrastructure.

For a long time, most conversations around AI focused primarily on model intelligence:

benchmark improvements,
larger context windows,
better reasoning,
faster responses,
and multimodal capabilities.

Those advancements matter, but this year’s announcements highlighted something equally important:

The ecosystem around AI is becoming significantly more usable for developers.

And I think that shift may ultimately matter more than raw model capability alone.

The Most Important Change Isn't Just Smarter Models

Modern AI systems are no longer just standalone assistants.

They are increasingly becoming:

workflow participants,
orchestration layers,
development accelerators,
multimodal interfaces,
and infrastructure components developers can build around.

That changes the conversation entirely.

The value of AI is no longer only about asking better questions in a chat window.

The real transformation begins when AI systems can integrate into actual software workflows:

connecting tools,
handling multiple input types,
assisting development pipelines,
automating repetitive engineering tasks,
and enabling faster iteration cycles.

Google I/O 2026 strongly reinforced this direction.

The Ecosystem Layer Is Becoming the Real Advantage

One of the biggest takeaways from this year’s announcements is that developer ecosystems are becoming just as important as the underlying models themselves.

Because eventually:

APIs matter,
tooling matters,
integrations matter,
orchestration matters,
iteration speed matters,
and developer experience matters.

A highly capable model becomes dramatically more useful when developers can rapidly experiment, prototype, and integrate it into real systems.

That is why platforms like Google AI Studio feel important.

The barrier between:

idea → prototype → working system

is getting smaller.

And that changes who gets to build.

AI Agents Are Quietly Becoming Workflow Infrastructure

What stood out most to me was how AI agents are evolving beyond simple conversational interfaces.

Modern AI systems are increasingly expected to:

reason across tools,
manage context,
interact with workflows,
process multimodal inputs,
and coordinate tasks dynamically.

That starts looking less like a chatbot feature and more like infrastructure.

The interesting part is not just that AI can generate responses.

It’s that AI can increasingly participate inside larger systems.

That opens up entirely different possibilities for:

software engineering,
automation,
productivity tooling,
research workflows,
and intelligent developer platforms.

Faster Experimentation Changes Everything

One underrated aspect of modern AI tooling is how much it reduces experimentation friction.

Historically, building intelligent systems often required:

significant infrastructure setup,
complex integrations,
model management,
deployment pipelines,
and specialized expertise.

Now the development loop is becoming much faster.

Developers can:

prototype quickly,
iterate faster,
test workflows rapidly,
and validate ideas with significantly less overhead.

That acceleration may end up being one of the most important long-term impacts of the current AI ecosystem shift.

Because innovation compounds when experimentation becomes easier.

But The Challenges Are Still Very Real

At the same time, the current state of AI systems still comes with major engineering challenges:

hallucinations,
evaluation complexity,
reliability issues,
orchestration difficulty,
debugging problems,
and unpredictable behavior.

AI agents add even more complexity because they combine:

reasoning,
memory,
workflows,
tool usage,
and autonomous decision-making.

Building reliable agentic systems is still difficult.

And that’s exactly why infrastructure, tooling, and ecosystem maturity matter so much right now.

The easier these systems become to evaluate, debug, orchestrate, and integrate responsibly, the more useful they become for real-world software development.

The Bigger Shift

The most interesting part of Google I/O 2026 wasn’t a single feature announcement.

It was the broader direction.

AI is gradually evolving from:

“a tool developers occasionally use”

into:

“a software layer developers build on top of.”

That feels like a meaningful transition.

The future of AI will likely depend not only on model intelligence, but also on:

ecosystem quality,
developer accessibility,
infrastructure maturity,
orchestration tooling,
and the ability to transform ideas into working systems quickly.

And that shift may ultimately shape the next generation of software development far more than model benchmarks alone.

Thanks for reading!

What was the most interesting Google I/O 2026 announcement or trend for you as a developer?

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

Saras Growth Space — Tue, 19 May 2026 15:00:00 +0000

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.

LLD Foundations: Trade-offs Thinking (how real design decisions are made)

Saras Growth Space — Mon, 18 May 2026 15:00:00 +0000

Up to now, you’ve learned:

how to structure systems
how to apply principles
how to keep designs clean

But there is one reality that changes everything:

There is no perfect system design.

Every decision you make improves something and weakens something else.

Understanding this is what separates:

someone who knows concepts from
someone who can design real systems

The illusion of the “best solution”

A common beginner mindset is:

“What is the best design for this problem?”

In reality, that question is incomplete.

A better question is:

“What am I optimizing for, and what am I willing to compromise?”

What is a trade-off?

A trade-off means:

You gain one benefit by accepting a cost somewhere else.

Common trade-offs in systems

1. Consistency vs Availability

Strong consistency → always correct data
- slower
- less available during failures
High availability → system always responds
- may return slightly outdated data

Example:
In a food delivery system, availability is often prioritized.
A slightly delayed order status is acceptable.
A system that doesn’t respond is not.

2. Performance vs Cost

More servers → faster responses
- higher infrastructure cost
Fewer resources → lower cost
- slower performance

3. Simplicity vs Flexibility

Simple design
- easier to build and maintain
- harder to extend later
Flexible design
- easier to extend
- more complex initially

4. Read vs Write optimization

Indexing improves read speed
- but slows down writes
- increases storage usage

Why trade-offs matter

Every design decision you make:

impacts scalability
affects user experience
changes system complexity

Ignoring trade-offs leads to:

over-engineering
under-performing systems
unexpected failures at scale

How to think in trade-offs

Instead of asking:

“Is this design correct?”

Ask:

What does this design optimize?
What does it sacrifice?
Is that acceptable for this system?

A practical example

Designing a food delivery system:

You might choose:

High availability
Eventual consistency

Why?

Because:

users prefer a working system
slight delays in updates are acceptable

This is a conscious trade-off, not a compromise by accident.

A subtle but critical shift

Beginners try to avoid trade-offs.

Experienced engineers:

Make trade-offs deliberately.

Closing thought

Good design is not about eliminating compromises.

It’s about choosing the right compromises for the problem you are solving.

LLD Foundations: DRY, KISS, YAGNI (practical rules for everyday design)

Saras Growth Space — Sun, 17 May 2026 15:00:00 +0000

So far, you’ve seen structured principles like SOLID and concepts like cohesion and coupling.

But in day-to-day development, you don’t always think in formal principles.

Instead, you rely on simple rules that guide decisions quickly.

Three of the most important ones are:

DRY (Don’t Repeat Yourself)
KISS (Keep It Simple)
YAGNI (You Aren’t Gonna Need It)

These look simple, but they prevent a large number of real-world design issues.

DRY — Don’t Repeat Yourself

Every piece of knowledge should have a single, unambiguous source.

What goes wrong without DRY

You implement pricing logic in multiple places:

checkout flow
order summary
invoice generation

Initially, everything works.

Later:

tax calculation changes
discount rules update

Now you must update logic in multiple places.

Miss one, and your system behaves inconsistently.

Applying DRY

Centralize logic:

PriceService:
- calculate_price(order)

Now:

one source of truth
consistent behavior across the system

Important nuance

DRY is not just about avoiding duplicate code.

It’s about:

Avoiding duplicate logic and knowledge

Common mistake

Over-applying DRY too early:

creating generic abstractions
forcing unrelated logic into one place

This leads to:

complexity
harder readability

KISS — Keep It Simple

Prefer simple solutions over complex ones.

What goes wrong without KISS

You design a simple feature using:

multiple design patterns
deep abstractions
unnecessary layers

The system becomes:

harder to understand
slower to modify

Applying KISS

Choose the simplest approach that solves the problem.

Sometimes:

a simple class is enough
a straightforward condition is fine

Complexity should be introduced only when required.

Important nuance

KISS does not mean:

writing messy or unstructured code

It means:

Avoiding unnecessary complexity

YAGNI — You Aren’t Gonna Need It

Don’t build functionality until it is actually needed.

What goes wrong without YAGNI

While building an MVP, you add:

multi-region support
advanced recommendation system
dynamic pricing engine

None of these are required immediately.

Result:

longer development time
more bugs
increased complexity

Applying YAGNI

Focus on current requirements:

build what is needed now
leave extension points for future

Do not implement features based on assumptions.

Important nuance

YAGNI does not mean:

ignoring future scalability

It means:

Don’t implement future features without real need

How these three work together

DRY → keeps logic consistent
KISS → keeps design simple
YAGNI → keeps scope controlled

Together, they help you:

avoid over-engineering
write maintainable code
move faster without creating chaos

A practical way to use them

When designing, ask:

Am I repeating logic? → DRY
Am I overcomplicating this? → KISS
Do I really need this right now? → YAGNI

Closing thought

Good design is not just about what you build.

It’s also about what you choose not to build.

LLD Foundations: Coupling vs Cohesion (how to judge if your design is actually good)

Saras Growth Space — Sat, 16 May 2026 15:00:00 +0000

Up to this point, you’ve learned:

how to understand requirements
how to break systems
how to apply SOLID principles

But a practical question still remains:

How do you evaluate whether a design is good or not?

Two concepts help you answer that:

Cohesion and Coupling

The hidden problem in most designs

Consider this:

OrderService:
- create_order()
- process_payment()
- send_email()
- generate_invoice()

At first glance, this may seem organized.

All order-related actions are in one place.

But look closer:

order creation
payment processing
notifications
billing

These are not the same responsibility.

This is where design quality starts breaking.

Cohesion — how focused a component is

Cohesion measures how closely related the responsibilities inside a module are.

Low cohesion (bad design)

A class doing:

multiple unrelated tasks
mixing business logic with external concerns

Like the previous example:

OrderService is doing everything

This leads to:

harder understanding
difficult testing
risky changes

High cohesion (good design)

Break responsibilities:

OrderService → create_order()
PaymentService → process_payment()
NotificationService → send_email()
InvoiceService → generate_invoice()

Now:

each class has a single, clear purpose
logic is easier to reason about

Key insight

A cohesive class answers one question clearly.

Coupling — how dependent components are

Coupling measures how much one component depends on others.

High coupling (bad design)

If OrderService directly:

calls payment logic
sends emails
generates invoices

Then:

it depends on multiple systems
any change in those systems affects it

Low coupling (good design)

Introduce separation:

Services are independent
Communication happens via clear interfaces

Optionally, introduce an orchestrator:

OrderOrchestrator:
- create_order()
- process_payment()
- send_notification()
- generate_invoice()

Now:

services don’t depend on each other
flow is managed separately

Key insight

Low coupling reduces the ripple effect of changes.

How cohesion and coupling work together

Good design aims for:

High Cohesion → each module is focused
Low Coupling → modules are independent

If you get both right:

code is easier to maintain
features are easier to add
bugs are easier to isolate

A practical way to evaluate your design

Ask yourself:

Does this class have more than one responsibility? → Cohesion issue
Will a change in one part affect many others? → Coupling issue

If the answer is yes, your design needs refinement.

A subtle but important shift

Beginners often think:

“Everything in one place is easier.”

Experienced engineers think:

“Clear separation makes systems easier to evolve.”

Closing thought

Good design is not about adding more structure.

It’s about placing responsibilities in the right place, and keeping dependencies under control.