Single responsibility

Your food delivery app sends a bill after every order. One class makes the bill, stores it and emails it.

That works fine, until three teams ask for three different changes in the same week. This lesson shows why that class starts to break, and how to split it.

The problem

Here is the class. It does three jobs:

• total() adds the item prices and a Rs 30 delivery fee.
• save() writes the invoice to the MySQL database.
• sendEmail() mails the total to the customer.

JavaPythonTypeScript

record Invoice(String customer, int[] prices) {
    int total() {
        return 30 + Arrays.stream(prices).sum(); // 30 is the delivery fee
    }

    void save() {
        System.out.println("MySQL: saved invoice for " + customer);
    }

    void sendEmail() {
        System.out.println("Email to " + customer + ": total Rs " + total());
    }
}

In Java, a record is a short class: Java writes the constructor and the getters for you. Python's @dataclass does the same job.

For Asha's order of Rs 250 and Rs 120, save() and then sendEmail() print:

MySQL: saved invoice for Asha
Email to Asha: total Rs 400

Three requests, one class

The same week, three teams ask for changes:

1. Finance: "Add 5% tax to every bill."
2. Platform: "We move from MySQL to PostgreSQL."
3. Marketing: "Send invoices on WhatsApp too."

┌────────────────────────────────────────────────────┐
│                                                    │
│   ┌────────────────────────────┐                   │
│   │ Invoice                    │                   │
│   ├────────────────────────────┤                   │
│   │ - customer: String         │                   │
│   │ - prices: int[]            │                   │
│   ├────────────────────────────┤                   │
│   │ + total(): int             │ ◀ finance         │
│   │ + save(): void             │ ◀ platform        │
│   │ + sendEmail(): void        │ ◀ marketing       │
│   └────────────────────────────┘                   │
│    + public   - private   ◀ who asks for changes   │
│                                                    │
└────────────────────────────────────────────────────┘

All three requests land in the same file. That hurts in three ways:

• Merge conflicts. Three pull requests edit Invoice in the same week.
• Side effects. A typo in the WhatsApp code can break total(), and finance sees wrong bills.
• Slow tests. To test one sum, you load a class that also needs a database and a mail server.

The idea

A class should have only one reason to change.

A reason to change is a person or a team, not a method. Robert C. Martin, who named the principle, says it is about people: each class should answer to one group.

So you split Invoice by who asks for its changes:

┌───────────────────────────────────────────────────┐
│                                                   │
│   ┌──────────────────────┐                        │
│   │ Checkout             │                        │
│   ├──────────────────────┤                        │
│   │ + finish(invoice)    │                        │
│   └──┬───────────────────┘                        │
│      │    ┌──────────────────────┐                │
│      ├──▶ │ Invoice              │ ◀ finance      │
│      │    ├──────────────────────┤                │
│      │    │ + total(): int       │                │
│      │    └──────────────────────┘                │
│      │    ┌──────────────────────┐                │
│      ├──▶ │ InvoiceRepository    │ ◀ platform     │
│      │    ├──────────────────────┤                │
│      │    │ + save(invoice)      │                │
│      │    └──────────────────────┘                │
│      │    ┌──────────────────────┐                │
│      └──▶ │ EmailSender          │ ◀ marketing    │
│           ├──────────────────────┤                │
│           │ + send(invoice)      │                │
│           └──────────────────────┘                │
│    ──▶ uses   + public   ◀ who asks for changes   │
│                                                   │
└───────────────────────────────────────────────────┘

• Invoice holds the order and does the money math. Only finance rules change it.
• InvoiceRepository stores invoices. Only a database change touches it.
• EmailSender delivers the bill. Only messaging changes touch it.
• Checkout runs the steps in order. It holds no rule of its own.

One reason to change does not mean one method. Invoice can have ten methods, as long as all of them are money math.

Find the reasons in three steps

Use this on any class that feels too big:

1. List its methods. For Invoice: total, save, sendEmail.
2. Next to each one, write who would ask to change it. Finance, platform, marketing.
3. Group the methods by that name. Each group becomes one class. A small class such as Checkout then calls them in order.

When every method gets the same name, the class is fine as it is.

The fix

Keep the data and the math in Invoice. Move storage and sending into their own classes. Checkout calls them in order.

JavaPythonTypeScript

record Invoice(String customer, int[] prices) {
    int total() {
        return 30 + Arrays.stream(prices).sum(); // 30 is the delivery fee
    }
}

class InvoiceRepository {
    void save(Invoice invoice) {
        System.out.println("MySQL: saved invoice for " + invoice.customer());
    }
}

class EmailSender {
    void send(Invoice invoice) {
        System.out.println("Email to " + invoice.customer() + ": total Rs " + invoice.total());
    }
}

class Checkout {
    private final InvoiceRepository repository = new InvoiceRepository();
    private final EmailSender emailSender = new EmailSender();

    void finish(Invoice invoice) {
        repository.save(invoice);
        emailSender.send(invoice);
    }
}

Checkout().finish(...) with Asha's order prints the same two lines as before. The behaviour did not change; only the places where each rule lives did.

The three requests again

Marketing's WhatsApp request is now a new class next to EmailSender:

JavaPythonTypeScript

class WhatsAppSender {
    void send(Invoice invoice) {
        System.out.println("WhatsApp to " + invoice.customer() + ": total Rs " + invoice.total());
    }
}

It prints WhatsApp to Asha: total Rs 400. Here is where each request lands now:

Each team now works in its own file. The PostgreSQL change cannot break the tax math, because the two no longer share a class.

How it runs

1. Checkout hands the invoice to the repository, which stores it.
2. Checkout hands the same invoice to EmailSender.
3. EmailSender asks Invoice for the total. It never computes money itself.

When to use it

Signals in the code

• You need "and" to describe the class: "it computes totals and saves them and emails them".
• One file imports unrelated worlds: a SQL driver and a mail client side by side.
• Different teams edit the same file for reasons that have nothing in common.
• A test needs a fake database to check a sum.

When it is too much

• One class per method. If two methods always change together, for the same team, keep them together. Splitting them only adds files to jump between (KISS, from DRY, KISS, YAGNI and composition).
• A small script that runs once. Nobody will ask it to change, so there is no reason to split it.

Look-alikes

Read more

• The Single Responsibility Principle by Robert C. Martin, on why the principle is about people
• Logging HOWTO in the Python docs: loggers, handlers, filters and formatters
• Single-responsibility principle on Wikipedia, with its history

Next: open for extension, closed for change. How to add a new rule as a new class, without editing a class that already works.