Interface Segregation Principle
ISP says clients should not be forced to depend on methods they do not use. A fat interface combines unrelated capabilities and forces implementations to provide meaningless methods, often resulting in empty implementations or UnsupportedOperationException. I prefer small, cohesive interfaces organized around client needs rather than one large interface representing an entire subsystem.
- 1
Keep interfaces cohesive and client-focused.
- 2
Avoid forcing implementations to support irrelevant operations.
- 3
Smaller interfaces improve mocking and testing.
- 4
ISP reduces accidental coupling between unrelated capabilities.
- 5
Do not split interfaces so aggressively that the design becomes fragmented and difficult to understand.
Scenario Questions
0-2 years experience
- 1We have a `Printer` interface that defines `print()`, `scan()`, and `fax()`. You need to add a `SimplePrinter` that only prints. How would you change the code without breaking existing implementations?
- 2A `Repository` interface includes `save()`, `delete()`, and `update()`. Your new class only needs `save()`. What problems could arise if you keep using the whole interface?
2-5 years experience