DEV Community: Ashay Tiwari

Dependency Injection in JavaScript/TypeScript: Why Should a Class Create Its Own Dependencies?

Ashay Tiwari — Thu, 13 Aug 2026 07:26:41 +0000

In the previous article, we explored the Dependency Inversion Principle (DIP).

We saw how high-level business logic becomes tightly coupled when it directly creates and depends on implementation details.

We also briefly introduced another concept:

Dependency Injection (DI).

You may have heard this term many times.

You may have even used Dependency Injection without realizing it.

But instead of starting with its definition, let's start with a problem.

The Problem

Imagine we're building an order processing system.

Our OrderService needs to send an email when an order is created.

We might write:

class EmailService {
  send(to: string, message: string) {
    console.log(`Sending email to ${to}`);
  }
}

class OrderService {
  private emailService = new EmailService();

  createOrder() {
    // Create order...

    this.emailService.send(
      "customer@example.com",
      "Your order has been placed."
    );
  }
}

Looks simple.

OrderService needs an EmailService, so it creates one.

What's wrong with that?

At first, nothing.

But let's see what happens as the application grows.

The First Problem: Changing the Dependency

Suppose the application initially uses one email provider.

Later, the business decides to switch to another provider.

Our OrderService is now directly connected to the original implementation.

We have to change it.

class OrderService {
  private emailService = new NewEmailService();
}

The order logic shouldn't have to know which email service the company uses.

But because it creates the dependency itself, it has no choice.

The Bigger Problem: Testing

Now imagine we want to test OrderService.

We only want to test:

Does creating an order trigger an email?

But our test has a problem.

OrderService automatically creates a real EmailService.

So our test may end up:

Connecting to an external service.
Making unnecessary network requests.
Depending on external configuration.
Becoming slower.
Becoming harder to make deterministic.

All because OrderService decided to create its own dependency.

What If We Could Provide the Dependency?

Instead of this:

class OrderService {
  private emailService = new EmailService();
}

What if we did this?

class OrderService {
  constructor(private emailService: EmailService) {}

  createOrder() {
    // Create order...

    this.emailService.send(
      "customer@example.com",
      "Your order has been placed."
    );
  }
}

And outside the class:

const emailService = new EmailService();

const orderService = new OrderService(emailService);

Something important just happened.

OrderService no longer creates its dependency.

Someone else provides it.

That's Dependency Injection.

The Simplest Definition

Dependency Injection simply means:

A class receives the dependencies it needs from the outside instead of creating them itself.

That's it.

The dependency is injected into the object.

Why Is This Better?

Now OrderService doesn't care where the email service came from.

We can provide the real implementation:

const emailService = new EmailService();

const orderService = new OrderService(emailService);

Or a fake implementation during testing:

class FakeEmailService {
  send(to: string, message: string) {
    console.log("Fake email sent");
  }
}

Then:

const fakeEmailService = new FakeEmailService();

const orderService = new OrderService(fakeEmailService);

The OrderService doesn't need to change.

It simply receives something that provides the behavior it needs.

But There Is Still a Problem

Our previous example depends directly on EmailService.

That's better than creating it internally, but we can take it one step further.

What if we define what OrderService actually needs?

It doesn't necessarily need an EmailService.

It needs something capable of sending emails.

So we define an abstraction.

interface EmailSender {
  send(to: string, message: string): void;
}

Our actual service implements it:

class EmailService implements EmailSender {
  send(to: string, message: string) {
    console.log(`Sending email to ${to}`);
  }
}

Now OrderService depends on the abstraction.

class OrderService {
  constructor(private emailSender: EmailSender) {}

  createOrder() {
    // Create order...

    this.emailSender.send(
      "customer@example.com",
      "Your order has been placed."
    );
  }
}

This is where Dependency Injection and Dependency Inversion work nicely together.

DI and DIP Are Not the Same Thing

These terms are often used interchangeably, but they mean different things.

Dependency Inversion Principle

DIP is a design principle.

It tells us that high-level modules shouldn't be tightly coupled to low-level implementation details.

Dependency Injection

DI is a technique.

It provides a practical way to supply dependencies from outside.

You can use Dependency Injection without perfectly following DIP.

And DIP can be achieved through different techniques.

But in practice, they are often used together.

Dependency Injection in Real Applications

You've probably already used Dependency Injection.

Consider a React component.

function UserProfile({ userService }: Props) {
  // ...
}

The component doesn't create userService.

It receives it.

The same idea appears in:

Backend services
Database repositories
API clients
Logging systems
Authentication providers
Payment processors
File storage
Notification services

The pattern is always similar:

Instead of:

Class → creates dependency

We have:

Class ← receives dependency

**Does DI Always Require a Framework?

**
No.

This is another common misconception.

Dependency Injection doesn't require:

NestJS
Angular
Spring
.NET
A DI container

This is Dependency Injection:

class OrderService {
  constructor(private paymentService: PaymentService) {}
}

And:

const paymentService = new PaymentService();

const orderService = new OrderService(paymentService);

No framework.

No library.

Just JavaScript/TypeScript.

A DI framework simply automates the process of creating and connecting these dependencies.

The Composition Root

At some point, someone still has to create the objects.

We haven't eliminated object creation.

We've moved it to a better place.

For example:

const paymentService = new StripePaymentService();

const orderService = new OrderService(
  paymentService
);

This part of the application is sometimes called the composition root.

It's where we decide:

Which implementation should be used?

The business logic doesn't need to know.

This creates a useful separation:

Application Setup
       │
       ├── StripePaymentService
       └── OrderService
                │
                ↓
        PaymentProcessor

The configuration decides the implementation.

The business logic simply uses the abstraction.

The Benefits of Dependency Injection

Easier Testing

Dependencies can easily be replaced with mocks, fakes, or stubs.

Easier Maintenance

Classes don't need to know how their dependencies are created.

Lower Coupling

Business logic becomes less dependent on concrete implementations.

Greater Flexibility

Different implementations can be provided without changing the consuming class.

But Is DI Always Better?

Not necessarily.

Dependency Injection also introduces some complexity.

Compare:

const orderService = new OrderService();

with:

const orderService = new OrderService(
  paymentService,
  emailService,
  inventoryService,
  logger,
  analyticsService
);

The second approach can become difficult to understand if taken too far.

You can also end up with a codebase where every class has an interface, every dependency is injected, and simple object creation becomes unnecessarily complicated.

Again, the goal isn't to apply a principle everywhere.

The goal is to solve a real problem.

Concluding This Series — For Now 🙂

With this article, we've reached a natural stopping point for this part of the series.

We started with the fundamentals of OOP, explored its core concepts, questioned where Factory Functions fit in, and then moved into SOLID Principles and Dependency Injection.

But software design is a much bigger topic.

There are still many areas worth exploring—from Design Patterns and Inversion of Control to architecture, coupling, cohesion, and many of the practical decisions we face while building real-world software.

We'll continue exploring these topics in future articles, always following the same approach:

Don't just learn what a concept is. Understand why it exists, what problem it solves, and when it actually makes sense to use it.

For now, this is where we'll conclude this part of the journey.

See you in the next one. 🚀

Dependency Inversion Principle (DIP): Why Should High Level Module Depend on Details?

