System Design (HLD)Interface Segregation Principle

What Is ISP?

LevelIntermediate

Duration60 mins

TopicInterface Segregation Principle

2 / 4

ISP and Interface Design

Rethinking Interface Design

Interfaces are contracts. They define the shape of a promise: "If you program against me, here's what you can expect." But not all contracts are created equal. Some contracts are specific and clear; others are sprawling and ambiguous.

The Interface Segregation Principle fundamentally reshapes how we think about interface design. Instead of asking "What should this abstraction be able to do?", ISP teaches us to ask "Who will use this abstraction, and what do they need from it?"

This shift from capability-centric to client-centric design is subtle but transformative. It moves the designer's perspective from the provider's side of the interface to the consumer's side. And that perspective shift changes everything.

What You Will Learn

This page explores ISP's deep relationship with interface design. You'll learn to identify natural interface boundaries, design interfaces from the client's perspective, understand role interfaces vs. capability interfaces, and apply systematic techniques for achieving ISP-compliant designs.

The Client-Centric Design Paradigm

Traditional object-oriented design often starts with the thing being modeled. We ask: "What is a Document? What can it do?" Then we create an interface that captures those capabilities.

ISP inverts this approach. Instead of starting with the abstraction's inherent capabilities, we start with the question: "Who needs this abstraction, and for what purpose?"

This is the client-centric design paradigm.

Provider-Centric (Traditional)

•"A User can login, logout, update profile, delete account, and change settings"
•Interface designed around what the entity IS
•All capabilities bundled together
•Single interface grows with entity capabilities
•Changes affect all clients uniformly

Client-Centric (ISP)

•"The auth system needs login/logout; the profile service needs profile updates"
•Interfaces designed around what clients NEED
•Capabilities segregated by usage patterns
•Multiple focused interfaces for different clients
•Changes isolated to affected clients only

The Discovery Process:

Client-centric design requires understanding your actual clients. This isn't guesswork — it's analysis:

Identify all consumers — Who or what will use this interface? List every service, module, or component that needs this abstraction.
Map usage patterns — For each consumer, which methods do they actually call? Create a matrix of consumers vs. methods.
Find natural groupings — Look for methods that are always used together by the same clients. These form natural interface boundaries.
Name the roles — Each grouping represents a role the abstraction plays. Name it by that role, not by the entity.
Validate independence — Ensure changes to one interface don't require changes to another. If they do, the boundary might be wrong.

The Interface Discovery Matrix

Create a simple table: consumers as rows, methods as columns. Mark which methods each consumer uses. Clusters of marks reveal natural interface boundaries. Methods always used together belong to the same interface. This exercise often reveals surprising insights about how code is actually used.

interface-discovery-example.md
Markdown
## Interface Discovery Matrix: User Entity
 
| Consumer           | login | logout | getProfile | updateProfile | deleteAccount | changePassword |
|--------------------|-------|--------|------------|---------------|---------------|----------------|
| AuthService        |   ✓   |   ✓    |            |               |               |       ✓        |
| ProfileService     |       |        |     ✓      |       ✓       |               |                |
| AccountService     |       |        |            |               |       ✓       |                |
| SessionManager     |   ✓   |   ✓    |            |               |               |                |
| AdminDashboard     |       |        |     ✓      |               |       ✓       |                |
 
## Natural Interface Boundaries Revealed:
 
1. **Authenticatable** (login, logout, changePassword)
   - Used by: AuthService, SessionManager
   
2. **ProfileManageable** (getProfile, updateProfile)
   - Used by: ProfileService, AdminDashboard
 
3. **AccountDeletable** (deleteAccount)
   - Used by: AccountService, AdminDashboard
 
Note: AdminDashboard crosses boundaries because it's a composite view.
This is normal — high-level coordinators often need multiple interfaces.

Role Interfaces: The ISP Ideal

Martin Fowler introduced the term Role Interface to describe interfaces designed from the client's perspective. A role interface defines the role an object plays for a specific client, rather than describing the object's complete identity.

Role Interface vs. Header Interface:

The traditional approach creates header interfaces — interfaces that mirror the public methods of a class. If your class has 20 public methods, your interface has 20 methods. This is provider-centric design.

Role interfaces are different. They answer: "What role does this object play in this specific context?" An object might play multiple roles for different clients, each defined by a separate interface.

role-vs-header-interfaces.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
// ❌ HEADER INTERFACE: Mirrors the class's public API
interface UserService {
    // Authentication
    login(credentials: Credentials): Promise<Session>;
    logout(session: Session): Promise<void>;
    changePassword(userId: string, newPassword: string): Promise<void>;
    resetPassword(email: string): Promise<void>;
    
    // Profile management
    getProfile(userId: string): Promise<UserProfile>;
    updateProfile(userId: string, updates: ProfileUpdates): Promise<void>;
    uploadAvatar(userId: string, image: Buffer): Promise<string>;
    
    // Account management
    createAccount(data: AccountData): Promise<User>;
    deleteAccount(userId: string): Promise<void>;
    suspendAccount(userId: string, reason: string): Promise<void>;
    
