System Design (HLD)ISP in Practice

ISP in Practice

LevelIntermediate

Duration60 mins

TopicISP in Practice

1 / 4

Real-World ISP Examples

ISP in the Wild: Theory Meets Production

The Interface Segregation Principle isn't an academic abstraction—it's a battle-tested design principle that shapes the APIs of every major framework, library, and platform you've ever used. From Java's Collection Framework to Node.js event emitters, from Spring's dependency injection to React's component lifecycle, ISP decisions made by framework authors ripple through millions of lines of application code.

This page takes you inside the design decisions of production systems, examining both exemplary ISP implementations and instructive violations. You'll see how the principle manifests in frameworks you use daily, why certain APIs feel intuitive while others feel burdensome, and how to recognize ISP patterns (and anti-patterns) in the wild.

What You Will Learn

By the end of this page, you will be able to identify ISP compliance in real-world APIs, understand why major frameworks chose specific interface designs, and apply these insights to your own system architecture. You'll develop an intuition for recognizing well-segregated interfaces versus problematic 'fat' interfaces in any codebase you encounter.

ISP in Java's Collection Framework

Java's Collection Framework stands as one of the most influential examples of ISP in action. Designed by Joshua Bloch (also known for Effective Java), the framework's interface hierarchy demonstrates how thoughtful segregation enables flexibility without forcing unnecessary implementations.

The Core Interface Hierarchy:

The Collection Framework doesn't present a single monolithic Collection interface with every possible operation. Instead, it segregates capabilities into focused interfaces that clients can depend on based on their actual needs:

Java Collection Interface Hierarchy
Java
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
// The base interface - extremely minimal
public interface Iterable<T> {
    Iterator<T> iterator();  // Just iteration capability
}
 
// Extends Iterable with basic collection operations
public interface Collection<T> extends Iterable<T> {
    int size();
    boolean isEmpty();
    boolean contains(Object o);
    boolean add(T e);
    boolean remove(Object o);
    // ... focused on core collection semantics
}
 
// Adds ordered access semantics
public interface List<T> extends Collection<T> {
    T get(int index);
    T set(int index, T element);
    void add(int index, T element);
    T remove(int index);
    int indexOf(Object o);
    // ... focused on positional access
}
 
// Adds sorted/navigable semantics
public interface SortedSet<T> extends Set<T> {
    Comparator<? super T> comparator();
    T first();
    T last();
    SortedSet<T> headSet(T toElement);
    SortedSet<T> tailSet(T fromElement);
    // ... focused on ordering operations
}
 
// Queue semantics for FIFO behavior
public interface Queue<T> extends Collection<T> {
    boolean offer(T e);     // Add without exception
    T poll();               // Remove without exception
    T peek();               // Examine without removal
    // ... focused on FIFO operations
}

Why This Hierarchy Exemplifies ISP:

Clients depend only on what they use: A method that only needs to iterate over elements depends on Iterable<T>, not List<T> or Collection<T>.
Implementations aren't forced into impossible contracts: An immutable collection can implement Collection<T> with add() throwing UnsupportedOperationException, but a method expecting Iterable<T> won't even know about mutability.
Extension without modification: New collection types (like Deque added in Java 6) integrate cleanly without breaking existing code expecting only Queue.

The Iterable Sweet Spot

Notice how Iterable<T> has exactly one method: iterator(). This is ISP taken to its logical extreme for the most common use case—iterating over elements. Enhanced for-loops (for-each) only require Iterable, not Collection or List. This means any class implementing just iteration capability can be used in for-each loops without implementing 15+ other Collection methods.

Client Dependencies by Use Case
Client Need	Minimum Interface	Why Not More?
Iterate through elements	`Iterable<T>`	No need to know about size, addition, or removal
Check membership	`Collection<T>`	No need for positional access or ordering
Access by index	`List<T>`	No need for sorting capabilities
Ensure uniqueness	`Set<T>`	No need for ordered traversal or indexing
FIFO processing	`Queue<T>`	No need for random access or set semantics

ISP in Node.js and TypeScript Ecosystems

The JavaScript/TypeScript ecosystem presents a fascinating case study in ISP evolution. Early Node.js design sometimes violated ISP, but modern TypeScript patterns and frameworks demonstrate increasing sophistication in interface design.

Node.js Streams: Mixed ISP Compliance

Node.js streams represent a partial success story. The readable and writable stream interfaces are appropriately separated, but the duplex stream requirement sometimes forces unnecessary implementations:

Node.js Stream Interface Segregation
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
// Good ISP: Separate interfaces for separate capabilities
interface Readable {
    read(size?: number): Buffer | string | null;
    pipe<T extends Writable>(destination: T): T;
    on(event: 'data', listener: (chunk: Buffer) => void): this;
    on(event: 'end', listener: () => void): this;
}
 
interface Writable {
    write(chunk: Buffer | string): boolean;
    end(chunk?: Buffer | string): void;
    on(event: 'drain', listener: () => void): this;
    on(event: 'finish', listener: () => void): this;
}
 
// Clients depend on what they need
function processInput(source: Readable): void {
    // Only reads - doesn't care about write capability
    source.on('data', chunk => console.log(chunk));
}
 
function sendOutput(destination: Writable): void {
    // Only writes - doesn't care about read capability
    destination.write('Hello, World!');
    destination.end();
}

Express.js Middleware: ISP in Action

Express.js middleware demonstrates excellent ISP compliance through its minimalist interface. Each middleware function receives exactly what it needs—request, response, and next—without being forced to implement a complex interface:

Express Middleware - Minimal Interfaces
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
import { Request, Response, NextFunction } from 'express';
 
// Minimal interface - just what middleware needs
type Middleware = (req: Request, res: Response, next: NextFunction) => void;
 
// Error middleware extends with one additional parameter
type ErrorMiddleware = (
    err: Error, 
    req: Request, 
    res: Response, 
    next: NextFunction
) => void;
 