Ashay Tiwari — Wed, 12 Aug 2026 08:13:42 +0000

We've finally reached the fifth and last principle of SOLID:

Dependency Inversion Principle (DIP).

So far, we've talked about:

SRP — Keep responsibilities focused.
OCP — Extend behaviour without constantly modifying existing code.
LSP — Subtypes should be genuine substitutes for their parent types.
ISP — Don't force clients to depend on things they don't need.

DIP brings many of these ideas together.

Its formal definition says:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

And the second part says:

Abstractions should not depend on details. Details should depend on abstractions.

That's technically correct.

But it's not particularly easy to understand.

So, as always, let's start with a problem.

The Problem

Imagine we're building an e-commerce application.

When an order is placed, we need to send a confirmation email.

A simple implementation might look like this:

class EmailService {
  send(to: string, message: string) {
    console.log(`Sending email to ${to}`);
  }
}

class OrderService {
  private emailService = new EmailService();

  createOrder() {
    // Create order...

    this.emailService.send(
      "customer@example.com",
      "Your order has been placed."
    );
  }
}

At first, this looks perfectly reasonable.

OrderService needs to send an email.

So it creates an EmailService.

What's wrong with that?

The Hidden Dependency

Our OrderService isn't really saying:

I need something that can send notifications.

It's saying:

I specifically need this particular EmailService.

That's an important difference.

Today, we're sending emails.

Tomorrow, the business might say:

"We also want to send a push notification."

Or:

"For some customers, send an SMS instead."

Or:

"We're moving to a different email provider."

Now OrderService is affected by all of those decisions.

Why?

Because the high-level business logic is directly connected to a low-level implementation.

What Is High-Level and Low-Level?

This terminology can sound confusing, so let's simplify it.

High-level code

This represents business decisions.

For example:

OrderService
PaymentService
CheckoutService

These answer questions like:

What should the application do?

Low-level code

This represents implementation details.

For example:

EmailService
StripePaymentService
MySQLRepository
S3Storage

These answer questions like:

How exactly should we do it?

The problem occurs when business logic becomes tightly coupled to implementation details.

Let's Look at a Payment Example

Suppose our checkout service directly uses Stripe.

class CheckoutService {
  private paymentService = new StripePaymentService();

  checkout(amount: number) {
    this.paymentService.charge(amount);
  }
}

Everything works.

Until the business says:

We're moving from Stripe to Razorpay.

Now we need to change CheckoutService.

But why should the checkout logic care which payment provider we're using?

The business requirement is:

Process the payment.

The implementation detail is:

Use Stripe.

Those are two different concerns.

The Idea Behind Dependency Inversion

Instead of making the high-level module depend directly on the implementation, we introduce an abstraction.

interface PaymentProcessor {
  charge(amount: number): void;
}

Now Stripe can implement that abstraction.

class StripePaymentProcessor implements PaymentProcessor {
  charge(amount: number) {
    console.log("Charging through Stripe...");
  }
}

And Razorpay can implement the same abstraction.

class RazorpayPaymentProcessor implements PaymentProcessor {
  charge(amount: number) {
    console.log("Charging through Razorpay...");
  }
}

Our CheckoutService no longer needs to know about either provider.

class CheckoutService {
  constructor(
    private paymentProcessor: PaymentProcessor
  ) {}

  checkout(amount: number) {
    this.paymentProcessor.charge(amount);
  }
}

Now the dependency points toward the abstraction.

What Changed?

Before:

CheckoutService
      ↓
StripePaymentProcessor

After:

CheckoutService
      ↓
PaymentProcessor
      ↑
StripePaymentProcessor

The important part isn't the arrow diagram.

It's the relationship.

CheckoutService no longer cares about Stripe.

It only cares about a capability:

Give me something that can process a payment.

The implementation can change without changing the business logic.

This Is Where Dependency Injection Comes In

You might have noticed something in our example.

We're no longer creating the payment processor inside CheckoutService.

We're receiving it from outside.

const paymentProcessor = new StripePaymentProcessor();

const checkoutService = new CheckoutService(
  paymentProcessor
);

This is Dependency Injection.

Instead of a class creating its own dependencies, those dependencies are provided to it.

DIP and Dependency Injection are closely related, but they are not the same thing.

DIP is a design principle.

Dependency Injection is one technique we can use to implement that principle.

We'll explore Dependency Injection in much more detail in the next article.

Why Is This Useful?

This design gives us several benefits.

Easier to Change

Switching payment providers doesn't require changing CheckoutService.

Easier to Test

We can provide a fake payment processor.

class FakePaymentProcessor implements PaymentProcessor {
  charge(amount: number) {
    console.log("Fake payment");
  }
}

Now we can test checkout logic without making a real payment.

Less Coupling

Business logic isn't tied to a specific technology.

Better Extensibility

Adding another implementation doesn't require modifying the high-level module.

DIP Isn't About Interfaces Everywhere

There's another common misunderstanding.

DIP doesn't mean:

Create an interface for every class.

That would quickly turn a simple application into an unnecessarily complicated one.

The real question is:

Which dependencies represent decisions or details that are likely to vary?

Those are the places where abstractions become valuable.

If something is simple, stable, and unlikely to change, introducing another abstraction may only add complexity.

The Bigger Picture

Now look at what we've covered across SOLID.

SRP tells us:

Keep responsibilities focused.

OCP tells us:

The system should be open for extension but closed for modification.

LSP tells us:

Child Entities preserve the behaviour clients expect.

ISP tells us:

Keep interfaces focused.

DIP tells us:

Don't tightly couple business logic to implementation details.

These aren't isolated rules.

They work together.

And together, they help us build scalable and maintainable software.

The Key Takeaway

Dependency Inversion isn't about avoiding dependencies.

Software will always have dependencies.

The goal is to control which direction those dependencies point.

Your business logic shouldn't have to know whether data comes from:

PostgreSQL
MongoDB
REST API
GraphQL

Or whether a payment is processed through:

Stripe
Razorpay
PayPal

Those are implementation details.

The business logic should depend on abstractions that represent what it actually needs.

What's Next?

We've now completed all five SOLID principles.

But one important concept has appeared repeatedly throughout this article:

Dependency Injection.

We've used it without fully exploring it.

So in the next article, we'll take a step back and ask a very practical question:

Why should a class create its own dependencies when someone else can provide them?

We'll explore Dependency Injection, understand the problem it solves, and see how it works in real JavaScript and TypeScript applications.

Interface Segregation Principle (ISP): Why Should a Class Implement What It Doesn't Need?

Ashay Tiwari — Tue, 11 Aug 2026 13:27:55 +0000

So far, we've explored three SOLID principles:

Single Responsibility Principle (SRP) — keep responsibilities together.
Open/Closed Principle (OCP) — make software easier to extend.
Liskov Substitution Principle (LSP) — objects of a superclass should be replaceable with objects of its subclasses

Now let's look at the fourth principle.

Interface Segregation Principle (ISP).

The formal definition says:

Clients should not be forced to depend on interfaces they do not use.

Sounds reasonable.

But what does that actually mean?

Let's start with a problem.

The Problem

Imagine we're building an application for managing employees.

