# Interface Segregation Principle (ISP)

> Split fat interfaces into focused ones — no class should be forced to implement methods it will never use.

- **Category**: Solid
- **Subcategory**: principles
- **Canonical URL**: https://designpattern.fyi/patterns/interface-segregation/

---

## Description
**Intent**: Large interfaces force implementing classes to provide stub or error implementations for methods that don't apply to them — dead code, broken contracts, and unnecessary coupling.

**Context**: A Robot class extends Worker and is forced to implement eat() and sleep() — methods that make no sense for a robot. Every change to those methods ripples to Robot even though it's irrelevant. The interface has leaked its assumptions about humans into an unrelated class.

**Solution**: Break the large interface into smaller, focused ones. A robot implements only Workable. A human implements Workable, Eatable, and Sleepable. Each implementor depends only on the contract it actually honors.



## Use Cases
Interfaces have methods that aren't always needed together. Classes are forced to implement methods they'll never call. You want to reduce the blast radius of interface changes to only the classes that care.



## Implementation Example

```javascript
// Before: Large interface
class Worker {
  work() {
    console.log('Working');
  }

  eat() {
    console.log('Eating lunch');
  }

  sleep() {
    console.log('Sleeping');
  }
}

class Robot extends Worker {
  eat() {
    throw new Error('Robots dont eat'); // Forced to implement
  }

  sleep() {
    throw new Error('Robots dont sleep'); // Forced to implement
  }
}

// After: ISP applied
class Workable {
  work() {
    throw new Error('Must implement work');
  }
}

class Eatable {
  eat() {
    throw new Error('Must implement eat');
  }
}

class Sleepable {
  sleep() {
    throw new Error('Must implement sleep');
  }
}

class Human implements Workable, Eatable, Sleepable {
  work() { console.log('Working'); }
  eat() { console.log('Eating'); }
  sleep() { console.log('Sleeping'); }
}

class Robot implements Workable {
  work() { console.log('Working'); }
  // No need to implement eat or sleep
}
```



## Trade-offs


### Advantages

- Small interfaces are easy to understand, implement, and document

- Clients depend only on what they actually use — no phantom coupling

- Interface changes ripple only to the classes that are genuinely affected




### Considerations & Drawbacks

- More interfaces to name, manage, and discover

- Over-segregation produces so many micro-interfaces it becomes its own maintenance burden

- Requires discipline to resist collapsing them back into one big contract