// Authentication middleware only uses what it needs from Request
const authMiddleware: Middleware = (req, res, next) => {
    const token = req.headers.authorization;  // Uses header
    if (!token) {
        return res.status(401).json({ error: 'Unauthorized' });
    }
    next();
};
 
// Logging middleware uses different subset
const loggingMiddleware: Middleware = (req, res, next) => {
    console.log(`${req.method} ${req.path}`);  // Uses method, path
    next();
};
 
// Rate limiting uses yet another subset
const rateLimitMiddleware: Middleware = (req, res, next) => {
    const clientIP = req.ip;  // Uses IP
    // Check rate limit...
    next();
};
 
// Each middleware depends only on the parts of Request
// and Response that it actually uses

TypeScript's Structural Typing Advantage

TypeScript's structural type system naturally supports ISP. Unlike Java where a class must explicitly declare interface implementation, TypeScript checks shape compatibility. A function requiring { name: string } accepts any object with a name property, regardless of other properties. This enables ISP without explicit interface declarations—but explicit interfaces still document intent and enable tooling support.

ISP in React and Frontend Frameworks

Modern frontend frameworks provide rich case studies in ISP application for component design. React's evolution, in particular, demonstrates how ISP thinking shaped the transition from class components to hooks.

Class Components: ISP Challenges

React class components historically presented ISP tensions. Implementing lifecycle methods meant depending on a large interface even when components only needed a subset:

Class Component ISP Issues

•Must extend React.Component<Props, State>
•Inherits lifecycle methods you may not use
•State management coupled with rendering
•this binding creates method dependencies
•Higher-order components (HOCs) compose poorly

Hooks-Based ISP Benefits

•Use only the hooks you need
•useState without lifecycle complexity
•useEffect only when side effects needed
•Custom hooks compose cleanly
•No inheritance hierarchy required

React Hooks - ISP in Practice
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
// Hooks enable ISP: use ONLY what you need
 
// Component needing just state
function Counter() {
    const [count, setCount] = useState(0);  // Only state
    return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}
 
// Component needing side effects
function DataFetcher({ url }: { url: string }) {
    const [data, setData] = useState(null);
    
    useEffect(() => {
        fetch(url).then(r => r.json()).then(setData);
    }, [url]);  // Only effect + state
    
    return <pre>{JSON.stringify(data)}</pre>;
}
 
// Custom hooks compose without inheritance
function useDebounce<T>(value: T, delay: number): T {
    const [debouncedValue, setDebouncedValue] = useState(value);
    
    useEffect(() => {
        const timer = setTimeout(() => setDebouncedValue(value), delay);
        return () => clearTimeout(timer);
    }, [value, delay]);
    
    return debouncedValue;
}
 
// Compose multiple capabilities
function SearchInput() {
    const [query, setQuery] = useState('');           // State capability
    const debouncedQuery = useDebounce(query, 300);   // Debounce capability
    const { data, loading } = useFetch(              // Fetch capability
        `/search?q=${debouncedQuery}`
    );
    
    // Each capability via separate, focused "interface" (hook)
    return (
        <div>
            <input value={query} onChange={e => setQuery(e.target.value)} />
            {loading ? <Spinner /> : <Results data={data} />}
        </div>
    );
}

Props Interfaces: ISP in Component Contracts

React component props demonstrate ISP at the component level. Well-designed components accept minimal props, enabling maximum reuse:

Component Props - ISP Design
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
// Anti-pattern: Fat props interface
interface BadButtonProps {
    label: string;
    onClick: () => void;
    icon?: ReactNode;
    size?: 'sm' | 'md' | 'lg';
    variant?: 'primary' | 'secondary';
    disabled?: boolean;
    loading?: boolean;
    tooltip?: string;
    analyticsId?: string;
    accessibilityLabel?: string;
    testId?: string;
    // ... 20 more optional props
}
 
// ISP approach: Compose focused interfaces
interface ClickableProps {
    onClick: () => void;
    disabled?: boolean;
}
 
interface LabeledProps {
    label: string;
    icon?: ReactNode;
}
 
interface SizeableProps {
    size?: 'sm' | 'md' | 'lg';
}
 
interface VariantProps {
    variant?: 'primary' | 'secondary';
}
 
// Button uses intersection of relevant interfaces
type ButtonProps = ClickableProps & LabeledProps & SizeableProps & VariantProps;
 
// A link component might only need:
type LinkProps = LabeledProps & { href: string };
 
// An icon button might need:
type IconButtonProps = ClickableProps & SizeableProps & { icon: ReactNode };
 
// Each component declares exactly what it needs
// Consumers know exactly what they're providing

ISP in Spring Framework and DI Containers

The Spring Framework provides enterprise-grade examples of ISP in dependency injection, aspect-oriented programming, and repository patterns. Spring's interface design philosophy has influenced countless enterprise applications.

Repository Pattern: Role-Based Interfaces

Spring Data demonstrates masterful ISP through its repository interface hierarchy. Instead of a single massive repository interface, capabilities are segregated by role:

Spring Data Repository Interfaces
Java
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
// Minimal: Just marks a repository
public interface Repository<T, ID> {}
 
// Read-only operations
public interface CrudRepository<T, ID> extends Repository<T, ID> {
    Optional<T> findById(ID id);
    Iterable<T> findAll();
    boolean existsById(ID id);
    long count();
    // Write operations also here - could be more segregated
}
 
// Pagination capability
public interface PagingAndSortingRepository<T, ID> 
        extends CrudRepository<T, ID> {
    Iterable<T> findAll(Sort sort);
    Page<T> findAll(Pageable pageable);
}
 
// JPA-specific operations
public interface JpaRepository<T, ID> 
        extends PagingAndSortingRepository<T, ID> {
    void flush();
    T saveAndFlush(T entity);
    void deleteInBatch(Iterable<T> entities);
    T getOne(ID id);  // Lazy loading
}
 