Different employees can perform different actions.

Some employees can:

Work
Attend meetings
Take breaks

Some can also:

Approve expenses
Manage teams
Conduct interviews

So we create an interface:

interface Employee {
  work(): void;
  attendMeeting(): void;
  takeBreak(): void;
  approveExpenses(): void;
  conductInterview(): void;
}

Looks convenient.

Everything related to an employee is in one place.

Now let's create a regular developer.

class Developer implements Employee {
  work() {
    console.log("Writing code...");
  }

  attendMeeting() {
    console.log("Attending meeting...");
  }

  takeBreak() {
    console.log("Taking a break...");
  }

  approveExpenses() {
    // Not applicable
  }

  conductInterview() {
    // Not applicable
  }
}

We have a problem.

The developer is being forced to implement methods that don't make sense for them.

The "Not Applicable" Problem

We might try to solve this by throwing an error.

approveExpenses() {
  throw new Error("Developers cannot approve expenses.");
}

Or perhaps we leave the method empty.

approveExpenses() {}

Neither solution feels right.

Why should a Developer be required to implement something that isn't part of its responsibility?

The problem isn't with the developer.

The problem is with our interface.

We've created an interface that is trying to represent too many things at once.

The Idea Behind ISP

Instead of one large interface, we can split it into smaller, focused interfaces.

interface Worker {
  work(): void;
}

interface MeetingParticipant {
  attendMeeting(): void;
}

interface BreakTaker {
  takeBreak(): void;
}

interface ExpenseApprover {
  approveExpenses(): void;
}

interface Interviewer {
  conductInterview(): void;
}

Now a developer can implement only what they actually need.

class Developer implements Worker, MeetingParticipant, BreakTaker {
  work() {
    console.log("Writing code...");
  }

  attendMeeting() {
    console.log("Attending meeting...");
  }

  takeBreak() {
    console.log("Taking a break...");
  }
}

A manager might implement more capabilities.

class Manager
  implements Worker, MeetingParticipant, BreakTaker, ExpenseApprover, Interviewer {

  work() {}

  attendMeeting() {}

  takeBreak() {}

  approveExpenses() {}

  conductInterview() {}
}

Now our design represents reality much better.

Why Does This Matter?

At first, this might seem like a small improvement.

But imagine the application becomes much larger.

Suppose dozens of classes implement our original Employee interface.

Now we decide to add a new method:

interface Employee {
  ...
  generatePayrollReport(): void;
}

Suddenly every class implementing Employee has to deal with this new method.

Even classes that have absolutely nothing to do with payroll.

This is one of the hidden costs of large interfaces.

A change in one part of an interface can force unrelated classes to change.

That's exactly the kind of coupling ISP tries to reduce.

ISP Isn't About Creating Tiny Interfaces Everywhere

This is important.

After learning ISP, it's easy to go too far.

You might end up creating interfaces like:

interface CanCreate {}

interface CanUpdate {}

interface CanDelete {}

interface CanRead {}

And suddenly the codebase has hundreds of interfaces.

That's not the goal.

The goal isn't:

Make every interface as small as possible.

The goal is:

Don't force a client to depend on behaviour it doesn't need.

Sometimes a larger interface genuinely represents one cohesive concept.

There's nothing wrong with that.

The problem begins when unrelated responsibilities are bundled together.

A Simple Way to Think About ISP

Whenever you're designing an interface, ask:

Does every implementation actually need all of these methods?

If the answer is repeatedly "no", that's a signal that the interface may be doing too much.

Another useful question is:

If I add a new method to this interface, how many unrelated classes will I have to change?

If the answer is "a lot", you may have a fat interface.

ISP and Real-World APIs

This principle isn't limited to classes.

The same thinking applies to APIs and modules.

Imagine a service exposes:

userService.createUser()
userService.deleteUser()
userService.generateReport()
userService.sendMarketingEmail()
userService.exportFinancialData()

A component that only needs to create users shouldn't necessarily depend on everything the service can do.

Smaller, focused contracts make dependencies clearer.

This becomes especially important when we start discussing Dependency Inversion and Dependency Injection.

The Key Takeaway

The Interface Segregation Principle is essentially about avoiding unnecessary dependencies.

Instead of creating one large interface that tries to describe everything, create focused contracts around meaningful capabilities.

That way:

Classes implement only what they need.
Changes affect fewer parts of the system.
Dependencies become clearer.
Interfaces become easier to understand and maintain.

The important thing isn't the number of methods in an interface.

It's whether those methods belong together from the perspective of the clients using them.

What's Next?

We've now covered four of the five SOLID principles:

SRP — Keep responsibilities focused.
OCP — Extend behaviour without constantly modifying existing code.
LSP — Subtypes should genuinely be replaceable for their parent types.
ISP — Don't force clients to depend on things they don't need.

One principle remains.

And arguably, it's the one that connects many of the ideas we've discussed so far.

Dependency Inversion Principle (DIP).

We'll explore why high-level business logic shouldn't be tightly coupled to low-level implementation details—and how this idea eventually leads us to Dependency Injection.

Liskov Substitution Principle (LSP): Can Every Child Truly Replace Its Parent?

Ashay Tiwari — Mon, 03 Aug 2026 04:37:08 +0000

So far in this series, we've explored two of the SOLID principles.

Single Responsibility Principle (SRP) taught us to design classes with one clear responsibility.
Open/Closed Principle (OCP) showed us how to extend software without constantly modifying existing, stable code.

Now it's time to look at what is often considered the most misunderstood SOLID principle:

The Liskov Substitution Principle (LSP).

Its formal definition is:

Objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program.

That's... a mouthful.

The definition is technically correct, but it doesn't tell us why this principle exists.

So, like every article in this series, let's start with a problem.

The Problem

Imagine we're building a payment system.

Every payment method should support refunds.

So we create a base class.

abstract class PaymentMethod {
  abstract pay(amount: number): void;
  abstract refund(amount: number): void;
}

Now we implement different payment methods.

class CreditCardPayment extends PaymentMethod {
  pay(amount: number) {
    console.log("Payment successful.");
  }

  refund(amount: number) {
    console.log("Refund successful.");
  }
}

Everything works perfectly.

Later, the business introduces Cash on Delivery (COD).

Naturally, we extend the same parent class.

class CashOnDeliveryPayment extends PaymentMethod {
  pay(amount: number) {
    console.log("Customer will pay on delivery.");
  }

  refund(amount: number) {
    throw new Error("Refunds are not supported.");
  }
}

The application compiles.

The inheritance hierarchy looks correct.

But do we actually have a valid substitute for PaymentMethod?

Not really.

What goes wrong?

Somewhere else in the application, another developer writes:

function cancelOrder(payment: PaymentMethod) {
  payment.refund(500);
}

This function doesn't care whether it's dealing with:

Credit Card
UPI
PayPal

It simply assumes:

Every PaymentMethod supports refunds.

That assumption was true...

Until CashOnDeliveryPayment appeared.

Now the application crashes.

The problem isn't the function.

The problem is that one child class broke the expectations established by its parent.

The Real Meaning of LSP

Liskov Substitution Principle asks a simple question:

If I replace a parent object with one of its children, should the rest of the program continue to work correctly?

