Interface Segregation Principle

Introduction

The Interface Segregation Principle (ISP) says clients should not depend on methods they do not use. One fat Worker interface with work(), eat(), sleep() forces robots to implement eat() — nonsense in LLD and production.

Split interfaces by role: Printable, Scannable, Payable. Interviewers notice when you dump unrelated methods on one interface to save drawing time.

ISP reduces mock burden in tests and keeps extension points precise.

Understanding the topic

Key concepts

• Many specific interfaces beat one general-purpose interface.
• Role interfaces describe capabilities clients need.
• Fat interfaces force dummy implementations.
• ISP complements SRP at interface boundary.
• Default methods on interfaces share code without forcing unused ops.
• Client-specific interfaces (adapter layer) when integrating legacy.

Step-by-step explanation

1. List operations each client actually calls.
2. Group related operations into focused interfaces.
3. Classes implement multiple small interfaces as needed.
4. Split fat interface when second client uses subset only.
5. Avoid 'marker' interfaces without behavior unless serializable-style.
6. Review after extension questions — new role may need new interface.

Informative example

Segregated device capabilities instead of monolithic Machine interface:

public interface Printable {
    void print(Document doc);
}

public interface Scannable {
    ScanResult scan();
}

public final class SimplePrinter implements Printable {
    @Override
    public void print(Document doc) { /* ... */ }
}

public final class MultiFunctionDevice implements Printable, Scannable {
    @Override
    public void print(Document doc) { /* ... */ }
    @Override
    public ScanResult scan() { /* ... */ }
}

public final class PrintJobRunner {
    private final Printable printer;

    public PrintJobRunner(Printable printer) { this.printer = printer; }

    public void run(Document doc) { printer.print(doc); }
}

PrintJobRunner depends only on Printable — no scan() in its contract.

Real-world use

Real-world applications

• Device, repository, and notification abstractions.
• Avoiding fat service interfaces in microservices.
• Test doubles implementing minimal surface.

Best practices

• Name interfaces after client capability needed.
• Prefer 2–5 methods per interface in LLD sketches.
• Use composition of interfaces on implementing class.
• Refactor fat interfaces when new client appears.
• Document which clients use which interface.

Common mistakes

• God interface copied from legacy codebase.
• Empty stub methods to satisfy interface.
• One interface per class reflexively (over-segregation).
• Leaking admin methods to user-facing clients.

Advanced interview questions

Summary

Small, role-focused interfaces beat fat ones. Clients depend only on methods they use. Multiple interfaces per class is normal. ISP reduces dummy methods and test mocks. Balance segregation with cohesive APIs.