DEV Community: Jay Gurav

Single Responsibility Principle

Jay Gurav — Fri, 15 Aug 2025 07:06:00 +0000

TL;DR: The Single Responsibility Principle (SRP) states that a module should be responsible to one, and only one, actor — an actor being a stakeholder or user group that may request changes to it. By giving each part of the system a single, well-defined responsibility, SRP improves clarity, cohesion, and maintainability while reducing complexity, avoiding unintended side effects, and producing cleaner, more adaptable software.

Lately I’ve been thinking about how software development is just breaking big, messy problems into smaller, less-messy ones. Then stitching them back together until they kind of resemble a system that does what we need. It's just composition.

While software development is that, We’re developers not exactly… innocent, we are actors of crime in this process of development. We are chaos wrapped in logic. We bring our quirks, our opinions, our “I’ll just do it this way” moments. And that chaos leaks into the code. Suddenly, a single file is juggling five different concerns because, well, it felt efficient or pleased our fingers at the time. We complicate things by mixing together code that many people care about in many different ways.

SRP(the Single Responsibility Principle) really comes into focus when you start breaking(decomposing) a problem apart. And when I sat with it for a while, I realized it's less about functions or classes and more about actors. Who cares about this piece of code? Who's impacted when it changes?

Ironically, being the actors of crime, we’ve even misinterpret the very principle we're trying to follow. We try to apply the rule—and end up misunderstanding it. There's something oddly poetic about that. Feels like a reflection of humanity as a whole.

More questions than answers right now. Behold.

World Interpreted

The term Single Responsibility Principle itself was coined by Robert Martin—better known in software circles as “Uncle Bob”—and rooted in an older design idea: cohesion.

Cohesion is about how well the parts of a module fit together. Uncle Bob didn’t invent it—he openly credits Tom DeMarco and Meilir Page-Jones—but he took it somewhere new. He tied cohesion to the forces that make a module change, and in his early definition boiled it down to:

A class should have only one reason to change.

Here, responsibility became synonymous with reason for change:

Responsibility = Reason for Change

Sounds clean, right? A module has one reason to change—good. Michael Feathers echoed the same in Working Effectively with Legacy Code, putting it as:

Every class should have a single responsibility: It should have a single purpose in the system, and there should be only one reason to change it.

At first glance, this idea seems straightforward and obvious… until you actually try to define it. What exactly qualifies as a “reason”? Are we talking about technical changes? Business requirements? Design choices? All of them? The line blurs fast.

To dig deeper into decomposing software, I read one of the works often linked to SRP: Parnas’s On the Criteria To Be Used in Decomposing Systems into Modules. Parnas compares two ways of breaking down systems:

Flowchart-based decomposition: splitting things by the order they happen.
Information-hiding decomposition: splitting things by design decisions most likely to change later.

Parnas strongly advocates for the second approach — and for good reason arguing that a good system reflects the volatility of its design decisions, not the sequence of its operations. The “why” behind a module should be hidden, revealing only what others actually need. In short -put that choice into a module with an interface infront that hides the implementation details.

Looping this back to SRP, and you see the connection:

If each module hides the implementation decision (Parnas), and
If each module equals one responsibility (Martin), …then modularity and responsibility are basically two ways of looking at the same thing.

The problem? Take it too literally, and you end up with a Frankenstein system—every possible reason for change locked in its own tiny module. You get hundreds of little pieces, all technically “SRP compliant,” but the big picture feels more like shattered glass than elegant architecture. This is not gut-fully convincing of a good system architecture and is clearly undesirable.

And that’s the tricky part: SRP is easy to explain, easy to nod along to, but maddeningly slippery to implement in the real world. Which is exactly why Uncle Bob eventually clarified his definition—shifting the focus just from the abstract “reasons to change” toward who is driving that change and actor's ownership.

That’s where SRP gets a lot more interesting—and a lot more useful.

Theory, History, and a Shift in Perspective

So, here’s the thing: the way SRP is often explained? It’s not the whole picture. Over time, it’s been oversimplified, misquoted, and trimmed down until it fits neatly into a conference slide—but that’s not where the real depth lives.

"When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function."

— Robert Martin, The Single Responsibility Principle