If the answer is no, the inheritance relationship is probably incorrect.

The child isn't truly behaving like the parent promised.

Another Famous Example

Perhaps you've seen this example before.

Imagine we model shapes like this.

Shape
├── Rectangle
└── Square

It sounds perfectly reasonable.

After all...

A square is a rectangle.

Right?

Let's see.

A rectangle allows width and height to change independently.

rectangle.setWidth(10);
rectangle.setHeight(5);

Now imagine Square.

Whenever we change the width, we must also change the height.

square.setWidth(10);

// Height automatically becomes 10

Now consider this function.

function resizeRectangle(rectangle: Rectangle) {
  rectangle.setWidth(10);
  rectangle.setHeight(5);

  console.log(rectangle.getArea());
}

If we pass a normal rectangle...

Area = 50

If we pass a square...

Area = 100

The function behaves differently because the child changed the expectations established by the parent.

The inheritance relationship looked correct mathematically.

It wasn't correct from a software design perspective.

The Root Problem

The issue isn't inheritance.

The issue is a bad abstraction.

Inheritance creates expectations.

Whenever we inherit from a parent class, we're making a promise.

We're saying:

You can use me anywhere you use my parent.

If that promise isn't true...

Inheritance becomes dangerous.

Other developers begin making assumptions - that aren't always valid.

Those assumptions eventually become bugs.

LSP Is About Behaviour, Not Hierarchy

One of the biggest misconceptions is thinking LSP is about inheritance syntax.

It isn't.

The compiler only checks whether a child inherits correctly.

LSP asks something deeper.

Does the child preserve the behaviour clients expect?

Two classes may have identical methods.

They may even share the same parent.

Yet one may still violate LSP if it behaves differently in unexpected ways.

Behaviour matters more than hierarchy.

How to Spot an LSP Violation

Here are a few warning signs.

A child throws UnsupportedOperationException or similar errors for inherited methods.
A child ignores methods defined by the parent.
Client code starts checking object types before calling methods.

For example:

if (payment instanceof CashOnDeliveryPayment) {
  // Skip refund
}

Whenever you find yourself writing lots of instanceof checks for subclasses, it's often a sign that the inheritance hierarchy isn't modelling the problem correctly.

A Better Design

Instead of forcing every payment method to support refunds, separate the capabilities.

interface PaymentMethod {
  pay(amount: number): void;
}

interface Refundable {
  refund(amount: number): void;
}

Now:

Credit Card implements both.
PayPal implements both.
Cash on Delivery only implements PaymentMethod.

No fake implementations.

No unexpected exceptions.

No broken promises.

The Key Takeaway

The Liskov Substitution Principle teaches us that inheritance isn't just about sharing code.

It's about preserving expectations.

Whenever a child class replaces its parent, the rest of the application should continue to work without knowing the difference.

If client code needs special cases for certain subclasses, or if some subclasses can't persist the behaviour promised by the parent, the inheritance hierarchy probably needs another look.

What's Next?

We've now covered three SOLID principles.

SRP helped us design focused classes.
OCP taught us to extend behaviour without modifying stable code.
LSP reminded us that inheritance should preserve behaviour, not just structure.

Next, we'll explore the Interface Segregation Principle (ISP).

We'll answer another practical question:

Why is forcing classes to implement methods they don't need considered a design problem?

Open/Closed Principle (OCP): How Do We Add Features Without Breaking Existing Code?

Ashay Tiwari — Wed, 29 Jul 2026 07:26:39 +0000

In the previous article, we discussed the Single Responsibility Principle (SRP) and learned that a class should have one clear reason to change.

Now let's look at the second SOLID principle:

Open/Closed Principle (OCP).

This principle is often summarized as:

Software entities should be open for extension but closed for modification.

It's a famous definition.

It's also one of the most misunderstood.

The obvious question is:

How can something be open and closed at the same time?

Let's start with the problem.

The Problem

Imagine you're building an e-commerce application.

Initially, the business only supports two payment methods:

Credit Card
UPI

Your implementation might look like this:

function processPayment(type: string, amount: number) {
  if (type === "credit-card") {
    console.log("Processing credit card payment...");
  } else if (type === "upi") {
    console.log("Processing UPI payment...");
  }
}

Everything works.

A month later, the business wants to support PayPal.

So we modify the function.

if (type === "paypal") {
  ...
}

A few weeks later:

Apple Pay
Bank Transfer
Gift Cards

Every new payment method requires editing the same function.

Again.

And again.

What's the Real Problem?

At first glance, modifying the function doesn't seem like a problem.

After all, adding new functionality usually means changing code.

But consider this.

That payment function is already:

Tested.
Used by multiple parts of the application.
Running successfully in production.

Every modification introduces risk.

A small mistake while adding Apple Pay could accidentally break UPI payments.

The more frequently we modify stable code, the greater the chance of introducing bugs.

The problem isn't adding new features.

The problem is having to modify existing, working code every time a new requirement appears.

The Idea Behind OCP

The Open/Closed Principle encourages us to design software so that new behaviour can be added without modifying existing, tested code.

Notice the wording.

It doesn't say:

Never modify code.

That's unrealistic.

Instead, it asks:

Can we design our code so new features are added by extending it rather than editing it?

That's a subtle but powerful shift in thinking.

Question

If you were designing this using what you've already learned about:

Abstraction
Interfaces
Polymorphism

How would you avoid the growing chain of:

function processPayment(type: string, amount: number) {
  if (type === "credit-card") {
    console.log("Processing credit card payment...");
  } else if (type === "upi") {
    console.log("Processing UPI payment...");
  }
}

A Better Approach

Instead of one function knowing about every payment method, each payment method can be responsible for processing itself.

Applying Polymorphism

interface PaymentMethod {
  process(amount: number): void;
}

Now we create separate implementations.

class CreditCardPayment implements PaymentMethod {
  process(amount: number) {
    console.log("Processing credit card payment...");
  }
}

class UpiPayment implements PaymentMethod {
  process(amount: number) {
    console.log("Processing UPI payment...");
  }
}

The checkout process no longer needs to know which payment method it's dealing with.

function checkout(payment: PaymentMethod, amount: number) {
  payment.process(amount);
}

Now suppose the business wants to support PayPal.

Do we modify checkout()?

No.

We simply create another implementation.

class PayPalPayment implements PaymentMethod {
  process(amount: number) {
    console.log("Processing PayPal payment...");
  }
}

The existing checkout logic remains untouched.

We've extended the system without modifying stable code.

That's exactly what OCP is encouraging.

What Changed?

Previously:

DiscountService
   ↓
knows all discount types

Now:

DiscountService
   ↓
knows only DiscountStrategy

That's abstraction.

Why Is This Useful?

Following OCP provides several benefits.

Less Risk
Existing, tested code remains unchanged.
Easier Feature Development
New functionality is added instead of squeezed into existing logic.
Better Team Collaboration
Different developers can work on new features without constantly editing the same files.
Improved Maintainability
The system naturally grows by adding new pieces instead of making one central component increasingly complex.

Does OCP Mean Never Modify Existing Code?

Not at all.

This is probably the biggest misconception.