    // Preferences
    getPreferences(userId: string): Promise<Preferences>;
    updatePreferences(userId: string, prefs: Preferences): Promise<void>;
    
    // Social features
    followUser(followerId: string, followeeId: string): Promise<void>;
    unfollowUser(followerId: string, followeeId: string): Promise<void>;
    getFollowers(userId: string): Promise<User[]>;
}
 
// A mobile client that only shows profiles must depend on ALL of this!
// It can't even import just what it needs.
 
 
// ✅ ROLE INTERFACES: Designed around specific client needs
 
// The role this object plays for authentication clients
interface Authenticator {
    login(credentials: Credentials): Promise<Session>;
    logout(session: Session): Promise<void>;
    changePassword(userId: string, newPassword: string): Promise<void>;
    resetPassword(email: string): Promise<void>;
}
 
// The role this object plays for profile viewing/editing clients
interface ProfileManager {
    getProfile(userId: string): Promise<UserProfile>;
    updateProfile(userId: string, updates: ProfileUpdates): Promise<void>;
    uploadAvatar(userId: string, image: Buffer): Promise<string>;
}
 
// The role this object plays for account administration clients
interface AccountAdministrator {
    createAccount(data: AccountData): Promise<User>;
    deleteAccount(userId: string): Promise<void>;
    suspendAccount(userId: string, reason: string): Promise<void>;
}
 
// The role for preference management
interface PreferenceStore {
    getPreferences(userId: string): Promise<Preferences>;
    updatePreferences(userId: string, prefs: Preferences): Promise<void>;
}
 
// The role for social graph operations
interface SocialGraph {
    followUser(followerId: string, followeeId: string): Promise<void>;
    unfollowUser(followerId: string, followeeId: string): Promise<void>;
    getFollowers(userId: string): Promise<User[]>;
}
 
// Now each client depends only on its specific role interface
class MobileProfileViewer {
    constructor(private profiles: ProfileManager) {}  // Only what it needs!
    
    async displayProfile(userId: string): Promise<void> {
        const profile = await this.profiles.getProfile(userId);
        this.render(profile);
    }
}
 
class AdminPanel {
    constructor(
        private auth: Authenticator,      // For password resets
        private accounts: AccountAdministrator  // For account ops
    ) {}
    // Doesn't know about profiles, preferences, or social features
}

The Object Behind the Roles

The same concrete class can implement all role interfaces. A UserServiceImpl might implement Authenticator, ProfileManager, AccountAdministrator, PreferenceStore, and SocialGraph. The segregation is in the interfaces (what clients see), not necessarily in the implementation (what provides the service).

Naming Role Interfaces:

Role interfaces should be named by the role they represent, not by the entity they abstract. Compare:

Header Interface Name	Role Interface Names
`User`	`Authenticatable`, `ProfileOwner`, `AccountHolder`
`File`	`Readable`, `Writable`, `Deletable`, `Seekable`
`Order`	`Purchasable`, `Shippable`, `Trackable`, `Refundable`
`Payment`	`Chargeable`, `Refundable`, `Disputable`

Notice how role names often end in adjective suffixes like -able, -ible, or -er/-or. This isn't a strict rule, but it often naturally emerges because roles describe what something can do for a specific client, not what it is.

Benefits of Role Interfaces

•Focused Testing — Tests for a client only need to mock the role interface, not a god interface with dozens of methods
•Documentation Clarity — Role interfaces are self-documenting; their name and methods explain their purpose
•Compile-Time Enforcement — Type systems prevent clients from accidentally using methods they shouldn't
•Dependency Clarity — A class's constructor reveals exactly which roles it needs, making dependencies explicit
•Substitutability — Easy to swap implementations when interfaces are focused; fewer methods to implement

Interface Cohesion: When Methods Belong Together

Just as SRP asks about class cohesion, ISP asks about interface cohesion: Do all methods in this interface belong together?

Cohesion in interfaces means that the methods form a coherent unit of functionality that clients naturally use together. High cohesion means every method in the interface relates to the same purpose; low cohesion means methods serve different, unrelated purposes that happen to share an interface.

Measuring Interface Cohesion:

Several heuristics help evaluate interface cohesion:

Cohesion Indicators

•Usage Correlation — If clients that use method A almost always use method B, they belong together. If method A and method C are never used by the same client, they may belong apart.
•Change Correlation — If modifying method A semantically requires reviewing method B, they're tightly related. If method A can change with no implications for method C, they might be independent.
•Parameter Sharing — Methods that take similar parameters often belong together (they operate on the same conceptual data).
•Return Type Relationships — If method A returns something that method B consumes, they're naturally paired.
•Single Sentence Test — Can you describe what this interface does in one sentence without using "and"? If you need "and", it might have low cohesion.

cohesion-analysis.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// ❌ LOW COHESION: "This interface handles authentication AND profile management"
interface UserAccount {
    login(email: string, password: string): Promise<Session>;
    logout(session: Session): Promise<void>;
    getProfile(): UserProfile;
    updateProfile(updates: ProfileUpdates): Promise<void>;
}
 