// Application-level: Interface per client role
public interface UserReadRepository extends Repository<User, Long> {
    Optional<User> findById(Long id);
    Optional<User> findByEmail(String email);
    List<User> findByStatus(UserStatus status);
    // Read-only operations for query services
}
 
public interface UserWriteRepository extends Repository<User, Long> {
    User save(User user);
    void delete(User user);
    void deleteById(Long id);
    // Write operations for command services
}
 
// Services depend on the interface matching their role
@Service
public class UserQueryService {
    private final UserReadRepository userReadRepository;
    // No temptation to modify data - interface prevents it
}
 
@Service
public class UserCommandService {
    private final UserWriteRepository userWriteRepository;
    // Focused on state changes
}

CQRS and ISP

Spring's repository segregation aligns with Command Query Responsibility Segregation (CQRS). By separating read and write interfaces, you enable different optimization strategies for each path: read replicas for queries, write-through caches for commands, different serialization approaches, and independent scaling. ISP at the repository level enables CQRS at the architecture level.

Spring Event System: Publisher-Subscriber Segregation

Spring's event system demonstrates ISP through separate interfaces for event publishers and event listeners:

Spring Events - ISP Separation
Java
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
// Publisher interface - just publishing capability
public interface ApplicationEventPublisher {
    void publishEvent(Object event);
}
 
// Listener interface - just handling capability
public interface ApplicationListener<E extends ApplicationEvent> {
    void onApplicationEvent(E event);
}
 
// Services use only what they need
 
@Service
public class OrderService {
    private final ApplicationEventPublisher eventPublisher;
    // Can only publish - no listener complexity
    
    public Order createOrder(OrderRequest request) {
        Order order = // create order logic
        eventPublisher.publishEvent(new OrderCreatedEvent(order));
        return order;
    }
}
 
@Component
public class InventoryEventHandler 
        implements ApplicationListener<OrderCreatedEvent> {
    // Can only listen - no publisher complexity
    
    @Override
    public void onApplicationEvent(OrderCreatedEvent event) {
        // Reduce inventory
    }
}
 
@Component
public class NotificationEventHandler 
        implements ApplicationListener<OrderCreatedEvent> {
    // Independent handler - same event, different concern
    
    @Override
    public void onApplicationEvent(OrderCreatedEvent event) {
        // Send notification
    }
}

ISP in Database Access Layers

Database access layers frequently violate ISP, leading to tight coupling between business logic and infrastructure. Well-designed data access patterns demonstrate how interface segregation enables testability, flexibility, and clean architecture.

The Problem: Monolithic Repository Interfaces

Many codebases suffer from "god repository" anti-patterns that force all database operations through a single interface:

God Repository Anti-Pattern
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
// Anti-pattern: Fat repository interface
interface UserRepository {
    // Basic CRUD
    findById(id: string): Promise<User | null>;
    findAll(): Promise<User[]>;
    save(user: User): Promise<User>;
    delete(id: string): Promise<void>;
    
    // Search operations
    findByEmail(email: string): Promise<User | null>;
    findByUsername(username: string): Promise<User | null>;
    searchByName(query: string): Promise<User[]>;
    
    // Complex queries
    findActiveUsersWithRecentOrders(days: number): Promise<User[]>;
    findUsersWithExpiredSubscriptions(): Promise<User[]>;
    findTopUsersBySpending(limit: number): Promise<User[]>;
    
    // Reporting
    getUserStatistics(): Promise<UserStats>;
    getUserGrowthByMonth(): Promise<GrowthData[]>;
    
    // Bulk operations
    batchInsert(users: User[]): Promise<void>;
    batchUpdate(users: Partial<User>[]): Promise<void>;
    softDeleteInactive(daysSinceLogin: number): Promise<number>;
    
    // Caching concerns mixed in
    invalidateCache(userId: string): Promise<void>;
    warmCache(): Promise<void>;
}
 
// Problems:
// 1. Any class depending on UserRepository depends on ALL methods
// 2. Mock implementations must stub 20+ methods
// 3. Changes to reporting methods affect authentication components
// 4. Caching, querying, and CRUD all coupled together

The Solution: Role-Based Repository Interfaces

By applying ISP, we segregate the repository by client role and capability:

ISP-Compliant Repository Design
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
// Read-only interface for query services
interface UserReader {
    findById(id: string): Promise<User | null>;
    findByEmail(email: string): Promise<User | null>;
    findByUsername(username: string): Promise<User | null>;
}
 
// Write operations for command services
interface UserWriter {
    save(user: User): Promise<User>;
    delete(id: string): Promise<void>;
}
 
// Search capability for search components
interface UserSearcher {
    searchByName(query: string): Promise<User[]>;
    findAll(filters: UserFilters): Promise<User[]>;
}
 
// Analytics interface for reporting module
interface UserAnalytics {
    getUserStatistics(): Promise<UserStats>;
    getUserGrowthByMonth(): Promise<GrowthData[]>;
    findTopUsersBySpending(limit: number): Promise<User[]>;
}
 
// Bulk operations for admin/batch processes
interface UserBulkOperations {
    batchInsert(users: User[]): Promise<void>;
    batchUpdate(users: Partial<User>[]): Promise<void>;
    softDeleteInactive(daysSinceLogin: number): Promise<number>;
}
 
// Implementation can implement all interfaces
class UserRepositoryImpl implements 
    UserReader, UserWriter, UserSearcher, 
    UserAnalytics, UserBulkOperations {
    // Full implementation
}
 
// Clients depend only on what they need
class AuthenticationService {
    constructor(private userReader: UserReader) {}
    // Can only read - can't accidentally modify users
}
 
class UserProfileService {
    constructor(
        private userReader: UserReader,
        private userWriter: UserWriter
    ) {}
    // Read and write, but no bulk operations
}
 