Sometimes modifying existing code is absolutely the right thing to do.

If you discover:

A bug
Poor design
Duplicate logic
Performance issues

You should improve it.

OCP isn't about avoiding modifications at all costs.

It's about designing systems where expected future changes are handled through extension rather than repeatedly editing the same code.

The Trade-offs

Like every design principle, OCP isn't free.

Supporting extension often means:

More interfaces.
More abstractions.
More classes.

If your application is small or unlikely to change, these extra layers may provide little value.

The goal isn't to predict every future requirement.

It's to recognise areas of the system that are likely to evolve and design those areas thoughtfully.

What's Next?

We've now explored two SOLID principles.

SRP taught us to give each class one clear responsibility.

OCP taught us how to extend behaviour without repeatedly modifying stable code.

Next, we'll tackle one of the most debated principles in software design:

The Liskov Substitution Principle (LSP).

We'll answer an interesting question:

Just because one class inherits from another, does it really mean it can replace it?

Single Responsibility Principle (SRP): How Much Responsibility Should a Class Really Have?

Ashay Tiwari — Mon, 27 Jul 2026 06:59:08 +0000

In the previous article, we discussed why Object-Oriented Programming alone wasn't enough and how the SOLID principles emerged to help developers design more maintainable software.

Today, we'll explore the first principle:

Single Responsibility Principle (SRP).

Many developers hear:

A class should have only one responsibility.

Then immediately wonder:

Does that mean a class should have only one method?

Or:

Should every class do just one tiny thing?

Not quite.

Let's understand the problem SRP was trying to solve.

The Problem

Imagine we're building an e-commerce application.

We create an OrderService.

Initially, its job is simple.

OrderService

✓ Create Order

Everything looks fine.

As the application grows, new requirements arrive.

"We need to calculate discounts."

No problem.

OrderService

✓ Create Order
✓ Calculate Discount

A week later:

"We should send a confirmation email."

OrderService

✓ Create Order
✓ Calculate Discount
✓ Send Email

A month later:

"We also need to generate invoices."

OrderService

✓ Create Order
✓ Calculate Discount
✓ Send Email
✓ Generate Invoice

Then someone asks for audit logs.

Inventory updates.

Loyalty points.

Analytics.

Before long, the class looks like this:

OrderService

✓ Create Order
✓ Calculate Discount
✓ Process Payment
✓ Update Inventory
✓ Generate Invoice
✓ Send Email
✓ Record Analytics
✓ Write Audit Logs

The application still works.

But something feels wrong.

What's the Real Problem?

The issue isn't the number of methods.

The issue is that the class is trying to solve too many different problems.

Think about who might request changes.

The finance team may ask for invoice changes.

The marketing team may introduce a new discount strategy.

Operations may change inventory rules.

Customer support may request a different email template.

Analytics may require new tracking events.

Every team has a different reason to modify the same class.

Now imagine multiple developers working on it simultaneously.

Merge conflicts become common.

Testing becomes more difficult.

A small change in one area can accidentally affect another.

The class has become a bottleneck.

The Idea Behind SRP

This is where the Single Responsibility Principle comes in.

It says:

A class should have one, and only one, reason to change.

Notice something important.

It doesn't say:

One method.

It doesn't say:

One line of code.

It says:

One reason to change.

A responsibility isn't defined by the amount of code.

It's defined by the purpose the class serves.

Breaking Responsibilities Apart

Instead of putting everything into one class, we separate concerns.

OrderService
    │
    ├── DiscountService
    ├── PaymentService
    ├── InventoryService
    ├── EmailService
    ├── InvoiceService
    └── AnalyticsService

Now each class has a clear responsibility.

If invoice generation changes, we modify InvoiceService.

If email templates change, we modify EmailService.

If discount rules change, we modify DiscountService.

Each class evolves independently.

Another Real-World Example

Think about a restaurant.

One person could:

Take orders.
Cook food.
Wash dishes.
Manage inventory.
Handle payments.
Clean tables.

Technically, it's possible.

But would it be efficient?

Probably not.

Restaurants divide responsibilities because specialization makes the system easier to manage.

Software is no different.

What SRP Doesn't Mean

SRP is often misunderstood.

It doesn't mean:

❌ Every class should contain only one method.

❌ Every file should be tiny.

❌ Every function deserves its own class.

Those interpretations usually lead to unnecessary complexity.

Instead, ask yourself:

Does this class represent one clear responsibility?

If the answer is yes, you're likely on the right track.

Benefits of SRP

Following SRP makes software easier to:

Understand
Test
Maintain
Extend

It also reduces the chances that unrelated changes will accidentally affect each other.

Are There Trade-offs?

Absolutely.

Like every design principle, SRP can be overused.

If every tiny operation becomes its own class, you'll end up with hundreds of small classes that are difficult to navigate.

Good software design is about balance.

Split responsibilities when they truly represent different reasons to change.

Don't split code simply because you can.

What's Next?

We've learned how to design classes with focused responsibilities.

But another challenge still remains.

What happens when a new feature requires changing an existing, well-tested class?

Should we keep modifying it?

Or is there a better way?

In the next article, we'll explore the Open/Closed Principle (OCP) and learn why software should be open for extension but closed for modification.

Why OOP Wasn't Enough: The Problems That Led to SOLID

Ashay Tiwari — Fri, 24 Jul 2026 06:01:52 +0000

Over the last few articles, we've explored the core concepts of Object-Oriented Programming.

We discussed why OOP was introduced, how objects help us organize code, and how concepts like Encapsulation, Abstraction, Inheritance, Composition, and Polymorphism make software easier to build and maintain.

At this point, it might seem like we've found the perfect solution.

So why did developers feel the need to introduce another set of principles called SOLID?

Wasn't OOP enough?

The short answer is:

OOP gave us powerful tools, but it didn't tell us how to use them well.

Let's understand why.

The Early Days of OOP

When Object-Oriented Programming became popular, developers finally had a better way to organize software.

Instead of scattering related data and functions across an application, they could model real-world entities as objects.

It was a huge improvement.

Applications became easier to understand.

Code became more reusable.

Responsibilities felt more organized.

For a while, everything seemed to be moving in the right direction.

Then Applications Started Growing

As software evolved, projects became much larger than anyone had imagined.

Applications that once had a few dozen classes now had hundreds.

Large enterprise systems contained thousands of classes maintained by multiple teams.

And a new kind of problem started appearing.

The problem was no longer:

How do we organize code?

The problem became:

How do we organize large codebases?

Simply using classes and objects wasn't enough anymore.

OOP Doesn't Prevent Bad Design

Let's imagine we're building an e-commerce application.

We create a class called Order.

At first, it seems reasonable.

It stores order details.

Then we add price calculations.

Later, invoice generation.

Then payment processing.

Email notifications.

Inventory updates.

Discount calculations.

Audit logging.

Before we realize it, our class looks something like this:

Order
├── calculateTotal()
├── processPayment()
├── sendConfirmationEmail()
├── generateInvoice()
├── updateInventory()
├── applyDiscount()
├── writeAuditLog()
├── exportPDF()
└── ...

Technically, it's Object-Oriented.

It uses a class.

It encapsulates data.

But is it well-designed?

Probably not.

