Every experienced developer has encountered it: an interface with fifteen methods when you only need two. You implement the interface, write throw new NotImplementedException() for the methods you don't care about, and move on with a vague sense of unease. That unease is your design intuition warning you about a fundamental violation of good software architecture.

The Interface Segregation Principle, the 'I' in SOLID, states that no client should be forced to depend on methods it does not use. It sounds obvious when stated plainly, yet this principle remains one of the most frequently violated in production codebases. The consequences compound silently: unnecessary recompilations, fragile test suites, and implementations littered with dead code that exists only to satisfy a contract nobody asked for.

Understanding ISP transforms how you think about abstractions. Instead of asking what can this thing do, you learn to ask what does each client actually need. This shift in perspective leads to interfaces that are smaller, more focused, and dramatically easier to implement, test, and evolve over time.

Consider a common scenario: a UserService interface with methods for authentication, profile management, password reset, email preferences, account deletion, and audit logging. When you need to write a component that simply validates credentials, you're forced to depend on an abstraction that knows about email templates and GDPR compliance. This isn't just aesthetically unpleasant—it creates concrete problems.

Every method on an interface represents a potential reason for that interface to change. When the audit logging requirements evolve, your authentication component must be recompiled and potentially retested, even though it never touches logging functionality. In large systems, these false dependencies cascade into build times measured in hours and deployment risks that seem disproportionate to the actual changes being made.

The implementation side suffers equally. Teams creating new implementations face a wall of methods, many irrelevant to their use case. They write stub implementations, throw exceptions, or return null—all of which are landmines waiting for an unsuspecting caller. The interface promises capabilities that implementations cannot deliver, breaking the fundamental contract that abstractions are supposed to provide.

Fat interfaces also poison your test suites. Mock objects must implement every method, even when testing code that uses only a fraction of them. Test setup becomes verbose, test intent becomes obscured, and the maintenance burden grows with every method added to the bloated interface. What should be isolated unit tests become entangled with concerns they were never meant to address.

Takeaway

When you find yourself implementing interface methods with NotImplementedException or empty bodies, you're looking at a violation of ISP. The interface is demanding more than your implementation can honestly provide.

The key insight of ISP is that interfaces should be designed from the client's perspective, not the implementer's. Instead of asking what a User object can do, ask what each consumer of user functionality actually requires. An authentication service needs credential validation. A profile page needs display information. An admin panel needs account management. These are three distinct clients with three distinct needs.

Role-based interfaces emerge naturally from this analysis. IAuthenticator handles credential verification. IProfileReader provides display data. IAccountManager controls lifecycle operations. A single class can implement all three interfaces, but each client depends only on the slice it needs. Changes to profile reading cannot affect authentication consumers.

This approach reveals hidden abstractions in your domain. When you decompose a fat interface, you often discover concepts that were previously implicit. The act of naming IPasswordPolicy as a separate interface forces you to recognize password rules as a distinct concern with its own evolution path. Your code becomes more expressive because your interfaces name real concepts rather than arbitrary groupings.

Small interfaces compose beautifully. A method that needs both authentication and profile data can accept both interfaces as parameters, explicitly documenting its actual dependencies. Contrast this with accepting a massive IUserService that obscures which capabilities are actually used. Precise dependencies make code self-documenting and make future refactoring dramatically safer.

Takeaway

Before defining an interface, list every client that will use it and what each client needs. If different clients need different subsets, you're looking at multiple interfaces masquerading as one.

Refactoring a fat interface in a production system requires surgical precision. The good news: ISP violations can be corrected incrementally without the big-bang rewrites that make managers nervous. The strategy relies on a fundamental property of interface inheritance—a class can implement multiple interfaces, and existing code doesn't care which interface reference it holds.

Start by creating the new, focused interfaces as extensions of the existing fat interface. If your bloated IUserService needs splitting, create IAuthenticator and IProfileReader as empty interfaces that extend IUserService. Every existing implementation automatically implements these new interfaces. Every existing client continues working unchanged.

Next, migrate clients one at a time to depend on the appropriate focused interface. Update the authentication module to accept IAuthenticator instead of IUserService. The same object gets passed in; only the declared dependency changes. Each migration is a minimal, low-risk change that can be reviewed, tested, and deployed independently.

Once all clients have migrated to focused interfaces, the inheritance relationship becomes unnecessary. The focused interfaces can declare their own methods, implementations can be updated to implement the specific interfaces they support, and the original fat interface can be deprecated or removed. The transformation completes without any single high-risk commit, and your codebase emerges with cleaner dependencies than before.

Takeaway

Use interface inheritance as a migration bridge: new focused interfaces extend the old fat interface initially, allowing gradual client migration before the final separation. Small, reversible steps beat ambitious rewrites.

Interface Segregation isn't about having more interfaces—it's about having the right interfaces. Each abstraction should represent a cohesive set of capabilities that specific clients actually need. When interfaces grow beyond this scope, they become liabilities that couple unrelated concerns and force implementations into dishonest contracts.

The discipline of ISP pays compound interest over the lifetime of a codebase. Systems built on focused interfaces are easier to test, safer to modify, and more honest about their dependencies. New implementations become tractable because they address specific needs rather than universal fantasies.

Ask of every interface: who are its clients, and do they all need everything it offers? When the answer reveals divergent needs, you've found your signal to segregate. Your future maintainers—including yourself—will thank you for the clarity.