// Analysis:
// - login() and logout() operate on sessions; unrelated to profiles
// - getProfile() and updateProfile() operate on profile data; unrelated to auth
// - A profile viewer doesn't need login(); an auth service doesn't need getProfile()
// - Sentence: "Handles logins AND profile management" — the "AND" reveals low cohesion
 
 
// ✅ HIGH COHESION: Each interface has a single, coherent purpose
 
interface SessionManager {
    login(email: string, password: string): Promise<Session>;
    logout(session: Session): Promise<void>;
    validateSession(session: Session): Promise<boolean>;
}
 
// Analysis:
// - All methods operate on Session concept
// - Clients using login() will likely need logout() and validateSession()
// - Sentence: "Manages session lifecycle" — no "AND"
 
interface ProfileEditor {
    getProfile(): UserProfile;
    updateProfile(updates: ProfileUpdates): Promise<void>;
    getProfileHistory(): ProfileRevision[];
}
 
// Analysis:
// - All methods operate on UserProfile concept
// - Clients that read profiles often also update or audit them
// - Sentence: "Manages user profile data" — no "AND"

The Over-Segregation Trap

Cohesion analysis can go too far. An interface with only one method isn't necessarily better than one with five. If those five methods are always used together and change together, they form a cohesive unit. ISP isn't about making interfaces as small as possible — it's about making them as focused as necessary.

Cohesion Through Domain Modeling:

Often, proper cohesion emerges from understanding the domain. Domain-Driven Design concepts help:

Aggregates — A cluster of domain objects treated as a unit. Interface methods operating on the same aggregate often belong together.
Bounded Contexts — Different contexts may use the same entity differently. Each context suggests different interfaces.
Domain Events — Methods that produce or consume the same domain events are related.

When interface boundaries align with domain boundaries, cohesion tends to be high naturally. Misaligned boundaries (e.g., an interface spanning two aggregates) tend toward low cohesion.

Interface Composition Patterns

When you segregate interfaces, you need strategies for combining them. ISP doesn't mean abandoning comprehensive abstractions — it means building them from focused pieces.

Pattern 1: Interface Inheritance (Extension)

Smaller interfaces extend into larger ones when clients genuinely need the combined functionality.

interface-composition.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Building larger interfaces from smaller ones through extension
 
interface Readable {
    read(): Buffer;
    readLine(): string;
}
 
interface Writable {
    write(data: Buffer): void;
    writeLine(line: string): void;
}
 
interface Seekable {
    seek(position: number): void;
    getPosition(): number;
}
 
interface Closable {
    close(): void;
    isClosed(): boolean;
}
 
// Composition through extension: only combined when clients need both
interface ReadWriteStream extends Readable, Writable {}
 
// Full file interface for clients that need everything
interface RandomAccessFile extends Readable, Writable, Seekable, Closable {}
 
// Clients choose their level of abstraction:
class LogReader {
    constructor(private source: Readable) {}  // Only needs reading
}
 
class DataCopier {
    constructor(
        private source: Readable,
        private destination: Writable  // Separate dependencies
    ) {}
}
 
class DatabaseFile {
    constructor(private file: RandomAccessFile) {}  // Needs everything
}

Pattern 2: Intersection Types (TypeScript/Flow)

In languages with intersection types, you can combine interfaces on-demand without pre-defined composite interfaces.

intersection-types.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// On-demand composition using intersection types
 
interface Identifiable {
    getId(): string;
}
 
interface Timestamped {
    getCreatedAt(): Date;
    getUpdatedAt(): Date;
}
 
interface Auditable {
    getAuditLog(): AuditEntry[];
}
 
// Functions declare exactly what they need, no pre-defined composite
function archiveRecord(record: Identifiable & Timestamped): void {
    console.log(`Archiving ${record.getId()} from ${record.getCreatedAt()}`);
}
 
function fullAudit(entity: Identifiable & Timestamped & Auditable): AuditReport {
    return {
        entityId: entity.getId(),
        created: entity.getCreatedAt(),
        updated: entity.getUpdatedAt(),
        events: entity.getAuditLog(),
    };
}
 
// Any object meeting the intersection can be passed
class Order implements Identifiable, Timestamped, Auditable {
    getId(): string { return this.orderId; }
    getCreatedAt(): Date { return this.createdDate; }
    getUpdatedAt(): Date { return this.updatedDate; }
    getAuditLog(): AuditEntry[] { return this.auditEntries; }
}
 
const order = new Order();
archiveRecord(order);  // Works - Order satisfies Identifiable & Timestamped
fullAudit(order);      // Works - Order satisfies all three

Pattern 3: Adapter Composition

Sometimes you inherit a fat interface and need to expose a segregated view. Adapters bridge the gap.

adapter-composition.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// Given a legacy fat interface from a third-party library
interface LegacyRepository {
    findById(id: string): Entity;
    findAll(): Entity[];
    save(entity: Entity): void;
    update(entity: Entity): void;
    delete(id: string): void;
    executeQuery(sql: string): any[];
    beginTransaction(): void;
    commit(): void;
    rollback(): void;
}
 