The class has become responsible for almost every part of the order lifecycle.

Changing one feature increases the risk of breaking another.

Testing becomes harder.

Understanding the class becomes harder.

Maintaining it becomes harder.

The problem wasn't OOP.

The problem was how we were using OOP.

Classes Became Too Dependent on Each Other

Another issue appeared.

Imagine a payment service.

OrderService
    │
    ▼
StripePaymentService

The OrderService creates and depends directly on StripePaymentService.

Everything works.

Until the business says:

"We're moving to Razorpay."

Now changes are needed in multiple places.

The higher-level business logic is tightly coupled to a specific implementation.

Again...

OOP didn't prevent this.

It allowed it.

Reusing Code Sometimes Made Things Worse

Inheritance was introduced to reduce duplication.

But many applications started building deep inheritance hierarchies.

Employee
    │
    ├── Manager
    │      ├── RegionalManager
    │      │       └── SeniorRegionalManager

Initially, it looked elegant.

Over time, it became difficult to understand.

A change in a parent class unexpectedly affected several child classes.

Developers realized that simply because something can inherit doesn't always mean it should.

This realization eventually led to the idea:

Favor Composition Over Inheritance.

The Missing Piece

At this point, developers had all the building blocks.

They had:

Classes
Objects
Encapsulation
Abstraction
Inheritance
Polymorphism

But something was still missing.

There were no clear guidelines for questions like:

How many responsibilities should a class have?
When should existing code be modified?
How should dependencies be managed?
How should objects communicate?
How do we build software that's easy to extend?

OOP answered:

What tools do we have?

Developers now needed answers to:

How should we use those tools?

🏋️ Enter SOLID

This is where the SOLID principles come in.

SOLID isn't a replacement for Object-Oriented Programming.

It builds on top of it.

Think of it this way.

OOP gives you the bricks, cement, and steel to construct a building.

SOLID gives you architectural guidelines for using those materials wisely.

Without those guidelines, you can still build a structure.

It just might not be easy to maintain.

What SOLID Tries to Achieve

The SOLID principles encourage us to build software that is:

Easier to understand.
Easier to modify.
Easier to test.
Easier to extend.
Less tightly coupled.
More maintainable over time.

None of these principles are magical rules.

They're lessons learned from years of building—and maintaining—large software systems.

Most of them were born from mistakes developers repeatedly encountered in real-world projects.

The Key Takeaway

Object-Oriented Programming solved many problems.

It gave developers a better way to organize software.

But it couldn't guarantee good design.

You can write terrible Object-Oriented code.

You can also write excellent Object-Oriented code.

The difference isn't the programming paradigm.

It's the design decisions you make.

That's exactly what the SOLID principles try to improve.

They don't teach us how to write Object-Oriented code.

They teach us how to write better Object-Oriented code.

What's Next?

Now that we understand why SOLID was introduced, we can finally explore the first principle:

The Single Responsibility Principle (SRP).

We'll answer a deceptively simple question:

How many responsibilities should a class really have?

As you'll see, the answer isn't "one method" or "one task."

It's much more interesting than that.

Polymorphism in OOP: One Interface, Multiple Implementations

Ashay Tiwari — Tue, 30 Jun 2026 05:40:47 +0000

Most developers memorize:

"One interface, many forms."

Unfortunately, that definition is so abstract that it doesn't teach much.

Let's understand the actual problem polymorphism solves.

🤯 The Problem

Suppose you're building a payment system.

Without polymorphism:

class PaymentService {

  processPayment(
    type: string,
    amount: number
  ) {
    if (type === 'credit-card') {
      // credit card logic
    }

    if (type === 'paypal') {
      // paypal logic
    }

    if (type === 'upi') {
      // upi logic
    }
  }
}

Works.

Then the business says:

Add Stripe

You modify:

if (type==='stripe') {}

Next month:

Add Apple Pay

Modify again.

Add Crypto

Modify again.

The class keeps growing.

This violates a key design principle:

Existing code should not need constant modification when new behavior is added.

✨ Polymorphism's Solution

Instead of asking:

What type are you?

ask:

Can you perform this action?

That's a huge mindset shift.

Example

Create a contract:

interface PaymentProvider {
  process(amount:number):void;
}

Implementations:

class CreditCardPayment implements PaymentProvider {

  process(amount: number) {
    console.log('Credit Card');
  }
}

class UpiPayment implements PaymentProvider {

  process(amount: number) {
    console.log('UPI');
  }
}

Now:

function checkout(
  provider: PaymentProvider,
  amount: number
) {
  provider.process(amount);
}

Usage:

checkout(new CreditCardPayment(),100);

checkout(new UpiPayment(),100);

checkout(new PaypalPayment(),100);

Same method call:

provider.process()

Different behavior.

This is polymorphism.

🧠 The Core Idea

Polymorphism means:

Treat different objects uniformly while allowing each object to behave differently.

You don't care:

Credit Card
UPI
PayPal

You only care:

Can you process a payment?

Real World Example

Think about a power socket.

You plug in:

Laptop charger
Phone charger
Fan
TV

The socket doesn't ask:

Are you a Samsung charger?
Are you a Dell charger?

It only expects:

Can you accept electricity?

Each device behaves differently after receiving power.

That is polymorphism.

Why Interfaces Matter

Consider:

interface UserRepository {
  findById(id:string):Promise<User>;
}

Implementation 1:

class PostgresUserRepository implements UserRepository {}

Implementation 2:

class MongoUserRepository implements UserRepository {}

Implementation 3:

class InMemoryUserRepository implements UserRepository {}

UserService:

class UserService {
  constructor(
   privaterepo: UserRepository
  ) {}
}

Notice:

repo.findById()

works regardless of:

Postgres
Mongo
Memory

The service doesn't care.

That's polymorphism.

🔑 The Key Takeaway

Polymorphism is often described as:

"One interface, many forms."

A more practical way to think about it is:

Different objects can respond to the same request in their own way.

The caller doesn't need to know the implementation.

It only needs to know the capability the object provides.

This makes systems easier to extend without constantly modifying existing code.

⏭️ What's Next?

With this article, we've completed the four core pillars commonly associated with Object-Oriented Programming:

Encapsulation
Abstraction
Inheritance
Polymorphism

But understanding these concepts doesn't automatically lead to well-designed software.

Developers soon realized that even OOP applications could become difficult to maintain if responsibilities weren't clearly defined.

That realization gave rise to a new set of guidelines known as the SOLID Principles.

In the next article, we'll explore why SOLID was introduced and the problems it was designed to solve.

Composition vs Inheritance: Why Modern Software Often Prefers Composition

Ashay Tiwari — Mon, 29 Jun 2026 07:31:09 +0000

In the previous article, we learned that Inheritance was introduced to solve a very real problem—code duplication.

Instead of writing the same behavior repeatedly, we could move common functionality into a parent class and let child classes inherit it.

It sounded like the perfect solution.

For a long time, many developers thought:

"If two classes share some behavior, just use inheritance."

And that's exactly what happened.

Large applications started building deep inheritance hierarchies.

Unfortunately, a new set of problems emerged.

Let's understand why.

🤯 The Problem

Imagine we're building an application for different kinds of birds.

