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

Master the Interface Segregation Principle (ISP) to reduce coupling and write modular TypeScript and React code that’s easier to test and change. This guide explains ISP with clear examples, practical refactoring steps, and tooling advice to keep interfaces focused and maintainable. TypeScript adoption is growing on GitHub, so these patterns are widely applicable across modern frontend and backend codebases.⁶

What is the Interface Segregation Principle?

The Interface Segregation Principle (ISP) says that no client should be forced to depend on methods it doesn’t use. ISP, the “I” in SOLID, encourages designing small, client-specific interfaces rather than one do-it-all contract, avoiding the “fat interface” or “God interface” anti-pattern.¹

Why fat interfaces hurt

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

Give each client exactly what it needs and nothing more. That leads to components that are 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.

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 testing 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.

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.

Practical links and internal references

• SOLID principles guide: SOLID guide
• TypeScript patterns and advanced types: TypeScript patterns
• ESLint rules and examples: ESLint custom rules

Three concise Q&A

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 incrementally so each class or component only implements what it needs.

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

A: Add lint rules and CI checks to detect oversized interfaces, maintain a review checklist for interface design, and 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.