// We want segregated interfaces for our clients
interface EntityReader {
    findById(id: string): Entity;
    findAll(): Entity[];
}
 
interface EntityWriter {
    save(entity: Entity): void;
    update(entity: Entity): void;
    delete(id: string): void;
}
 
// Adapters expose only the relevant slice
class ReadOnlyRepositoryAdapter implements EntityReader {
    constructor(private legacy: LegacyRepository) {}
    
    findById(id: string): Entity {
        return this.legacy.findById(id);
    }
    
    findAll(): Entity[] {
        return this.legacy.findAll();
    }
}
 
class WriteRepositoryAdapter implements EntityWriter {
    constructor(private legacy: LegacyRepository) {}
    
    save(entity: Entity): void {
        this.legacy.save(entity);
    }
    
    update(entity: Entity): void {
        this.legacy.update(entity);
    }
    
    delete(id: string): void {
        this.legacy.delete(id);
    }
}
 
// Clients depend on focused interfaces, not the legacy monster
class ReportGenerator {
    constructor(private dataSource: EntityReader) {}  // Read-only access
}
 
class ImportService {
    constructor(private writer: EntityWriter) {}  // Write-only access
}

Choose Your Composition Strategy

Interface extension works when composites are stable and widely used. Intersection types work for ad-hoc combinations. Adapters work for legacy integration. Choose based on your context — there's no universally 'best' approach.

ISP Beyond Classical OOP

ISP's principle — minimize unnecessary dependencies — applies beyond interface-based OOP designs.

ISP in Functional Programming:

In FP, "interfaces" manifest as function signatures, type classes, or protocols. The ISP equivalent: functions should require only the data they need.

-- ❌ Requires the whole User even though it only needs the email
sendWelcome :: User -> IO ()
sendWelcome user = sendEmail (userEmail user) "Welcome!"

-- ✅ Requires only the email it actually uses
sendWelcome :: EmailAddress -> IO ()
sendWelcome email = sendEmail email "Welcome!"

The refined version is easier to test (no User fixture needed), more reusable (works with any email source), and documents its actual dependencies.

ISP in API Design:

REST and GraphQL APIs face ISP considerations:

❌ Fat Endpoint: GET /users/{id}
Returns: name, email, address, payment_info, order_history, preferences, social_connections, ...

Problem: Mobile app showing user name fetches (and pays bandwidth for) payment info it never displays.

✅ Segregated Endpoints:
GET /users/{id}/profile (name, email, avatar)
GET /users/{id}/address
GET /users/{id}/payment-methods
GET /users/{id}/orders

Or: GraphQL where clients request exactly the fields they need.

ISP in Module/Package Design:

At the module level, ISP suggests splitting large modules if different clients need different subsets:

❌ Single module: utils (string utils, date utils, crypto utils, http utils)
   Every importer depends on all utilities, transitively pulling in crypto and http libraries.

✅ Segregated modules:
   - string-utils (no dependencies)
   - date-utils (no dependencies)
   - crypto-utils (depends on crypto library)
   - http-utils (depends on http library)
   
   Clients import only what they need; dependency graphs stay lean.

ISP Manifestations Across Paradigms
Paradigm	ISP Equivalent	Violation Symptom
OOP Interfaces	Segregated role interfaces	Classes implement methods with 'throw NotImplemented'
Functional Types	Minimal function parameters	Functions receive large records but use few fields
REST APIs	Resource-specific endpoints	Endpoints return massive payloads with mostly unused data
GraphQL	Schema design, field resolvers	Over-connected schemas forcing unnecessary field resolution
Modules/Packages	Focused module boundaries	Importing a module pulls in heavy transitive dependencies
Microservices	Service API contracts	Service APIs bundling unrelated operations

Universal Principle, Local Syntax

The underlying wisdom of ISP — don't force dependencies on things you don't use — transcends any particular syntax or paradigm. Whether you're designing interfaces, function signatures, APIs, or module boundaries, the principle guides you toward designs that minimize unnecessary coupling.

Practical Guidelines for Interface Design

Let's distill the concepts into actionable guidelines for daily practice.

Design-Time Guidelines

•Start with clients, not capabilities — Before defining an interface, identify who will use it. Let client needs drive the method selection.
•Apply the 'method usage matrix' — Map clients to methods. If clear clusters appear, you have natural interface boundaries.
•Prefer many small interfaces to few large ones — But don't over-segregate. Methods that change together and are used together should stay together.
•Name by role, not entity — Interface names should reflect what the interface represents to its clients (Readable, Printable) not what type it abstracts (Document).
•Use composition for complex needs — If some clients need combinations of roles, use interface extension or intersection types rather than creating monolithic interfaces.

Review-Time Checks

•Scan for throw NotImplemented — Any method implemented by throwing an exception is a red flag for ISP violation.
•Check for empty implementations — Methods with empty bodies or stub returns often indicate forced implementation.
•Look for conditional type checks — Client code that checks concrete types before calling methods suggests the interface is too broad.
•Measure import footprint — If importing one feature pulls in many unrelated dependencies, modules may be too coarse.
•Ask: Can I describe this interface without 'and'? — If not, consider whether it combines multiple roles.