class MonthlyReportGenerator {
    constructor(private analytics: UserAnalytics) {}
    // Only analytics - no access to modify data
}
 
// Testing becomes trivial
class TestUserReader implements UserReader {
    findById(id: string) { return Promise.resolve(mockUser); }
    findByEmail(email: string) { return Promise.resolve(mockUser); }
    findByUsername(username: string) { return Promise.resolve(mockUser); }
    // Only 3 methods to mock!
}

The Testing Multiplier Effect

ISP in data access layers dramatically reduces testing burden. A test for AuthenticationService only needs a mock UserReader with 3 methods, not a full repository with 20+ methods. This isn't just convenience—it's accuracy. Tests that mock unused methods create false confidence because the mocks might behave differently from real implementations for methods not under test.

ISP in Microservices and API Design

ISP principles extend beyond class interfaces to API contracts between services. In microservices architectures, fat APIs create the same coupling problems that fat interfaces create in object-oriented code—but with network calls amplifying the costs.

Backend-for-Frontend (BFF) Pattern: ISP at Scale

The Backend-for-Frontend pattern is ISP applied to API design. Instead of a single API serving all clients (web, mobile, IoT), specialized APIs serve each client's specific needs:

BFF Pattern - Client-Specific APIs
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
// Anti-pattern: Single fat API for all clients
interface ProductAPI {
    // Full product with all relations
    getProductById(id: string): Promise<{
        id: string;
        name: string;
        description: string;
        price: number;
        inventory: number;
        supplier: Supplier;
        reviews: Review[];
        similarProducts: Product[];
        purchaseHistory: Purchase[]; // For analytics
        warehouseLocations: Location[]; // For logistics
        // ... 30 more fields
    }>;
}
 
// Problem: Mobile app downloads 10KB of data to show a 100-byte card
// Problem: Web app makes extra calls for fields not in the response
// Problem: IoT device needs just inventory but gets everything
 
// ISP Solution: Backend-for-Frontend pattern
// Mobile BFF - optimized for bandwidth and battery
interface MobileProductAPI {
    getProductCard(id: string): Promise<{
        id: string;
        name: string;
        thumbnailUrl: string;
        price: number;
    }>; // ~100 bytes
    
    getProductDetails(id: string): Promise<{
        id: string;
        name: string;
        description: string;
        images: string[];
        price: number;
        reviewSummary: { average: number; count: number };
    }>; // Loaded on user tap
}
 
// Web BFF - optimized for rich desktop experience
interface WebProductAPI {
    getProductPage(id: string): Promise<{
        product: ProductDetails;
        reviews: Review[];
        similarProducts: ProductCard[];
        breadcrumbs: Category[];
        seoMeta: SEOMeta;
    }>; // Single request for full page
}
 
// IoT BFF - minimal data for device constraints
interface IoTInventoryAPI {
    checkStock(skus: string[]): Promise<Map<string, number>>;
    subscribeToStockChanges(skus: string[]): Observable<StockChange>;
}

GraphQL: Query-Level ISP

GraphQL represents another approach to ISP in APIs—instead of segregating interfaces, it lets clients declare exactly what they need per request:

GraphQL - Dynamic Interface Segregation
GraphQL
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
# Full schema available
type Product {
    id: ID!
    name: String!
    description: String!
    price: Float!
    inventory: Int!
    supplier: Supplier!
    reviews: [Review!]!
    similarProducts: [Product!]!
    categories: [Category!]!
}
 
# Mobile client request - minimal fields
query MobileProductCard($id: ID!) {
    product(id: $id) {
        id
        name
        price
    }
}
 
# Web client request - more detail
query WebProductPage($id: ID!) {
    product(id: $id) {
        id
        name
        description
        price
        reviews {
            rating
            text
            author { name }
        }
        similarProducts {
            id
            name
            price
        }
    }
}
 
# Analytics service - different shape entirely
query ProductAnalytics($id: ID!) {
    product(id: $id) {
        id
        inventory
        reviews {
            rating
            createdAt
        }
        supplier {
            leadTime
            reliabilityScore
        }
    }
}

GraphQL Trade-offs

While GraphQL enables per-query ISP, it shifts complexity to the server. The server must support all possible field combinations, potentially leading to N+1 query problems and complex authorization logic. GraphQL is ISP for data shape, but the underlying resolvers still need well-designed, segregated interfaces. Don't let GraphQL flexibility mask poor backend interface design.

ISP Lessons from Framework Authors

The architects of major frameworks have articulated principles that directly connect to ISP. Understanding their reasoning helps internalize when and how to apply interface segregation.

Principle 1: "Design interfaces for clients, not implementations"

Joshua Bloch (Effective Java) emphasizes that interface design should start from consumer needs, not implementer convenience:

Client-First Interface Design

•Identify all clients: Who will depend on this interface? What do they need?
•Group by role: Do different clients need different method subsets?
•Separate by rate of change: Methods that change together should be together; methods that change independently should be in separate interfaces
•Design for the 80% case: The most common use case should require the smallest interface

Principle 2: "Prefer narrow interfaces to wide ones"

Martin Fowler advocates for the "Minimal Interface" principle—each interface should contain the absolute minimum needed for its purpose. Additional capabilities belong in separate interfaces that can be composed:

Interface Width Trade-offs
Narrow Interfaces	Wide Interfaces
Easy to implement	Burdensome to implement
Easy to mock/test	Requires extensive mocking
Changes affect fewer consumers	Changes ripple widely
Compose for complex needs	Already include complex needs
More types to manage	Fewer types, but each is larger

Principle 3: "Make interfaces hard to misuse"

Scott Meyers (Effective C++) argues that interfaces should guide users toward correct usage. Fat interfaces violate this principle by presenting options that don't apply to all use cases, inviting incorrect method calls:

Interface Design for Correct Usage
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
// Wide interface - easy to misuse
interface FileHandler {
    read(): Promise<string>;
    write(content: string): Promise<void>;
    append(content: string): Promise<void>;
    delete(): Promise<void>;
}
 
// User might call write() on a read-only file handle
// User might call delete() when they meant to close
// Interface doesn't guide correct usage
 
// Narrow interfaces - harder to misuse
interface FileReader {
    read(): Promise<string>;
    close(): void;
}
 
interface FileWriter {
    write(content: string): Promise<void>;
    append(content: string): Promise<void>;
    close(): void;
}
 
interface FileRemover {
    delete(): Promise<void>;
}
 
// Read-only handle can't accidentally write or delete
function processLogFile(reader: FileReader): void {
    // Can only read - can't accidentally modify
    const content = await reader.read();
    // ...
}
 
// Write handle can't accidentally delete
function updateConfig(writer: FileWriter): void {
    // Can write/append - can't delete the file
    await writer.write(newConfig);
}

Summary: ISP in Production Systems

We've explored how the Interface Segregation Principle manifests across production systems—from language standard libraries to enterprise frameworks to microservices architectures. Let's consolidate the patterns we've observed:

Key Takeaways

•Java Collections demonstrate hierarchical ISP — Capabilities like iteration, ordering, and indexing are segregated into distinct interfaces that compose through inheritance
•Modern JavaScript frameworks embrace functional ISP — Hooks, middleware, and structural typing enable composition without interface bloat
•Spring shows ISP in enterprise contexts — Repository interfaces, event systems, and DI demonstrate role-based segregation at scale
•Database access benefits dramatically from ISP — Read/write/search/analytics separation enables testing, CQRS, and clean architecture
•API design extends ISP to network boundaries — BFF pattern and GraphQL apply segregation principles to service contracts
•Framework authors unanimously advocate narrow interfaces — Client-focused, minimal, hard-to-misuse designs are the gold standard

What's Next:

Having seen ISP excellence in action, we turn to the opposite: common mistakes that violate ISP. The next page examines ISP anti-patterns, helping you recognize and avoid the pitfalls that lead to coupled, fragile, hard-to-maintain interfaces.

Page Complete

You've explored real-world ISP implementations across major frameworks and architectures. You can now identify ISP compliance in APIs you use daily and understand the design decisions behind them. Next, we'll examine common ISP mistakes and how to avoid them.

1 / 4

Loading learning content...

System Design (HLD)ISP in Practice

ISP in Practice

LevelIntermediate

Duration60 mins

TopicISP in Practice

1 / 4

Real-World ISP Examples

ISP in the Wild: Theory Meets Production

What You Will Learn

ISP in Java's Collection Framework

The Core Interface Hierarchy:

Java Collection Interface Hierarchy
Java
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
// The base interface - extremely minimal
public interface Iterable<T> {
    Iterator<T> iterator();  // Just iteration capability
}
 
// Extends Iterable with basic collection operations
public interface Collection<T> extends Iterable<T> {
    int size();
    boolean isEmpty();
    boolean contains(Object o);
    boolean add(T e);
    boolean remove(Object o);
    // ... focused on core collection semantics
}
 
// Adds ordered access semantics
public interface List<T> extends Collection<T> {
    T get(int index);
    T set(int index, T element);
    void add(int index, T element);
    T remove(int index);
    int indexOf(Object o);
    // ... focused on positional access
}
 
// Adds sorted/navigable semantics
public interface SortedSet<T> extends Set<T> {
    Comparator<? super T> comparator();
    T first();
    T last();
    SortedSet<T> headSet(T toElement);
    SortedSet<T> tailSet(T fromElement);
    // ... focused on ordering operations
}
 
// Queue semantics for FIFO behavior
public interface Queue<T> extends Collection<T> {
    boolean offer(T e);     // Add without exception
    T poll();               // Remove without exception
    T peek();               // Examine without removal
    // ... focused on FIFO operations
}

Why This Hierarchy Exemplifies ISP:

Clients depend only on what they use: A method that only needs to iterate over elements depends on Iterable<T>, not List<T> or Collection<T>.
Implementations aren't forced into impossible contracts: An immutable collection can implement Collection<T> with add() throwing UnsupportedOperationException, but a method expecting Iterable<T> won't even know about mutability.
Extension without modification: New collection types (like Deque added in Java 6) integrate cleanly without breaking existing code expecting only Queue.

The Iterable Sweet Spot

Client Dependencies by Use Case
Client Need	Minimum Interface	Why Not More?
Iterate through elements	`Iterable<T>`	No need to know about size, addition, or removal
Check membership	`Collection<T>`	No need for positional access or ordering
Access by index	`List<T>`	No need for sorting capabilities
Ensure uniqueness	`Set<T>`	No need for ordered traversal or indexing
FIFO processing	`Queue<T>`	No need for random access or set semantics

ISP in Node.js and TypeScript Ecosystems

Node.js Streams: Mixed ISP Compliance

Node.js Stream Interface Segregation
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
// Good ISP: Separate interfaces for separate capabilities
interface Readable {
    read(size?: number): Buffer | string | null;
    pipe<T extends Writable>(destination: T): T;
    on(event: 'data', listener: (chunk: Buffer) => void): this;
    on(event: 'end', listener: () => void): this;
}
 
interface Writable {
    write(chunk: Buffer | string): boolean;
    end(chunk?: Buffer | string): void;
    on(event: 'drain', listener: () => void): this;
    on(event: 'finish', listener: () => void): this;
}
 
// Clients depend on what they need
function processInput(source: Readable): void {
    // Only reads - doesn't care about write capability
    source.on('data', chunk => console.log(chunk));
}
 
function sendOutput(destination: Writable): void {
    // Only writes - doesn't care about read capability
    destination.write('Hello, World!');
    destination.end();
}

