Open-Closed Principle

Open for extension means you can add new behaviour by adding new code. Closed for modification means you do not have to change code that already works. The two together are what let a system absorb new requirements without a cascade of edits through code that was previously correct.

public class Main {
    public static void main(String[] args) {
        Order order = new Order();
        order.add(new Line("Book", 20.0));
        order.add(new Line("Pen", 5.0));
        System.out.println(order.total(new NoDiscount()));
        System.out.println(order.total(new HalfPrice()));
    }
}

interface Discount {
    double apply(double amount);
}

class NoDiscount implements Discount {
    public double apply(double amount) { return amount; }
}

class HalfPrice implements Discount {
    public double apply(double amount) { return amount / 2; }
}

class Line {
    final String product;
    final double price;
    Line(String product, double price) { this.product = product; this.price = price; }
    double price() { return price; }
}

class Order {
    private final java.util.List<Line> lines = new java.util.ArrayList<>();
    void add(Line l) { lines.add(l); }
    double total(Discount discount) {
        double sum = 0;
        for (Line l : lines) { sum += l.price(); }
        return discount.apply(sum);
    }
}

The order class is the fixed part. It knows how to total a basket and nothing about the kinds of discount that exist. The discount strategy is what varies, and each variation is a new class that implements the contract. The output shows the same order priced two different ways, and adding a loyalty discount or a bulk discount later would be another class, with no edit to the order at all.

That is the mechanism the principle is really describing: extension happens through new types that fit an existing contract, and the modification happens only in the new type. The code that was correct yesterday is untouched.

Two honest caveats. The principle only works when there is a stable contract to extend, and the more variants you have, the more the strategy mechanism has to be paid for in indirection. And there are places where modification is genuinely the right answer, such as a small set of well-understood branches where a new case is clearly a case of the same thing. The principle is a guideline about where the pressure to change should land, not a law.

Find the point of variation and turn it into a contract. If the behaviour varies by type, define an interface for the varying part and pass the implementation in. If it varies by condition, use a strategy object or a parameterised function instead of a chain of conditionals inside the existing method.

Then add a new class that implements the contract. The existing code already talks to the abstraction, so it needs no change, and the new behaviour arrives with the new class. That is extension without modification, and it is why the interface has to be the thing the existing code depends on rather than the concrete class.

There are two other approaches worth naming. The open-closed principle can also be satisfied with a plugin registry, where the existing code looks up a behaviour by name at run time, and with a template method in an abstract class, where the base class owns the sequence and new subclasses fill in the varying steps.

The practical check for a review is to ask whether adding the next requirement would require editing code that already worked. If the answer is yes and you cannot easily point to a contract to extend, that is the pressure point to refactor before the next requirement arrives, not after.