The Evolution Approach

You don't need perfect interfaces from day one. Start with what you know. As new clients emerge with different needs, refactor to segregate. ISP-compliant design often evolves iteratively rather than being designed perfectly upfront.

Summary: ISP-Driven Interface Design

We've explored how ISP fundamentally shapes the philosophy and practice of interface design.

Key Takeaways

•Client-centric design — Start by understanding who uses the interface and what they need, not what the abstraction could do.
•Role interfaces over header interfaces — Define interfaces by the role an object plays for a client, not by mirroring the object's public API.
•Cohesion matters — Methods in an interface should be used together and change together. Apply the single-sentence test.
•Composition strategies — Use extension, intersection types, or adapters to build larger interfaces from smaller pieces.
•ISP is universal — The principle applies to functional programming, API design, and module boundaries — anywhere dependencies exist.
•Evolution is okay — Perfect segregation isn't required upfront. Refactor as you discover how clients actually use your code.

What's Next:

With a solid understanding of how ISP guides interface design, we'll next examine the concrete problem ISP solves: fat interfaces. The next page explores what makes interfaces 'fat', why fat interfaces emerge, and the specific problems they cause in practice.

Page Complete

You now understand ISP's relationship with interface design philosophy. You can identify client-centric vs. provider-centric designs, recognize role interfaces, evaluate interface cohesion, and apply composition patterns. Next: Why Fat Interfaces Are Problematic.

2 / 4

Loading learning content...

System Design (HLD)Interface Segregation Principle

What Is ISP?

LevelIntermediate

Duration60 mins

TopicInterface Segregation Principle

2 / 4

ISP and Interface Design

Rethinking Interface Design

What You Will Learn

The Client-Centric Design Paradigm

Traditional object-oriented design often starts with the thing being modeled. We ask: "What is a Document? What can it do?" Then we create an interface that captures those capabilities.

ISP inverts this approach. Instead of starting with the abstraction's inherent capabilities, we start with the question: "Who needs this abstraction, and for what purpose?"

This is the client-centric design paradigm.

Provider-Centric (Traditional)

•"A User can login, logout, update profile, delete account, and change settings"
•Interface designed around what the entity IS
•All capabilities bundled together
•Single interface grows with entity capabilities
•Changes affect all clients uniformly

Client-Centric (ISP)

•"The auth system needs login/logout; the profile service needs profile updates"
•Interfaces designed around what clients NEED
•Capabilities segregated by usage patterns
•Multiple focused interfaces for different clients
•Changes isolated to affected clients only

The Discovery Process:

Client-centric design requires understanding your actual clients. This isn't guesswork — it's analysis:

Identify all consumers — Who or what will use this interface? List every service, module, or component that needs this abstraction.
Map usage patterns — For each consumer, which methods do they actually call? Create a matrix of consumers vs. methods.
Find natural groupings — Look for methods that are always used together by the same clients. These form natural interface boundaries.
Name the roles — Each grouping represents a role the abstraction plays. Name it by that role, not by the entity.
Validate independence — Ensure changes to one interface don't require changes to another. If they do, the boundary might be wrong.

The Interface Discovery Matrix

interface-discovery-example.md
Markdown
## Interface Discovery Matrix: User Entity
 
| Consumer           | login | logout | getProfile | updateProfile | deleteAccount | changePassword |
|--------------------|-------|--------|------------|---------------|---------------|----------------|
| AuthService        |   ✓   |   ✓    |            |               |               |       ✓        |
| ProfileService     |       |        |     ✓      |       ✓       |               |                |
| AccountService     |       |        |            |               |       ✓       |                |
| SessionManager     |   ✓   |   ✓    |            |               |               |                |
| AdminDashboard     |       |        |     ✓      |               |       ✓       |                |
 
## Natural Interface Boundaries Revealed:
 
1. **Authenticatable** (login, logout, changePassword)
   - Used by: AuthService, SessionManager
   
2. **ProfileManageable** (getProfile, updateProfile)
   - Used by: ProfileService, AdminDashboard
 
3. **AccountDeletable** (deleteAccount)
   - Used by: AccountService, AdminDashboard
 
Note: AdminDashboard crosses boundaries because it's a composite view.
This is normal — high-level coordinators often need multiple interfaces.

Role Interfaces: The ISP Ideal

Role Interface vs. Header Interface:

role-vs-header-interfaces.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
// ❌ HEADER INTERFACE: Mirrors the class's public API
interface UserService {
    // Authentication
    login(credentials: Credentials): Promise<Session>;
    logout(session: Session): Promise<void>;
    changePassword(userId: string, newPassword: string): Promise<void>;
    resetPassword(email: string): Promise<void>;
    
    // Profile management
    getProfile(userId: string): Promise<UserProfile>;
    updateProfile(userId: string, updates: ProfileUpdates): Promise<void>;
    uploadAvatar(userId: string, image: Buffer): Promise<string>;
    