Express.js Middleware: ISP in Action

Express Middleware - Minimal Interfaces
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
import { Request, Response, NextFunction } from 'express';
 
// Minimal interface - just what middleware needs
type Middleware = (req: Request, res: Response, next: NextFunction) => void;
 
// Error middleware extends with one additional parameter
type ErrorMiddleware = (
    err: Error, 
    req: Request, 
    res: Response, 
    next: NextFunction
) => void;
 
// Authentication middleware only uses what it needs from Request
const authMiddleware: Middleware = (req, res, next) => {
    const token = req.headers.authorization;  // Uses header
    if (!token) {
        return res.status(401).json({ error: 'Unauthorized' });
    }
    next();
};
 
// Logging middleware uses different subset
const loggingMiddleware: Middleware = (req, res, next) => {
    console.log(`${req.method} ${req.path}`);  // Uses method, path
    next();
};
 
// Rate limiting uses yet another subset
const rateLimitMiddleware: Middleware = (req, res, next) => {
    const clientIP = req.ip;  // Uses IP
    // Check rate limit...
    next();
};
 
// Each middleware depends only on the parts of Request
// and Response that it actually uses

TypeScript's Structural Typing Advantage

ISP in React and Frontend Frameworks

Class Components: ISP Challenges

React class components historically presented ISP tensions. Implementing lifecycle methods meant depending on a large interface even when components only needed a subset:

Class Component ISP Issues

•Must extend React.Component<Props, State>
•Inherits lifecycle methods you may not use
•State management coupled with rendering
•this binding creates method dependencies
•Higher-order components (HOCs) compose poorly

Hooks-Based ISP Benefits

•Use only the hooks you need
•useState without lifecycle complexity
•useEffect only when side effects needed
•Custom hooks compose cleanly
•No inheritance hierarchy required

React Hooks - ISP in Practice
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
// Hooks enable ISP: use ONLY what you need
 
// Component needing just state
function Counter() {
    const [count, setCount] = useState(0);  // Only state
    return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}
 
// Component needing side effects
function DataFetcher({ url }: { url: string }) {
    const [data, setData] = useState(null);
    
    useEffect(() => {
        fetch(url).then(r => r.json()).then(setData);
    }, [url]);  // Only effect + state
    
    return <pre>{JSON.stringify(data)}</pre>;
}
 
// Custom hooks compose without inheritance
function useDebounce<T>(value: T, delay: number): T {
    const [debouncedValue, setDebouncedValue] = useState(value);
    
    useEffect(() => {
        const timer = setTimeout(() => setDebouncedValue(value), delay);
        return () => clearTimeout(timer);
    }, [value, delay]);
    
    return debouncedValue;
}
 
// Compose multiple capabilities
function SearchInput() {
    const [query, setQuery] = useState('');           // State capability
    const debouncedQuery = useDebounce(query, 300);   // Debounce capability
    const { data, loading } = useFetch(              // Fetch capability
        `/search?q=${debouncedQuery}`
    );
    
    // Each capability via separate, focused "interface" (hook)
    return (
        <div>
            <input value={query} onChange={e => setQuery(e.target.value)} />
            {loading ? <Spinner /> : <Results data={data} />}
        </div>
    );
}

Props Interfaces: ISP in Component Contracts

React component props demonstrate ISP at the component level. Well-designed components accept minimal props, enabling maximum reuse:

Component Props - ISP Design
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
// Anti-pattern: Fat props interface
interface BadButtonProps {
    label: string;
    onClick: () => void;
    icon?: ReactNode;
    size?: 'sm' | 'md' | 'lg';
    variant?: 'primary' | 'secondary';
    disabled?: boolean;
    loading?: boolean;
    tooltip?: string;
    analyticsId?: string;
    accessibilityLabel?: string;
    testId?: string;
    // ... 20 more optional props
}
 
// ISP approach: Compose focused interfaces
interface ClickableProps {
    onClick: () => void;
    disabled?: boolean;
}
 
interface LabeledProps {
    label: string;
    icon?: ReactNode;
}
 
interface SizeableProps {
    size?: 'sm' | 'md' | 'lg';
}
 
interface VariantProps {
    variant?: 'primary' | 'secondary';
}
 
// Button uses intersection of relevant interfaces
type ButtonProps = ClickableProps & LabeledProps & SizeableProps & VariantProps;
 
// A link component might only need:
type LinkProps = LabeledProps & { href: string };
 
// An icon button might need:
type IconButtonProps = ClickableProps & SizeableProps & { icon: ReactNode };
 
// Each component declares exactly what it needs
// Consumers know exactly what they're providing

ISP in Spring Framework and DI Containers

Repository Pattern: Role-Based Interfaces

Spring Data demonstrates masterful ISP through its repository interface hierarchy. Instead of a single massive repository interface, capabilities are segregated by role:

Spring Data Repository Interfaces
Java
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
// Minimal: Just marks a repository
public interface Repository<T, ID> {}
 
// Read-only operations
public interface CrudRepository<T, ID> extends Repository<T, ID> {
    Optional<T> findById(ID id);
    Iterable<T> findAll();
    boolean existsById(ID id);
    long count();
    // Write operations also here - could be more segregated
}
 
// Pagination capability
public interface PagingAndSortingRepository<T, ID> 
        extends CrudRepository<T, ID> {
    Iterable<T> findAll(Sort sort);
    Page<T> findAll(Pageable pageable);
}
 
// JPA-specific operations
public interface JpaRepository<T, ID> 
        extends PagingAndSortingRepository<T, ID> {
    void flush();
    T saveAndFlush(T entity);
    void deleteInBatch(Iterable<T> entities);
    T getOne(ID id);  // Lazy loading
}
 
