Interface Segregation Principle (ISP) - TypeScript & React

Summary: Master the Interface Segregation Principle (ISP). Learn SOLID concepts with practical TypeScript and React examples to write cleaner, more maintainable code.

Introduction

The Interface Segregation Principle (ISP) says that no client should be forced to depend on methods it doesn’t use. Applied well, ISP reduces coupling, simplifies testing, and makes code easier to change and reason about. This guide shows practical TypeScript and React examples you can use today to make your codebase more modular and maintainable.

What is the Interface Segregation Principle?

Imagine a TV remote with 90 buttons when you only need “Play.” That frustration mirrors software where a class must implement a large, unfocused interface. ISP, the “I” in SOLID, encourages designing small, client-specific interfaces rather than one do-it-all contract. This avoids the “fat interface” or “God interface” anti-pattern and leads to clearer, more flexible systems.¹

Why fat interfaces hurt

• Unnecessary dependencies: Classes become coupled to methods they never call, making unrelated changes risky.
• Cognitive overload: Developers must scan irrelevant methods to find what they need.
• Empty implementations: Classes are forced to stub out unused methods, adding boilerplate.

The core idea is simple: give each client exactly what it needs, and nothing more. This makes components easier to understand, test, and evolve.

Monolithic vs. Segregated Interfaces

A side-by-side comparison makes the trade-offs clear.

Choosing ISP helps your codebase stay adaptable as features are added or refactored.

ISP in Practice: Common Violations

Violations don’t break the app but make maintenance painful. Look for classes full of empty methods or components with a large number of optional props.

A classic “God Interface” in TypeScript

// ANTI-PATTERN: A "fat interface" that violates ISP interface IUserActions { createUser(data: UserData): void; editUser(id: string, data: UserData): void; deleteUser(id: string): void; viewUserProfile(id: string): UserProfile; changeUserRole(id: string, newRole: Role): void; publishArticle(article: Article): void; approveComment(commentId: string): void; }

A Viewer class forced to implement this will include meaningless or error-throwing methods. This increases maintenance cost and risk.

Bloated component props in React

A common frontend symptom is a generic Card with many optional props. That creates ambiguity about valid prop combinations and forces complex conditional rendering.

// ANTI-PATTERN: A bloated props interface interface CardProps { title: string; description?: string; imageUrl?: string; imageAltText?: string; videoUrl?: string; authorName?: string; authorAvatarUrl?: string; publicationDate?: string; articleLink?: string; onClick?: () => void; // ... and many more optional props }

These anti-patterns set us up for the refactoring steps below.

How to refactor: Monolithic to Segregated Interfaces

Refactoring to ISP doesn't require a large rewrite. Use small, focused changes to split responsibilities and clarify contracts.

1) Fixing the "God Interface" in TypeScript

Step A: Identify client roles. For example: Admins, Editors, Viewers.

Step B: Create role-specific interfaces.

// GOOD: Focused interfaces interface IViewerActions { viewUserProfile(id: string): UserProfile; }

interface IEditorActions { publishArticle(article: Article): void; approveComment(commentId: string): void; }

interface IAdminActions { createUser(data: UserData): void; editUser(id: string, data: UserData): void; deleteUser(id: string): void; changeUserRole(id: string, newRole: Role): void; }

Step C: Implement only what’s needed.

class Viewer implements IViewerActions { viewUserProfile(id: string): UserProfile { console.log(Fetching profile for user ${id}...); // ... fetch and return profile } }

An Administrator can implement multiple interfaces as needed. This separation reduces unnecessary recompiles and clarifies who owns each capability.

2) Refactoring bloated React props with discriminated unions

Use discriminated unions so each component variant has a clear contract. TypeScript’s union types and discriminators are ideal for this.²

// GOOD: Base props type BaseCardProps = { title: string; onClick?: () => void; };

// GOOD: Specific variants type ImageCardProps = BaseCardProps & { cardType: 'image'; imageUrl: string; imageAltText: string; };

type ArticleCardProps = BaseCardProps & { cardType: 'article'; description: string; authorName: string; articleLink: string; };

type CardProps = ImageCardProps | ArticleCardProps;

With this pattern, the editor immediately enforces valid prop combinations and prevents invalid permutations.

Auditing and enforcing ISP across your team

Making one-time fixes is useful, but embedding ISP into team practices delivers lasting value. Combine clear audit criteria with automated checks to keep interfaces healthy.

Clear audit criteria

Make a shared checklist to spot ISP violations during reviews. Example red flags:

• Interfaces with many methods (worth inspection when above five to seven methods).
• Empty or stubbed methods on implementations.
• Vague interface names using words like “Manager” or “Handler.”
• Component props with lots of optional fields.

A common approach is to pair manual review with automated tools to scale enforcement.

Automating enforcement

ESLint and custom rules are powerful for catching straightforward patterns, like oversized props or classes that implement interfaces but leave methods unimplemented.³ AI coding assistants can also help flag design smells when prompted to review interfaces and implementations.⁴

Both automated checks and human reviews are valuable: tools provide consistency and speed, while humans capture context and business intent.

Use both: let automation handle routine checks and reviewers focus on nuanced design decisions. This pairing improves TDD workflows because smaller interfaces are simpler to mock and test—supporting faster Red-Green-Refactor cycles and clearer unit tests.⁵

ISP and AI-Driven Development

As AI becomes more embedded in development workflows, clear interfaces help tools like GPT-style models reason about code. Small, focused interfaces reduce ambiguity and improve the quality of generated code, automated refactor suggestions, and documentation.⁴

Clean interfaces act like a precise brief for both humans and machines. That clarity reduces guesswork and yields more accurate, reliable AI-assisted changes.

Common ISP Questions

Does ISP mean every method needs its own interface?

No. The goal isn’t to create one-method interfaces everywhere. Group methods that are always used together by the same client. The aim is focused, cohesive interfaces, not fragmentation.

How is ISP different from the Single Responsibility Principle?

SRP applies to classes and says a class should have one reason to change. ISP applies to interfaces and says clients shouldn’t depend on methods they don’t use. You can follow SRP and still violate ISP if a class implements a bloated interface.

When is it okay to ignore ISP?

Mostly when you can’t change the interface—third-party libraries or legacy APIs you don’t own. Also, if every client genuinely needs all methods, a larger interface can still be cohesive and acceptable.

Quick refactor checklist

• Identify roles and clients for each interface.
• Split large interfaces into role-specific contracts.
• Use TypeScript discriminated unions for variant component props.²
• Add lint rules to flag oversized interfaces or props.³
• Combine automated checks with code review for nuanced decisions.

Three concise Q&A (Common developer queries)

Q: How do I spot an ISP violation quickly?

A: Look for interfaces with many unrelated methods, classes with empty or throwing implementations, or components with dozens of optional props. These are strong signs a contract should be split.

Q: What’s the fastest way to fix a “fat interface”?

A: Identify distinct client roles, create focused role-specific interfaces, and update implementations to only implement what they need. Make the change incrementally to avoid risk.

Q: How do I prevent ISP regressions in a growing codebase?

A: Add lint rules and CI checks to detect oversized interfaces and add a review checklist for interface design. Combine automation with periodic manual audits.

At Clean Code Guy, we help teams apply principles like ISP to build maintainable, AI-ready codebases. Get a free codebase audit to find hidden issues and improve long-term maintainability.