interface-segregation-principle

To refactor a fat interface, split it into smaller, focused contracts reflecting cohesive capabilities. Update implementations to depend only on the interfaces they need and remove unused methods to avoid throw or no-op workarounds.

The interface segregation principle (ISP) ensures clients are not forced to depend on interfaces they don't use. It promotes smaller, cohesive interfaces that map to actual client needs rather than a single large, fat interface.

Avoiding throw or no-op implementations prevents hidden capabilities and brittle code. Fat interfaces force implementers to provide irrelevant methods, whereas segregated interfaces ensure clients implement only what they can actually deliver.

You need to split interfaces during codebase refactoring when different clients or implementations rely on only a subset of methods. Dividing large interfaces enables compile-time capability checks and improves maintainability.

Yes, interface segregation is applicable during both API design and codebase refactoring. It improves maintainability and testability by creating focused contracts like separating Printer, Scanner, and Fax capabilities.

The best way to identify a fat interface is to look for implementations containing throw or no-op workarounds. If clients rely on only a subset of methods, the interface should be split into focused, cohesive contracts.