How Do SOLID Principles Show Up in Java Code?

SOLID is five principles, and the useful way to answer this question is to show where each one lives in a piece of code rather than reciting the definitions.

Single responsibility means one reason to change. An Invoice should calculate an invoice; it should not also format it, persist it or send it.

Open/closed means open for extension, closed for modification. When you add a new tax rule, the invoice code should not change — you add a new implementation of the tax policy.

Liskov substitution means a subtype must be usable wherever its parent is. If a subclass changes the contract — by throwing where the parent did not, or by weakening a postcondition — the principle is broken.

Interface segregation means small, focused interfaces. A class should not be forced to implement methods it has no use for.

Dependency inversion means depending on abstractions, not on concrete classes. That is what the tax policy interface is: the invoice depends on the interface, and the specific rule is injected.

import java.util.List;

public class Main {
    public static void main(String[] args) {
        // SRP: one reason to change per class.
        Invoice invoice = new Invoice(List.of(1000, 2500));
        // OCP: add a new tax rule without touching the invoice.
        TaxPolicy policy = new VatPolicy(20);
        // DIP: the formatter can be swapped.
        PriceFormatter formatter = new PriceFormatter();

        System.out.println("subtotal : " + formatter.format(invoice.subtotal()));
        System.out.println("total    : " + formatter.format(invoice.total(policy)));
    }
}

class Invoice {
    private final List<Integer> lines;

    Invoice(List<Integer> lines) {
        this.lines = List.copyOf(lines);
    }

    int subtotal() {
        int total = 0;
        for (int line : lines) {
            total += line;
        }
        return total;
    }

    int total(TaxPolicy policy) {
        return subtotal() + policy.taxOn(subtotal());
    }
}

interface TaxPolicy {
    int taxOn(int amount);
}

class VatPolicy implements TaxPolicy {
    private final int percent;

    VatPolicy(int percent) {
        this.percent = percent;
    }

    @Override
    public int taxOn(int amount) {
        return amount * percent / 100;
    }
}

class PriceFormatter {
    String format(int pence) {
        return String.format("£%.2f", pence / 100.0);
    }
}

The output shows the invoice calculating a subtotal of 35 pounds, and a total of 42 pounds once the value added tax is applied. The invoice never mentions the tax rate — it only knows the interface.

Two of the principles are hard to demonstrate in a snippet. Liskov substitution is about what happens when you pass a subtype where the parent is expected, so the example that proves it is one where a subclass would break the contract. Interface segregation is about not fattening an interface with methods an implementor does not need. But all five show up as ordinary decisions about where to put a method, which interface to type a field against, and what to inject.

They answer different questions and they work at different levels. Single responsibility is about the class: it should have one reason to change, so that a change to one concern does not force you to touch a class that is doing something else. Open/closed is about the hierarchy: you should be able to extend the behaviour of a type by adding a new subtype, without editing the code that already uses it.

The distinction matters because people confuse them in both directions. A class can perfectly satisfy single responsibility and still be closed to extension — a class with one job, but with a switch statement inside that job that you have to edit to add a case. And a hierarchy can satisfy open/closed while every class in it violates single responsibility, because each subclass ends up doing several things.

How they interact is the interesting part. Single responsibility is usually what creates the opportunity for open/closed. Once you have separated calculation from formatting, from persistence and from notification, each of those becomes a place where a new variant can be added as a subtype — a new formatter, a new repository, a new notification channel — without touching the code that is already working.

So the workflow is: split the class until each piece has one reason to change, and then look for the pieces that have variants. Those become interfaces with implementations, and the code that used the concrete class now depends on the interface. That is dependency inversion arriving as a consequence of the other two principles rather than as an independent rule.

Here is the same thing as runnable code:

import java.util.List;

public class Main {
    public static void main(String[] args) {
        // The two principles working together.
        Report report = new Report(new ConsoleRenderer());
        report.render("Q3 sales");

        // Adding a renderer is an extension, not a modification.
        report.setRenderer(new FileRenderer());
        report.render("Q3 sales");
    }
}

// One reason to change: the report has one job.
class Report {
    private final List<String> lines = new java.util.ArrayList<>();
    private Renderer renderer;

    Report(Renderer renderer) {
        this.renderer = renderer;
    }

    void setRenderer(Renderer renderer) {
        this.renderer = renderer;
    }

    void add(String line) {
        lines.add(line);
    }

    void render(String title) {
        renderer.render(title, lines);
    }
}

// The abstraction the report depends on.
interface Renderer {
    void render(String title, List<String> lines);
}

class ConsoleRenderer implements Renderer {
    @Override
    public void render(String title, List<String> lines) {
        System.out.println("== " + title + " ==");
        for (String line : lines) {
            System.out.println(line);
        }
    }
}

class FileRenderer implements Renderer {
    @Override
    public void render(String title, List<String> lines) {
        System.out.println("would write " + title + " (" + lines.size() + " lines) to a file");
    }
}