SOLID principles

Why principles?

Code that works today must change tomorrow: new payment methods, new tax rules, new report formats. Badly structured code makes every change risky. SOLID, named by Robert C. Martin, summarises habits that make change cheaper. Treat them as guidelines, not laws.

S: Single responsibility

// Before: one class with three reasons to change
class InvoiceService {
    double total(Invoice i) { … }          // tax rules change
    byte[] toPdf(Invoice i) { … }          // PDF layout changes
    void email(Invoice i) { … }            // email provider changes
}
// After: one job each
class InvoiceCalculator { double total(Invoice i) { … } }
class InvoicePdfRenderer { byte[] render(Invoice i) { … } }
class InvoiceMailer { void send(Invoice i, byte[] pdf) { … } }

O: Open/closed

Classes should be open for extension but closed for modification: add new behaviour by adding code, not by editing a growing if/else chain. Polymorphism is the usual tool.

interface DiscountRule { double apply(double amount); }
class FestivalDiscount implements DiscountRule { public double apply(double a) { return a * 0.9; } }
class MemberDiscount implements DiscountRule { public double apply(double a) { return a > 500 ? a - 50 : a; } }
// A new rule = a new class; the checkout code that loops over List<DiscountRule> never changes.

L: Liskov substitution

Anywhere the code expects a parent type, any subclass must work without surprises. The classic violation: Square extends Rectangle. Setting a Rectangle's width should not change its height, but a Square must keep both equal, so code that works with rectangles breaks with squares. If a subclass has to throw UnsupportedOperationException for an inherited method, the inheritance is probably wrong.

I: Interface segregation

// Too big: a simple printer must implement scan and fax
interface OfficeMachine { void print(Doc d); void scan(Doc d); void fax(Doc d); }
// Better: small, focused interfaces
interface Printer { void print(Doc d); }
interface Scanner { void scan(Doc d); }
class BasicPrinter implements Printer { public void print(Doc d) { … } }

D: Dependency inversion

High-level code (OrderService) should depend on abstractions (a PaymentGateway interface), not on concrete details (RazorpayGateway). The details implement the abstraction. Spring's dependency injection (module 11) is built around this principle.