// Application-level: Interface per client role
public interface UserReadRepository extends Repository<User, Long> {
    Optional<User> findById(Long id);
    Optional<User> findByEmail(String email);
    List<User> findByStatus(UserStatus status);
    // Read-only operations for query services
}
 
public interface UserWriteRepository extends Repository<User, Long> {
    User save(User user);
    void delete(User user);
    void deleteById(Long id);
    // Write operations for command services
}
 
// Services depend on the interface matching their role
@Service
public class UserQueryService {
    private final UserReadRepository userReadRepository;
    // No temptation to modify data - interface prevents it
}
 
@Service
public class UserCommandService {
    private final UserWriteRepository userWriteRepository;
    // Focused on state changes
}

CQRS and ISP

Spring Event System: Publisher-Subscriber Segregation

Spring's event system demonstrates ISP through separate interfaces for event publishers and event listeners:

Spring Events - ISP Separation
Java
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
// Publisher interface - just publishing capability
public interface ApplicationEventPublisher {
    void publishEvent(Object event);
}
 
// Listener interface - just handling capability
public interface ApplicationListener<E extends ApplicationEvent> {
    void onApplicationEvent(E event);
}
 
// Services use only what they need
 
@Service
public class OrderService {
    private final ApplicationEventPublisher eventPublisher;
    // Can only publish - no listener complexity
    
    public Order createOrder(OrderRequest request) {
        Order order = // create order logic
        eventPublisher.publishEvent(new OrderCreatedEvent(order));
        return order;
    }
}
 
@Component
public class InventoryEventHandler 
        implements ApplicationListener<OrderCreatedEvent> {
    // Can only listen - no publisher complexity
    
    @Override
    public void onApplicationEvent(OrderCreatedEvent event) {
        // Reduce inventory
    }
}
 
@Component
public class NotificationEventHandler 
        implements ApplicationListener<OrderCreatedEvent> {
    // Independent handler - same event, different concern
    
    @Override
    public void onApplicationEvent(OrderCreatedEvent event) {
        // Send notification
    }
}

ISP in Database Access Layers

The Problem: Monolithic Repository Interfaces

Many codebases suffer from "god repository" anti-patterns that force all database operations through a single interface:

God Repository Anti-Pattern
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
// Anti-pattern: Fat repository interface
interface UserRepository {
    // Basic CRUD
    findById(id: string): Promise<User | null>;
    findAll(): Promise<User[]>;
    save(user: User): Promise<User>;
    delete(id: string): Promise<void>;
    
    // Search operations
    findByEmail(email: string): Promise<User | null>;
    findByUsername(username: string): Promise<User | null>;
    searchByName(query: string): Promise<User[]>;
    
    // Complex queries
    findActiveUsersWithRecentOrders(days: number): Promise<User[]>;
    findUsersWithExpiredSubscriptions(): Promise<User[]>;
    findTopUsersBySpending(limit: number): Promise<User[]>;
    
    // Reporting
    getUserStatistics(): Promise<UserStats>;
    getUserGrowthByMonth(): Promise<GrowthData[]>;
    
    // Bulk operations
    batchInsert(users: User[]): Promise<void>;
    batchUpdate(users: Partial<User>[]): Promise<void>;
    softDeleteInactive(daysSinceLogin: number): Promise<number>;
    
    // Caching concerns mixed in
    invalidateCache(userId: string): Promise<void>;
    warmCache(): Promise<void>;
}
 
// Problems:
// 1. Any class depending on UserRepository depends on ALL methods
// 2. Mock implementations must stub 20+ methods
// 3. Changes to reporting methods affect authentication components
// 4. Caching, querying, and CRUD all coupled together

The Solution: Role-Based Repository Interfaces

By applying ISP, we segregate the repository by client role and capability:

ISP-Compliant Repository Design
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
// Read-only interface for query services
interface UserReader {
    findById(id: string): Promise<User | null>;
    findByEmail(email: string): Promise<User | null>;
    findByUsername(username: string): Promise<User | null>;
}
 
// Write operations for command services
interface UserWriter {
    save(user: User): Promise<User>;
    delete(id: string): Promise<void>;
}
 
// Search capability for search components
interface UserSearcher {
    searchByName(query: string): Promise<User[]>;
    findAll(filters: UserFilters): Promise<User[]>;
}
 
// Analytics interface for reporting module
interface UserAnalytics {
    getUserStatistics(): Promise<UserStats>;
    getUserGrowthByMonth(): Promise<GrowthData[]>;
    findTopUsersBySpending(limit: number): Promise<User[]>;
}
 
// Bulk operations for admin/batch processes
interface UserBulkOperations {
    batchInsert(users: User[]): Promise<void>;
    batchUpdate(users: Partial<User>[]): Promise<void>;
    softDeleteInactive(daysSinceLogin: number): Promise<number>;
}
 
// Implementation can implement all interfaces
class UserRepositoryImpl implements 
    UserReader, UserWriter, UserSearcher, 
    UserAnalytics, UserBulkOperations {
    // Full implementation
}
 
// Clients depend only on what they need
class AuthenticationService {
    constructor(private userReader: UserReader) {}
    // Can only read - can't accidentally modify users
}
 
class UserProfileService {
    constructor(
        private userReader: UserReader,
        private userWriter: UserWriter
    ) {}
    // Read and write, but no bulk operations
}
 
class MonthlyReportGenerator {
    constructor(private analytics: UserAnalytics) {}
    // Only analytics - no access to modify data
}
 
// Testing becomes trivial
class TestUserReader implements UserReader {
    findById(id: string) { return Promise.resolve(mockUser); }
    findByEmail(email: string) { return Promise.resolve(mockUser); }
    findByUsername(username: string) { return Promise.resolve(mockUser); }
    // Only 3 methods to mock!
}

The Testing Multiplier Effect

ISP in Microservices and API Design

Backend-for-Frontend (BFF) Pattern: ISP at Scale