    // Account management
    createAccount(data: AccountData): Promise<User>;
    deleteAccount(userId: string): Promise<void>;
    suspendAccount(userId: string, reason: string): Promise<void>;
    
    // Preferences
    getPreferences(userId: string): Promise<Preferences>;
    updatePreferences(userId: string, prefs: Preferences): Promise<void>;
    
    // Social features
    followUser(followerId: string, followeeId: string): Promise<void>;
    unfollowUser(followerId: string, followeeId: string): Promise<void>;
    getFollowers(userId: string): Promise<User[]>;
}
 
// A mobile client that only shows profiles must depend on ALL of this!
// It can't even import just what it needs.
 
 
// ✅ ROLE INTERFACES: Designed around specific client needs
 
// The role this object plays for authentication clients
interface Authenticator {
    login(credentials: Credentials): Promise<Session>;
    logout(session: Session): Promise<void>;
    changePassword(userId: string, newPassword: string): Promise<void>;
    resetPassword(email: string): Promise<void>;
}
 
// The role this object plays for profile viewing/editing clients
interface ProfileManager {
    getProfile(userId: string): Promise<UserProfile>;
    updateProfile(userId: string, updates: ProfileUpdates): Promise<void>;
    uploadAvatar(userId: string, image: Buffer): Promise<string>;
}
 
// The role this object plays for account administration clients
interface AccountAdministrator {
    createAccount(data: AccountData): Promise<User>;
    deleteAccount(userId: string): Promise<void>;
    suspendAccount(userId: string, reason: string): Promise<void>;
}
 
// The role for preference management
interface PreferenceStore {
    getPreferences(userId: string): Promise<Preferences>;
    updatePreferences(userId: string, prefs: Preferences): Promise<void>;
}
 
// The role for social graph operations
interface SocialGraph {
    followUser(followerId: string, followeeId: string): Promise<void>;
    unfollowUser(followerId: string, followeeId: string): Promise<void>;
    getFollowers(userId: string): Promise<User[]>;
}
 
// Now each client depends only on its specific role interface
class MobileProfileViewer {
    constructor(private profiles: ProfileManager) {}  // Only what it needs!
    
    async displayProfile(userId: string): Promise<void> {
        const profile = await this.profiles.getProfile(userId);
        this.render(profile);
    }
}
 
class AdminPanel {
    constructor(
        private auth: Authenticator,      // For password resets
        private accounts: AccountAdministrator  // For account ops
    ) {}
    // Doesn't know about profiles, preferences, or social features
}

The Object Behind the Roles

Naming Role Interfaces:

Role interfaces should be named by the role they represent, not by the entity they abstract. Compare:

Header Interface Name	Role Interface Names
`User`	`Authenticatable`, `ProfileOwner`, `AccountHolder`
`File`	`Readable`, `Writable`, `Deletable`, `Seekable`
`Order`	`Purchasable`, `Shippable`, `Trackable`, `Refundable`
`Payment`	`Chargeable`, `Refundable`, `Disputable`

Benefits of Role Interfaces

•Focused Testing — Tests for a client only need to mock the role interface, not a god interface with dozens of methods
•Documentation Clarity — Role interfaces are self-documenting; their name and methods explain their purpose
•Compile-Time Enforcement — Type systems prevent clients from accidentally using methods they shouldn't
•Dependency Clarity — A class's constructor reveals exactly which roles it needs, making dependencies explicit
•Substitutability — Easy to swap implementations when interfaces are focused; fewer methods to implement

Interface Cohesion: When Methods Belong Together

Just as SRP asks about class cohesion, ISP asks about interface cohesion: Do all methods in this interface belong together?

Measuring Interface Cohesion:

Several heuristics help evaluate interface cohesion:

Cohesion Indicators

•Usage Correlation — If clients that use method A almost always use method B, they belong together. If method A and method C are never used by the same client, they may belong apart.
•Change Correlation — If modifying method A semantically requires reviewing method B, they're tightly related. If method A can change with no implications for method C, they might be independent.
•Parameter Sharing — Methods that take similar parameters often belong together (they operate on the same conceptual data).
•Return Type Relationships — If method A returns something that method B consumes, they're naturally paired.
•Single Sentence Test — Can you describe what this interface does in one sentence without using "and"? If you need "and", it might have low cohesion.

cohesion-analysis.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// ❌ LOW COHESION: "This interface handles authentication AND profile management"
interface UserAccount {
    login(email: string, password: string): Promise<Session>;
    logout(session: Session): Promise<void>;
    getProfile(): UserProfile;
    updateProfile(updates: ProfileUpdates): Promise<void>;
}
 
// Analysis:
// - login() and logout() operate on sessions; unrelated to profiles
// - getProfile() and updateProfile() operate on profile data; unrelated to auth
// - A profile viewer doesn't need login(); an auth service doesn't need getProfile()
// - Sentence: "Handles logins AND profile management" — the "AND" reveals low cohesion
 
 
// ✅ HIGH COHESION: Each interface has a single, coherent purpose
 