This is a subtle but important clarification that, It’s not just “a class should have one reason to change” in the abstract—it’s that reason should come from one clearly identifiable source of authority. One person. Or one tightly knit team. A single, well-defined business function.

Why does that matter? Because software doesn’t just exist in code—it lives in organizations. If two different teams “own” a module, they’ll inevitably pull it in different directions. That’s how you get conflicting priorities, unclear ownership, and a maintenance nightmare.

Now, pair this again with David Parnas’ technical angle:

If each module hides the implementation decision (Parnas), and
the decision, reason of change should have one clear owner(Uncle Bob).

Put those together, and you get a richer picture:

Technical modularity keeps changes contained.
Organizational clarity keeps ownership aligned.

In other words, SRP isn’t just about avoiding vague, multiple “reasons to change.” It’s about ensuring that when change happens, you know exactly who it’s coming from. That combination of design principle and organizational reality is what keeps systems healthy, maintainable, and, honestly, a lot less frustrating.

Alright—enough theory. Let's take a look at a quick example

Fake Real-World Example


public class Invoice {
    private String customer;
    private double amount;

    public Invoice(String customer, double amount) {
        this.customer = customer;
        this.amount = amount;
    }

    public double calculateTotal() {
        // Tax calculation logic
        double tax = amount * 0.15;
        return amount + tax;
    }

    public void saveToDatabase() {
        // Save to DB
        System.out.println("Saving invoice to database...");
    }

    public void printInvoice() {
        // Print logic
        System.out.println("Printing invoice for customer: " + customer);
    }
}

What's wrong with this code?

This class has multiple reasons to change, each coming from a different group of people:

calculateTotal() → Might change when the finance team updates tax rules.
saveToDatabase() → Might change when the database team or devops changes data persistence.
printInvoice() → Might change when the UX/design team wants to reformat printed invoices. Each of these groups could request changes that would all modify this one class — that's exactly what SRP warns against.

Applying SRP: Split by Responsibility and ownership

1. `Invoice` – Owned by Finance/Accounting

public class Invoice {
    private String customer;
    private double amount;

    public Invoice(String customer, double amount) {
        this.customer = customer;
        this.amount = amount;
    }

    public String getCustomer() {
        return customer;
    }

    public double getAmount() {
        return amount;
    }

    public double calculateTotal() {
        double tax = amount * 0.15;
        return amount + tax;
    }
}

2.`InvoiceRepository` – Owned by Database/Infrastructure team

public class InvoiceRepository {
    public void save(Invoice invoice) {
        // Save invoice to database
        System.out.println("Saving invoice for customer: " + invoice.getCustomer());
        // Simulate DB save logic...
    }
}

3.`InvoicePrinter` – Owned by UX/Design or Docs team


public class InvoicePrinter {
    public void print(Invoice invoice) {
        // Format and print invoice
        System.out.println("----- Invoice -----");
        System.out.println("Customer: " + invoice.getCustomer());
        System.out.println("Amount: $" + invoice.getAmount());
        System.out.println("Total with Tax: $" + invoice.calculateTotal());
        System.out.println("-------------------");
    }
}

4.Main class (Usage example)

public class Main {
    public static void main(String[] args) {
        Invoice invoice = new Invoice("Acme Corp", 1000.00);

        // Business team uses core logic
        double total = invoice.calculateTotal();

        // Infrastructure team persists the invoice
        InvoiceRepository repository = new InvoiceRepository();
        repository.save(invoice);

        // Presentation team handles invoice output
        InvoicePrinter printer = new InvoicePrinter();
        printer.print(invoice);
    }
}

Summary of Responsibilities

Class	Responsibility	Owned by
`Invoice`	Business rules (tax, etc.)	Finance team
`InvoiceRepository`	Persistence (DB logic)	Infrastructure/DB team
`InvoicePrinter`	Presentation (formatting)	UX/Design/Docs team

In this setup, each class has one responsibility and one clear owner.

If the finance team decides tax rules need tweaking, they update Invoice—and nothing else.
If the database schema changes, the infrastructure team touches only InvoiceRepository.
If the design team wants a prettier invoice layout, they go straight to InvoicePrinter.