We start with a base class.

class Bird {
  fly() {
    console.log("Flying...");
  }
}

Now we create different birds.

class Sparrow extends Bird {}

class Eagle extends Bird {}

Everything looks good.

Then someone asks us to add a Penguin.

Naturally, we do this:

class Penguin extends Bird {}

But now we have a problem.

Penguins don't fly.

Yet every Penguin automatically inherits the fly() method.

const penguin = new Penguin();

penguin.fly();

Technically, the code works.

Logically, it doesn't.

Our inheritance hierarchy is forcing behavior onto objects that shouldn't have it.

Trying to Fix It

One common approach is overriding the method.

class Penguin extends Bird {
  fly() {
    throw new Error("Penguins can't fly.");
  }
}

This "fixes" the issue.

But think about it.

We inherited behavior only to disable it.

That's usually a sign that our model isn't representing reality very well.

The Root Cause

Inheritance creates a very strong relationship.

When a class extends another class, it says:

"I am a specialized version of this parent."

That's a big commitment.

The child automatically receives:

State
Methods
Design decisions
Future changes

As the parent evolves, every child is affected.

Sometimes that's exactly what we want.

Sometimes it becomes a maintenance headache.

😐 A Different Way of Thinking

Instead of asking:

"What should this object inherit?"

We can ask:

"What capabilities does this object need?"

That's the idea behind Composition.

Instead of inheriting behavior, we build objects by combining smaller, focused pieces.

✨ Composition in Action

Rather than making every bird inherit fly(), we separate flying into its own behavior.

class FlyingBehavior {
  fly() {
    console.log("Flying...");
  }
}

Now a Sparrow can have flying behavior.

class Sparrow {
  flyingBehavior = new FlyingBehavior();
}

A Penguin simply doesn't.

class Penguin {}

No unnecessary methods.

No overridden behavior.

No pretending that penguins can fly.

Each object gets only the capabilities it actually needs.

Thinking Beyond Birds

This idea appears everywhere.

Imagine a payment system.

Instead of:

Payment
├── CreditCardPayment
├── UpiPayment
├── PayPalPayment
└── CashPayment

We might compose behavior like:

Refundable
SupportsInstallments
GeneratesInvoice
RequiresAuthentication

Each payment method gets only the behaviors it needs.

This makes the system far more flexible.

Why Composition Is Often Preferred

Composition offers several advantages.

Smaller Responsibilities

Each component does one thing well.

Better Reusability

The same behavior can be shared across unrelated objects.

Lower Coupling

Changing one component doesn't necessarily affect everything else.

Greater Flexibility

Objects can gain or lose behavior simply by changing the components they use.

Does This Mean Inheritance Is Bad?

Not at all.

Inheritance is still a valuable tool.

It works well when there is a genuine "is-a" relationship.

Examples include:

A Circle is a Shape.
A Square is a Shape.
A SavingsAccount is a BankAccount.

The problem isn't inheritance itself.

The problem is using inheritance simply to reuse code.

If the relationship doesn't naturally fit, inheritance often introduces more problems than it solves.

A Practical Guideline

A common piece of advice you'll hear is:

Favor Composition Over Inheritance.

Notice the wording.

It doesn't say:

Never use inheritance.

It says:

Prefer composition when it gives you a simpler and more flexible design.

Inheritance and Composition are both tools.

🔑 The Key Takeaway

Inheritance helped developers eliminate duplicated behavior.

Composition helped developers build systems that were easier to change.

Modern software often prefers composition because requirements change far more often than class hierarchies.

⏭️ What's Next?

We've now explored three important ideas in Object-Oriented Programming:

Encapsulation protects an object's state.
Abstraction hides unnecessary complexity.
Composition helps us build flexible systems.

One important pillar still remains.

In the next article, we'll explore Polymorphism and understand how different objects can share a common interface while providing their own implementations.

Inheritance in OOP: Solving Code Duplication or Creating New Problems?

Ashay Tiwari — Thu, 25 Jun 2026 07:29:46 +0000

Many developers learn:

Inheritance allows code reuse.

Technically true.

But if that's your primary reason for using inheritance, you'll often create bad designs.

❓ Why Was Inheritance Invented?

Imagine:

User
 ├── Customer
 ├── Admin
 └── Seller

All of them have:

id
name
email
login()
logout()

Instead of duplicating these everywhere:

class Customer { ... }
class Admin { ... }
class Seller { ... }

we extract common behavior:

class User {
  id: string;
  name: string;
  email: string;

  login() {}
  logout() {}
}

Then:

class Customer extends User {}

class Admin extends User {}

class Seller extends User {}

This creates an IS-A relationship.

Admin IS A User

Customer IS A User

Seller IS A User

This is the most important rule of inheritance.

What Does `extends` Actually Do?

Consider:

class User {
  login() {
    console.log('login');
  }
}

class Admin extends User {}

Now:

const admin = new Admin();

admin.login();

works.

Why?

Because JavaScript walks up the prototype chain:

admin
   ↓
Admin.prototype
   ↓
User.prototype

and finds login().

Inheritance is fundamentally prototype delegation.

User
   ↓
Admin

Admin has everything a User has, plus additional capabilities.

Example:

class User {
  login() {}
}

class Admin extends User {
  banUser() {}
}

Now:

admin.login();
admin.banUser();

Overriding Methods

Children can change behavior.

class User {
  getRole() {
    return'User';
  }
}

class Admin extends User {
  getRole() {
    return'Admin';
  }
}

Now:

newUser().getRole();
// User

newAdmin().getRole();
// Admin

Same method name.

Different behavior.

This becomes important later when we discuss polymorphism.

🤯 The Biggest Mistake with Inheritance

The Hidden Problem

Over time, developers started encountering a different challenge.

Imagine we have a Vehicle class:

class Vehicle {
  start() {}
  stop() {}
  lockDoors() {}
}

Seems harmless.

But what happens when we introduce a Bicycle?

class Bicycle extends Vehicle {}

Bicycles don't have doors.

Yet they've inherited door-related behavior.

Now our model starts feeling strange.

The problem becomes even worse as systems grow.

Developers often found themselves inheriting behavior they didn't actually need.

Changes in parent classes unexpectedly affected child classes.

The hierarchy became increasingly difficult to maintain.

What started as a solution to code duplication sometimes created tightly coupled systems.

⚔️ The Double-Edged Sword

Inheritance solves one problem very well:

Reusing common behavior.

But it can introduce another:

Tight coupling between parent and child classes.

The child depends heavily on decisions made by the parent.

As hierarchies become deeper, understanding the system becomes harder.

A small change in a base class can ripple through multiple child classes.

This is one reason why modern software design is often more cautious about using inheritance.

✅ When Inheritance Is Actually Good

Use inheritance when:

1. Real IS-A relationship exists

Admin IS A User

Manager IS An Employee

Dog IS An Animal

2. Parent behavior is truly shared

class User {
  login() {}
  logout() {}
}

All child classes genuinely need this.

3. Hierarchy is shallow

Good:

User
 ├─ Admin
 └─ Customer

Bad:

User
 ↓
Employee
 ↓
Manager
 ↓
RegionalManager
 ↓
DistrictManager
 ↓