interface SessionManager {
    login(email: string, password: string): Promise<Session>;
    logout(session: Session): Promise<void>;
    validateSession(session: Session): Promise<boolean>;
}
 
// Analysis:
// - All methods operate on Session concept
// - Clients using login() will likely need logout() and validateSession()
// - Sentence: "Manages session lifecycle" — no "AND"
 
interface ProfileEditor {
    getProfile(): UserProfile;
    updateProfile(updates: ProfileUpdates): Promise<void>;
    getProfileHistory(): ProfileRevision[];
}
 
// Analysis:
// - All methods operate on UserProfile concept
// - Clients that read profiles often also update or audit them
// - Sentence: "Manages user profile data" — no "AND"

The Over-Segregation Trap

Cohesion Through Domain Modeling:

Often, proper cohesion emerges from understanding the domain. Domain-Driven Design concepts help:

Aggregates — A cluster of domain objects treated as a unit. Interface methods operating on the same aggregate often belong together.
Bounded Contexts — Different contexts may use the same entity differently. Each context suggests different interfaces.
Domain Events — Methods that produce or consume the same domain events are related.

When interface boundaries align with domain boundaries, cohesion tends to be high naturally. Misaligned boundaries (e.g., an interface spanning two aggregates) tend toward low cohesion.

Interface Composition Patterns

When you segregate interfaces, you need strategies for combining them. ISP doesn't mean abandoning comprehensive abstractions — it means building them from focused pieces.

Pattern 1: Interface Inheritance (Extension)

Smaller interfaces extend into larger ones when clients genuinely need the combined functionality.

interface-composition.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Building larger interfaces from smaller ones through extension
 
interface Readable {
    read(): Buffer;
    readLine(): string;
}
 
interface Writable {
    write(data: Buffer): void;
    writeLine(line: string): void;
}
 
interface Seekable {
    seek(position: number): void;
    getPosition(): number;
}
 
interface Closable {
    close(): void;
    isClosed(): boolean;
}
 
// Composition through extension: only combined when clients need both
interface ReadWriteStream extends Readable, Writable {}
 
// Full file interface for clients that need everything
interface RandomAccessFile extends Readable, Writable, Seekable, Closable {}
 
// Clients choose their level of abstraction:
class LogReader {
    constructor(private source: Readable) {}  // Only needs reading
}
 
class DataCopier {
    constructor(
        private source: Readable,
        private destination: Writable  // Separate dependencies
    ) {}
}
 
class DatabaseFile {
    constructor(private file: RandomAccessFile) {}  // Needs everything
}

Pattern 2: Intersection Types (TypeScript/Flow)

In languages with intersection types, you can combine interfaces on-demand without pre-defined composite interfaces.

intersection-types.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// On-demand composition using intersection types
 
interface Identifiable {
    getId(): string;
}
 
interface Timestamped {
    getCreatedAt(): Date;
    getUpdatedAt(): Date;
}
 
interface Auditable {
    getAuditLog(): AuditEntry[];
}
 
// Functions declare exactly what they need, no pre-defined composite
function archiveRecord(record: Identifiable & Timestamped): void {
    console.log(`Archiving ${record.getId()} from ${record.getCreatedAt()}`);
}
 
function fullAudit(entity: Identifiable & Timestamped & Auditable): AuditReport {
    return {
        entityId: entity.getId(),
        created: entity.getCreatedAt(),
        updated: entity.getUpdatedAt(),
        events: entity.getAuditLog(),
    };
}
 
// Any object meeting the intersection can be passed
class Order implements Identifiable, Timestamped, Auditable {
    getId(): string { return this.orderId; }
    getCreatedAt(): Date { return this.createdDate; }
    getUpdatedAt(): Date { return this.updatedDate; }
    getAuditLog(): AuditEntry[] { return this.auditEntries; }
}
 
const order = new Order();
archiveRecord(order);  // Works - Order satisfies Identifiable & Timestamped
fullAudit(order);      // Works - Order satisfies all three

Pattern 3: Adapter Composition

Sometimes you inherit a fat interface and need to expose a segregated view. Adapters bridge the gap.

adapter-composition.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// Given a legacy fat interface from a third-party library
interface LegacyRepository {
    findById(id: string): Entity;
    findAll(): Entity[];
    save(entity: Entity): void;
    update(entity: Entity): void;
    delete(id: string): void;
    executeQuery(sql: string): any[];
    beginTransaction(): void;
    commit(): void;
    rollback(): void;
}
 
// We want segregated interfaces for our clients
interface EntityReader {
    findById(id: string): Entity;
    findAll(): Entity[];
}
 
interface EntityWriter {
    save(entity: Entity): void;
    update(entity: Entity): void;
    delete(id: string): void;
}
 
// Adapters expose only the relevant slice
class ReadOnlyRepositoryAdapter implements EntityReader {
    constructor(private legacy: LegacyRepository) {}
    
    findById(id: string): Entity {
        return this.legacy.findById(id);
    }
    