No stepping on each other’s toes. No “just one quick change” that accidentally breaks something unrelated.

Why It Delivers Better Code

One reason to change by one actor → Clear boundaries between modules.
Simpler maintenance → Changes happen in isolation, with fewer surprises.
Readable code → Each class has a tight, obvious purpose.
Better tests → Smaller, focused modules are easier to test (and trust).
Loose coupling → One change doesn’t ripple through the whole codebase.
Organizational alignment → Code ownership mirrors real-world team structures.

Final Thoughts

SRP isn’t a one-and-done checklist item you tick during the initial design phase—it’s something to keep an eye on throughout the life of a project.

If a module starts feeling heavy, juggling unrelated concerns, or attracting change requests from multiple teams, that’s your early warning sign: responsibilities are blurring. That’s the moment to refactor. The payoff? Clearer code, happier maintainers, and teams that can move independently without tripping over each other.

I hope this article gave you a clearer understanding of the Single Responsibility Principle and its importance in software design. Let’s keep exploring good code together — and stay responsible.

References

The Principles of OOD by Robert Martin
The Single Responsibility Principle (2007) by Robert Martin
Working Effectively with Legacy Code by Feathers, Michael C
On the Criteria To Be Used in Decomposing Systems into Modules by D.L. Parnas
The Single Responsibility Principle (2014) by Robert Martin
Single Responsibility Principle on Wikipedia

Functions: Am I pure?

Jay Gurav — Mon, 28 Jun 2021 15:16:30 +0000

Pure functions are a nice idea—clean, predictable, and easy to >test. But in the messiness of real-world software, things aren't >always so... pure. This is me trying to untangle what purity means >in programming, why functional folks love it, and where it fits (or >doesn't) in the wild.

If you hang around functional programmers long enough, you'll start to notice something: they really love pure functions. Like, really love them. There’s a kind of quiet reverence for these mythical creatures—functions that touch nothing, change nothing, and simply return a result, neat and tidy.

And honestly? I get it. There’s a kind of elegance to the idea. But I also think that this obsession with purity—what it means, what it gives us—might be part of why functional programming can feel so out of step with how we actually build software.

Because let’s be real: most of what we build in the real world isn’t all that pure.

In this post, I’m going to try and unpack what a function actually is, what it means for one to be “pure,” and why that matters—or doesn’t—depending on what you’re doing.

Functions, Flashbacks & Functional Programming

Remember that one chapter in high school math—the one with functions and sets and domain-to-range mappings? If your brain just went foggy, don’t worry. Here’s the short version:

A function is a way to turn an input into an output. That’s it.

Mathematically, it’s a mapping from a “domain” (input set) to a “co-domain” (output set). Every input gets exactly one output. It’s tidy, predictable, and totally abstract—like a calculator You punch in 2 * 2 and you always get 4. No surprises, no mood swings, no hidden dependencies. Just input → output.

We can represent that kind of function easily in code:

function square(x: number): number {
  return x * x;
}

Here, the square function takes a number and returns its square. That’s it. No surprises. You give it 2, you get 4. You give it 3, you get 9. Every time.

But here’s the thing: real software doesn’t live in a vacuum. It runs in messy, complex environments where things are constantly changing, breaking, mutating, and talking to other things. And that’s where this whole “purity” conversation gets a little weird.

What Does It Mean for a Function to Be “Pure”?

A pure function is one that behaves like that math example above. Same input, same output, no cheating.

But most of the time, our functions aren’t just math—they’re opening files, saving things to databases, talking to APIs, mutating DOM elements, throwing errors, logging things, catching exceptions, and so on.

So let’s slow down and ask: what actually makes a function pure?

1. Isolation

A pure function is totally cut off from the world around it. It only knows what you tell it through its arguments. No peeking at global variables, no reaching into your app state, no relying on the system clock or database. It’s like being blindfolded and asked to solve a puzzle with only the pieces in your hands.

A pure function is isolated. What it does is entirely based on the >inputs you give it.

2. No Side Effects

This is the big one. A side effect is anything a function does besides return a value. Examples include:

Changing a variable outside the function
Mutating the input
Writing to a file or database
Printing to the console
Throwing an error