SuperDistrictManager

⏭️ What's Next?

Inheritance helped developers reuse behavior.

But over time, many teams discovered that inheritance wasn't always the most flexible solution.

This led to an important shift in software design thinking:

Instead of inheriting behavior, what if we assembled behavior from smaller pieces?

In the next article, we'll explore Composition vs Inheritance and understand why many modern applications prefer composition when building complex systems.

Abstraction in OOP: Hiding Complexity Without Hiding Capability

Ashay Tiwari — Wed, 17 Jun 2026 12:24:42 +0000

In the previous article, we discussed Encapsulation and how objects should control changes to their own state.

Now let's talk about another fundamental concept of Object-Oriented Programming: Abstraction.

Like always, let's start with a problem.

The Problem

Imagine you own a car.

To drive it, you do a few simple things:

Start the engine.
Press the accelerator.
Apply the brakes.
Turn the steering wheel.

You don't need to know:

How fuel is injected into the engine.
How the pistons move.
How the gearbox changes gears.
How combustion generates power.

All that complexity is hidden from you.

You simply interact with a straightforward interface.

Software systems work in a very similar way.

A Real-World Example

Suppose we need to send an email.

The application code might look like this:

emailService.send({
  to: "john@example.com",
  subject: "Welcome!",
  body: "Hello John"
});

Looks simple.

But what actually happens behind the scenes?

Potentially a lot:

Validate the email address.
Create an SMTP connection.
Authenticate with the provider.
Build the message.
Retry if sending fails.
Log failures.
Close the connection.

As consumers of email service, we don't care about those details.

We only care that:

If I call send(), the email should be sent.

This is exactly the problem Abstraction tries to solve.

The Problem with Exposing Everything

Imagine if sending an email required every caller to do this:

connect();
authenticate();
buildMessage();
sendMessage();
disconnect();

Every single time.

Suddenly:

Every consumer knows too much.
Every consumer is responsible for the implementation.
Changing the implementation becomes painful.

What if we switch from SMTP to a third-party email provider?

Now every place that sends emails needs to change.

The consumers have become tightly coupled to implementation details.

The Idea Behind Abstraction

Abstraction is about exposing what an object can do while hiding how it does it.

Instead of exposing every implementation detail, we expose only what consumers need.

For example:

emailService.send(email);

The caller doesn't need to know:

Which provider we're using.
How authentication works.
How retries are handled.
How messages are constructed.

Those details remain hidden.

Consumers interact with a simple and stable interface.

Abstraction Is Not the Same as Encapsulation

These two concepts are often confused.

Encapsulation asks:

Who should be allowed to change the object's state?

Abstraction asks:

What details should consumers be aware of?

Encapsulation protects data.

Abstraction hides unnecessary complexity.

They often work together, but they solve different problems.

What's Next?

So far, we've discussed:

How objects protect their state using Encapsulation.
How objects hide complexity using Abstraction.

Next, we'll look at another question developers faced:

If multiple objects share similar behavior, do we really need to write that code repeatedly?

This leads us to one of the most well-known—and sometimes controversial—concepts in OOP:

Inheritance.

Encapsulation in OOP: Protecting an Object's State from Unintended Changes

Ashay Tiwari — Mon, 15 Jun 2026 08:16:37 +0000

In the previous articles, we discussed why Object-Oriented Programming was introduced and explored different ways of creating objects using factory functions and classes.

Now it's time to look at one of the most important ideas behind OOP: Encapsulation.

Like every concept in this series, let's start with the problem rather than the definition.

The Real Problem Encapsulation Solves

Imagine you're building a bank account.

Without encapsulation:

class BankAccount {
  balance = 1000;
}

const account = new BankAccount();

account.balance = -50000;

Now your account contains:

Balance = -50000

which may be impossible according to business rules.

The problem isn't that someone changed a variable.

The problem is:

Anybody can put the object into an invalid state.

Encapsulation is NOT About Hiding

Most beginners think:

Encapsulation = private fields

No.

Private fields are just one tool.

The actual goal is:

Protecting the integrity of an object's state.

An object should control how its data changes.

Why This Becomes Dangerous

In small applications, unrestricted access may not seem like a big deal.

As applications grow, however, data starts being accessed from many places.

Imagine:

A payment module updating balances.
A refund module updating balances.
An admin panel updating balances.
A reporting service reading balances.

Now suppose an issue appears.

A customer's balance becomes negative.

Where did it happen?

Which part of the application modified it?

Was validation skipped?

Did someone accidentally overwrite a value?

The more places that can directly manipulate data, the harder it becomes to reason about the system.

A Better Design

Instead of:

account.balance = -50000;

force all changes through methods:

class BankAccount {
  private balance = 1000;

  deposit(amount: number) {
    this.balance += amount;
  }

  withdraw(amount: number) {
    if (amount > this.balance) {
      throw new Error('Insufficient funds');
    }

    this.balance -= amount;
  }

  getBalance() {
    return this.balance;
  }
}

Now:

account.withdraw(500);

is allowed.

But:

account.balance=-50000;

is impossible.

The object protects itself.

Think Like a Security Guard

Imagine a company database.

Bad design:

Employee Database
      ↑
Everybody can modify it

Good design:

Employee Database
      ↑
HR Department
      ↑
Employees submit requests

Employees don't directly change records.

They request changes.

The HR department validates them.

Encapsulation works exactly like this.

The Idea Behind Encapsulation

Encapsulation is about controlling access to an object's internal state.

Instead of allowing anyone to modify data directly, the object becomes responsible for managing its own data.

Rather than exposing the balance:

account.balance = 5000;

we expose behaviors:

account.deposit(5000);

account.withdraw(5000);

Now every change passes through rules defined by the object itself.

The object protects its own integrity.

This is the real purpose of Encapsulation.

Not hiding data.

Protecting data.

Encapsulation in TypeScript

TypeScript gives us access modifiers.

class User {
  public name: string;

  private password: string;

  protected role: string;
}

public

Accessible everywhere.

user.name

works.

private

Accessible only inside the class.

user.password

❌ Error

protected

Accessible inside:

current class
derived classes

class User {
  protected role = 'user';
}

class Admin extends User {
  checkRole() {
    console.log(this.role);
  }
}

Works.

Important Reality About TypeScript

Many developers are surprised by this.

TypeScript:

private balance = 1000;

is primarily a compile-time restriction.

After compilation to JavaScript:

this.balance = 1000;

still exists.

TypeScript prevents you from accessing it in code, but it's not true runtime privacy.

Modern JavaScript introduced:

#balance

which is actual runtime privacy.

class Account {
  #balance = 1000;
}

Now:

account.#balance

is impossible.

The Key Takeaway

Encapsulation is often described as hiding data.

A more useful way to think about it is this:

Encapsulation ensures that an object controls how its own state changes.

By doing so, it protects business rules, reduces accidental misuse, and makes software easier to maintain as systems grow.

What's Next?

Encapsulation helps us control access to data.

But another challenge still remains.

Even when objects manage their own state correctly, consumers often need to understand too many implementation details to use them.

In the next article, we'll explore Abstraction and see how hiding unnecessary complexity allows us to build systems that are easier to use and easier to change.