    findAll(): Entity[] {
        return this.legacy.findAll();
    }
}
 
class WriteRepositoryAdapter implements EntityWriter {
    constructor(private legacy: LegacyRepository) {}
    
    save(entity: Entity): void {
        this.legacy.save(entity);
    }
    
    update(entity: Entity): void {
        this.legacy.update(entity);
    }
    
    delete(id: string): void {
        this.legacy.delete(id);
    }
}
 
// Clients depend on focused interfaces, not the legacy monster
class ReportGenerator {
    constructor(private dataSource: EntityReader) {}  // Read-only access
}
 
class ImportService {
    constructor(private writer: EntityWriter) {}  // Write-only access
}

Choose Your Composition Strategy

ISP Beyond Classical OOP

ISP's principle — minimize unnecessary dependencies — applies beyond interface-based OOP designs.

ISP in Functional Programming:

In FP, "interfaces" manifest as function signatures, type classes, or protocols. The ISP equivalent: functions should require only the data they need.

-- ❌ Requires the whole User even though it only needs the email
sendWelcome :: User -> IO ()
sendWelcome user = sendEmail (userEmail user) "Welcome!"

-- ✅ Requires only the email it actually uses
sendWelcome :: EmailAddress -> IO ()
sendWelcome email = sendEmail email "Welcome!"

The refined version is easier to test (no User fixture needed), more reusable (works with any email source), and documents its actual dependencies.

ISP in API Design:

REST and GraphQL APIs face ISP considerations:

❌ Fat Endpoint: GET /users/{id}
Returns: name, email, address, payment_info, order_history, preferences, social_connections, ...

Problem: Mobile app showing user name fetches (and pays bandwidth for) payment info it never displays.

✅ Segregated Endpoints:
GET /users/{id}/profile (name, email, avatar)
GET /users/{id}/address
GET /users/{id}/payment-methods
GET /users/{id}/orders

Or: GraphQL where clients request exactly the fields they need.

ISP in Module/Package Design:

At the module level, ISP suggests splitting large modules if different clients need different subsets:

❌ Single module: utils (string utils, date utils, crypto utils, http utils)
   Every importer depends on all utilities, transitively pulling in crypto and http libraries.

✅ Segregated modules:
   - string-utils (no dependencies)
   - date-utils (no dependencies)
   - crypto-utils (depends on crypto library)
   - http-utils (depends on http library)
   
   Clients import only what they need; dependency graphs stay lean.

ISP Manifestations Across Paradigms
Paradigm	ISP Equivalent	Violation Symptom
OOP Interfaces	Segregated role interfaces	Classes implement methods with 'throw NotImplemented'
Functional Types	Minimal function parameters	Functions receive large records but use few fields
REST APIs	Resource-specific endpoints	Endpoints return massive payloads with mostly unused data
GraphQL	Schema design, field resolvers	Over-connected schemas forcing unnecessary field resolution
Modules/Packages	Focused module boundaries	Importing a module pulls in heavy transitive dependencies
Microservices	Service API contracts	Service APIs bundling unrelated operations

Universal Principle, Local Syntax

Practical Guidelines for Interface Design

Let's distill the concepts into actionable guidelines for daily practice.

Design-Time Guidelines

•Start with clients, not capabilities — Before defining an interface, identify who will use it. Let client needs drive the method selection.
•Apply the 'method usage matrix' — Map clients to methods. If clear clusters appear, you have natural interface boundaries.
•Prefer many small interfaces to few large ones — But don't over-segregate. Methods that change together and are used together should stay together.
•Name by role, not entity — Interface names should reflect what the interface represents to its clients (Readable, Printable) not what type it abstracts (Document).
•Use composition for complex needs — If some clients need combinations of roles, use interface extension or intersection types rather than creating monolithic interfaces.

Review-Time Checks

•Scan for throw NotImplemented — Any method implemented by throwing an exception is a red flag for ISP violation.
•Check for empty implementations — Methods with empty bodies or stub returns often indicate forced implementation.
•Look for conditional type checks — Client code that checks concrete types before calling methods suggests the interface is too broad.
•Measure import footprint — If importing one feature pulls in many unrelated dependencies, modules may be too coarse.
•Ask: Can I describe this interface without 'and'? — If not, consider whether it combines multiple roles.

The Evolution Approach

Summary: ISP-Driven Interface Design

We've explored how ISP fundamentally shapes the philosophy and practice of interface design.

Key Takeaways

•Client-centric design — Start by understanding who uses the interface and what they need, not what the abstraction could do.
•Role interfaces over header interfaces — Define interfaces by the role an object plays for a client, not by mirroring the object's public API.
•Cohesion matters — Methods in an interface should be used together and change together. Apply the single-sentence test.
•Composition strategies — Use extension, intersection types, or adapters to build larger interfaces from smaller pieces.
•ISP is universal — The principle applies to functional programming, API design, and module boundaries — anywhere dependencies exist.
•Evolution is okay — Perfect segregation isn't required upfront. Refactor as you discover how clients actually use your code.

What's Next:

Page Complete

2 / 4