Interface Segregation Principle
Clients should not be forced to depend on methods they don't use, so large interfaces should be split into smaller, role-specific ones.
Also known as: ISP, Role Interfaces, Interface Segregation
Category: Software Development
Tags: software-development, software-design, object-oriented, design-patterns, architecture, maintainability, principles
Explanation
Imagine a `Job` class with dozens of methods: some for printing, some for stapling, some for faxing. A stapling task only needs a few of them. But it depends on all of them. Change a printing method, and the stapling code gets rebuilt and redeployed too.
This actually happened. Robert C. Martin formulated the Interface Segregation Principle (ISP) while consulting for Xerox. Xerox had built a new printer system that could print, staple and fax. As the software grew, a single "fat" `Job` class ended up being used by almost every task, and even the smallest change took a redeployment cycle of an hour. Martin's solution was to put small, task-specific interfaces (a Staple Job interface, a Print Job interface) between the `Job` class and its clients. It's the I in SOLID.
**The principle**:
No client should be forced to depend on methods it does not use. Martin's short version: "Keep interfaces small so that users don't end up depending on things they don't need." These smaller interfaces are often called role interfaces, because each one describes one role a client needs.
**Why it matters**:
- **Fewer ripple effects**: Changes to one group of methods don't force rebuilds, redeploys or re-tests of unrelated clients
- **Clearer code**: A small interface tells you exactly what a piece of code needs
- **Easier testing**: Faking a two-method interface takes a minute; faking a forty-method one takes an afternoon
- **Honest implementations**: Classes don't have to implement methods that make no sense for them (a common source of Liskov violations)
**Signs you need it**:
- Interfaces with many methods that each client only uses partially
- Implementations full of empty methods or `throw new NotImplementedException()`
- A change in one area forcing recompilation or redeployment of unrelated modules
- Test doubles that need dozens of stubs just to compile
**How to apply it**:
1. Look at each interface from the client's side: which methods does each client actually call?
2. Group methods by role, and extract one interface per role
3. Let a class implement several small interfaces if it plays several roles
4. Make each client depend only on the role it needs
Keep in mind that the goal isn't one interface per method. Split along real client needs, and stop there.
**In AI skills**:
ISP maps to opt-in context loading. Instead of loading every dependency every time, an agent declares its dependencies in a DEPENDENCIES.md manifest with three tiers: Always, OnTrigger and Never. Each context only gets what it actually needs.
Related Concepts
← Back to all concepts