The Backend-for-Frontend pattern is ISP applied to API design. Instead of a single API serving all clients (web, mobile, IoT), specialized APIs serve each client's specific needs:

BFF Pattern - Client-Specific APIs
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
// Anti-pattern: Single fat API for all clients
interface ProductAPI {
    // Full product with all relations
    getProductById(id: string): Promise<{
        id: string;
        name: string;
        description: string;
        price: number;
        inventory: number;
        supplier: Supplier;
        reviews: Review[];
        similarProducts: Product[];
        purchaseHistory: Purchase[]; // For analytics
        warehouseLocations: Location[]; // For logistics
        // ... 30 more fields
    }>;
}
 
// Problem: Mobile app downloads 10KB of data to show a 100-byte card
// Problem: Web app makes extra calls for fields not in the response
// Problem: IoT device needs just inventory but gets everything
 
// ISP Solution: Backend-for-Frontend pattern
// Mobile BFF - optimized for bandwidth and battery
interface MobileProductAPI {
    getProductCard(id: string): Promise<{
        id: string;
        name: string;
        thumbnailUrl: string;
        price: number;
    }>; // ~100 bytes
    
    getProductDetails(id: string): Promise<{
        id: string;
        name: string;
        description: string;
        images: string[];
        price: number;
        reviewSummary: { average: number; count: number };
    }>; // Loaded on user tap
}
 
// Web BFF - optimized for rich desktop experience
interface WebProductAPI {
    getProductPage(id: string): Promise<{
        product: ProductDetails;
        reviews: Review[];
        similarProducts: ProductCard[];
        breadcrumbs: Category[];
        seoMeta: SEOMeta;
    }>; // Single request for full page
}
 
// IoT BFF - minimal data for device constraints
interface IoTInventoryAPI {
    checkStock(skus: string[]): Promise<Map<string, number>>;
    subscribeToStockChanges(skus: string[]): Observable<StockChange>;
}

GraphQL: Query-Level ISP

GraphQL represents another approach to ISP in APIs—instead of segregating interfaces, it lets clients declare exactly what they need per request:

GraphQL - Dynamic Interface Segregation
GraphQL
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
# Full schema available
type Product {
    id: ID!
    name: String!
    description: String!
    price: Float!
    inventory: Int!
    supplier: Supplier!
    reviews: [Review!]!
    similarProducts: [Product!]!
    categories: [Category!]!
}
 
# Mobile client request - minimal fields
query MobileProductCard($id: ID!) {
    product(id: $id) {
        id
        name
        price
    }
}
 
# Web client request - more detail
query WebProductPage($id: ID!) {
    product(id: $id) {
        id
        name
        description
        price
        reviews {
            rating
            text
            author { name }
        }
        similarProducts {
            id
            name
            price
        }
    }
}
 
# Analytics service - different shape entirely
query ProductAnalytics($id: ID!) {
    product(id: $id) {
        id
        inventory
        reviews {
            rating
            createdAt
        }
        supplier {
            leadTime
            reliabilityScore
        }
    }
}

GraphQL Trade-offs

ISP Lessons from Framework Authors

The architects of major frameworks have articulated principles that directly connect to ISP. Understanding their reasoning helps internalize when and how to apply interface segregation.

Principle 1: "Design interfaces for clients, not implementations"

Joshua Bloch (Effective Java) emphasizes that interface design should start from consumer needs, not implementer convenience:

Client-First Interface Design

•Identify all clients: Who will depend on this interface? What do they need?
•Group by role: Do different clients need different method subsets?
•Separate by rate of change: Methods that change together should be together; methods that change independently should be in separate interfaces
•Design for the 80% case: The most common use case should require the smallest interface

Principle 2: "Prefer narrow interfaces to wide ones"

Interface Width Trade-offs
Narrow Interfaces	Wide Interfaces
Easy to implement	Burdensome to implement
Easy to mock/test	Requires extensive mocking
Changes affect fewer consumers	Changes ripple widely
Compose for complex needs	Already include complex needs
More types to manage	Fewer types, but each is larger

Principle 3: "Make interfaces hard to misuse"

Interface Design for Correct Usage
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
// Wide interface - easy to misuse
interface FileHandler {
    read(): Promise<string>;
    write(content: string): Promise<void>;
    append(content: string): Promise<void>;
    delete(): Promise<void>;
}
 
// User might call write() on a read-only file handle
// User might call delete() when they meant to close
// Interface doesn't guide correct usage
 
// Narrow interfaces - harder to misuse
interface FileReader {
    read(): Promise<string>;
    close(): void;
}
 
interface FileWriter {
    write(content: string): Promise<void>;
    append(content: string): Promise<void>;
    close(): void;
}
 
interface FileRemover {
    delete(): Promise<void>;
}
 
// Read-only handle can't accidentally write or delete
function processLogFile(reader: FileReader): void {
    // Can only read - can't accidentally modify
    const content = await reader.read();
    // ...
}
 
// Write handle can't accidentally delete
function updateConfig(writer: FileWriter): void {
    // Can write/append - can't delete the file
    await writer.write(newConfig);
}

Summary: ISP in Production Systems

Key Takeaways

•Java Collections demonstrate hierarchical ISP — Capabilities like iteration, ordering, and indexing are segregated into distinct interfaces that compose through inheritance
•Modern JavaScript frameworks embrace functional ISP — Hooks, middleware, and structural typing enable composition without interface bloat
•Spring shows ISP in enterprise contexts — Repository interfaces, event systems, and DI demonstrate role-based segregation at scale
•Database access benefits dramatically from ISP — Read/write/search/analytics separation enables testing, CQRS, and clean architecture
•API design extends ISP to network boundaries — BFF pattern and GraphQL apply segregation principles to service contracts
•Framework authors unanimously advocate narrow interfaces — Client-focused, minimal, hard-to-misuse designs are the gold standard

What's Next:

Page Complete

1 / 4