In other words, side effects are everything that make a function not just a function—but part of a program that’s alive and doing stuff.

A pure function doesn’t change the world. It just gives you an >answer.

3. Referential Transparency

This is a fancy way of saying: if you replace a function call with its output, nothing breaks.

function double(num: number): number {
  return 2 * num;
}

const x = double(3); // is exactly the same as:
const x = 6;

If you can do that and your program still behaves the same, congrats—your function is referentially transparent.

Referential transparency means your functions are predictable and >interchangeable with their outputs.

function double(num: number): number {
  return 2 * num;
}

const x = double(3); // is exactly the same as:
const x = 6;

If you can do that and your program still behaves the same, congrats—your function is referentially transparent.

Referential transparency means your functions are predictable and >interchangeable with their outputs.

So... What’s the Big Deal?
Pure functions are basically the ideal citizen in functional programming land. They’re predictable, testable, composable, and don’t cause trouble. They’re the kind of functions you want to be friends with—quiet, polite, never unexpectedly crash your program.

Here’s the cheat sheet:

✅ No side effects
✅ Input → Output only
✅ Same input = same output (always)

Also, pure functions are idempotent, which means you can call them a million times and get the same result every time. They’re kind of boring that way—in a good way.

Why Testers Love Them
One of the best parts about pure functions? They're a dream to test.

When a function doesn’t rely on anything outside itself, you don’t have to mock a bunch of dependencies or set up elaborate test scaffolding. You just give it an input and check the output.

A pure function is a self-contained little logic machine—perfect >for unit tests.

Since they don’t depend on external state, and always return the same thing for the same input, they’re easy to verify, easy to debug, and hard to break.

Okay, But Where’s the Catch?
All of this sounds great. But remember what I said at the start?

There’s not a whole lot of “purity” in most real-world applications.

That’s because most useful programs need to do things. They need to save data, show things to the user, respond to the world. That means side effects. And side effects mean impurity.

So while pure functions are amazing for logic, you still need a way to connect that logic to the messy, unpredictable world.

Functional programming languages often solve this by separating the pure stuff from the impure stuff. You push all the messy, side-effect-laden code to the edges, and keep the core of your app clean and pure. This way, most of your logic can still be composed, tested, and reasoned about—even if the app itself still has to talk to a database eventually.

Final Thoughts

I’m still figuring this all out, to be honest. The more I explore functional programming, the more I appreciate the beauty of pure functions—and the more I realize how rare they are in practice.

But they’re worth striving for. Pure functions make your code easier to read, test, and trust. They let you build systems that are more predictable and less prone to surprising behavior. And even if you can’t go full-functional, just nudging your code in a purer direction can bring real benefits.

So no, not every function has to be pure. But the more you can keep your logic clean, your dependencies explicit, and your code testable—the easier life tends to get.

Purity isn’t about being perfect. It’s about being intentional. >About knowing where the side effects live—and keeping them on a >short leash.

That’s it for now. I hope this gives you a clearer picture of what pure functions are. Let’s keep learning.

👉 This blogpost was originally publish at my personal blog site

Get in touch

Hey, have any suggestions, questions or concerns, You can find me Twitter, GitHub and LinkedIn. Help me make this better drop me a message and I’ll get back to you soon Thanks!🎉

DEV Community: Jay Gurav

Single Responsibility Principle

World Interpreted

Theory, History, and a Shift in Perspective

Fake Real-World Example

What's wrong with this code?

Applying SRP: Split by Responsibility and ownership

1. Invoice – Owned by Finance/Accounting

2.InvoiceRepository – Owned by Database/Infrastructure team

3.InvoicePrinter – Owned by UX/Design or Docs team

4.Main class (Usage example)

Summary of Responsibilities

Why It Delivers Better Code

Final Thoughts

References

Functions: Am I pure?

Functions, Flashbacks & Functional Programming

What Does It Mean for a Function to Be “Pure”?

1. Isolation

2. No Side Effects

3. Referential Transparency

Final Thoughts

Get in touch

1. `Invoice` – Owned by Finance/Accounting

2.`InvoiceRepository` – Owned by Database/Infrastructure team

3.`InvoicePrinter` – Owned by UX/Design or Docs team