What Are the SOLID Principles?

SOLID is five principles that all push in the same direction: small, focused units with narrow contracts between them. Single responsibility says a class should have one reason to change. Open for extension and closed for modification says you should be able to add behaviour by adding code rather than by editing code that already works. Liskov substitution says a subclass must be usable wherever its parent is. Interface segregation says clients should not be forced to depend on methods they do not use. Dependency inversion says high level policy should not depend on low level detail, and both should depend on abstractions.

public class Main {
    public static void main(String[] args) {
        Invoice invoice = new Invoice(new PercentDiscount(10));
        invoice.add(new Item("Book", 20.0));
        invoice.add(new Item("Pen", 5.0));
        System.out.println(invoice.total());
    }
}

interface Discount {
    double apply(double amount);
}

class PercentDiscount implements Discount {
    private final double percent;
    PercentDiscount(double percent) { this.percent = percent; }
    public double apply(double amount) { return amount * (1 - percent / 100); }
}

class Item {
    final String name;
    final double price;
    Item(String name, double price) { this.name = name; this.price = price; }
}

class Invoice {
    private final java.util.List<Item> items = new java.util.ArrayList<>();
    private final Discount discount;
    Invoice(Discount discount) { this.discount = discount; }
    void add(Item item) { items.add(item); }
    double total() {
        double sum = 0;
        for (Item i : items) { sum += i.price; }
        return discount.apply(sum);
    }
}

The invoice example touches several of them. The invoice class has a single reason to change, which is the way totals are calculated. The discount is a strategy behind an interface, so adding a fixed amount discount or a loyalty discount means writing a new class and nothing else. The invoice does not know what kind of discount it is using, which is the dependency inversion principle at work: the high level policy depends on the abstraction rather than on a concrete calculator.

The important qualification is that SOLID is not a checklist to apply mechanically. Each principle costs something. Narrow contracts mean more interfaces, and each one is a place where a change can ripple. The practical goal is not maximal decomposition but classes that change for one reason each, and the ability to add a variation without editing working code.

It breaks the Liskov substitution principle. The square inherits resize from the rectangle and then refuses to honour it, which means a square is not a safe substitute for a rectangle. Code that receives a rectangle reference and calls resize works for one shape and blows up for the other, and the caller has no way to know in advance.

public class Main {
    public static void main(String[] args) {
        Rectangle s = new Square(3);
        System.out.println(s.area());
        System.out.println(s.describe());
        try {
            s.resize(4, 4);
        } catch (UnsupportedOperationException e) {
            System.out.println("refused: " + e.getMessage());
        }
    }
}

class Rectangle {
    protected double width;
    protected double height;
    Rectangle(double width, double height) { this.width = width; this.height = height; }
    double area() { return width * height; }
    void resize(double w, double h) { width = w; height = h; }
    String describe() { return "rect " + width + "x" + height; }
}

class Square extends Rectangle {
    Square(double side) { super(side, side); }
    void resize(double w, double h) {
        throw new UnsupportedOperationException("a square cannot be resized");
    }
    String describe() { return "square " + width + "x" + height; }
}

The output makes the violation visible. The area and the description work, so the square looks like a rectangle at first glance. The resize call is where the contract breaks, and the exception message says exactly what happened.

The fix is to stop modelling square as a kind of rectangle when their behaviour differs. Model them as siblings behind a shared interface that contains only what both genuinely support, such as area and describe, and leave resize on the rectangle alone. The square then has no inherited method it cannot honour, and code that needs to resize can ask for a rectangle specifically rather than for a shape.

The broader lesson is the one SOLID keeps repeating: an abstraction should describe the common behaviour, not the union of everything the subtypes might one day need. The moment you add a method to a base type that only some subtypes support, you have created the conditions for exactly this kind of violation.

Single responsibility solves the problem of classes that change for unrelated reasons. If a class has one reason to change, a new requirement touches one place.

Open for extension, closed for modification solves the problem of stable code that has to be edited whenever something new is required. Extending through new classes and new interfaces keeps working code untouched.

Liskov substitution solves the problem of hierarchies where a subtype quietly breaks its parent's promise. It guarantees that polymorphism is safe, because every subclass really can stand in for its parent.

Interface segregation solves the problem of fat contracts that force implementors to write methods they do not support and force callers to depend on behaviour they do not use.

Dependency inversion solves the problem of code that is welded to concrete details. Depending on abstractions in the direction of the policy keeps the high level rules independent of the low level machinery.

All five are really one idea expressed five ways: keep the reason for change in one place, and keep the connections between places narrow. That is worth saying in an interview, because it shows you understand the principles rather than the acronyms.