Skip to content

Interface segregation principle

The SOLID rule that clients should not depend on interface methods they do not use — decompose a fat interface into role-specific ones sized to each consumer's usage footprint, so a contract change's blast radius is read off the boundary rather than the call graph.

Version
v5 · 2026-09-19 · History
Domain-specific #
557
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomain
Object Oriented Design → Computer Science & Software Engineering

Core Idea

The Interface Segregation Principle (ISP), one of Martin's SOLID principles, holds that clients should not be forced to depend on interface methods they do not use. It targets the fat interface — a contract bundling methods for several client roles, forcing each client to depend on the whole bundle. In a typed, compiled system that declaration creates compile-, link-, and deploy-time coupling. The fix decomposes the fat interface into role-specific interfaces, each shaped by one client's usage footprint, so change propagates only to clients that declared they need the changed method.

How would you explain it like I'm…

Just the Crayon You Need

Imagine you only want to borrow a crayon, but you have to take the whole giant art box. Every time anything in the box changes, you have to come get the box again. The interface segregation principle says: give each kid just the small box they need.

Small Lists, Not One Big List

In programming, an interface is a list of things a piece of code can do. Sometimes one interface lists lots of jobs, like saving, printing, and spell-checking, even though most users only need one of them. Then whenever any job on the list changes, everyone using the list has to be rebuilt, even if they never use that job. The interface segregation principle says to split the big list into small lists, one for each kind of user. That way a change only affects the code that actually uses it.

Split Fat Interfaces by Role

The Interface Segregation Principle, one of Robert Martin's SOLID principles, says that clients shouldn't be forced to depend on interface methods they don't use. The problem is the 'fat interface': one contract bundling methods for several different kinds of users, so every user depends on the whole thing. In compiled languages that dependency is real. Changing any method forces every importing client to be rebuilt and redeployed, even clients that never call that method. The fix is to split the fat interface into small role interfaces shaped by what each type of client needs. A Document class might then implement Saveable, Printable, Translatable, and SpellCheckable separately. The backup service imports only Saveable, so changes to spell-checking never reach it.

 

The Interface Segregation Principle (ISP), from Robert Martin's SOLID set, states that no client should be forced to depend on methods it does not use. It addresses fat interfaces, which aggregate methods serving multiple distinct client roles. In statically typed, compiled systems, importing such an interface creates compile-time, link-time, and deployment-time coupling to the whole bundle. A change to any method then forces rebuilds and re-verification of every dependent, which is costly in continuous-delivery pipelines. The remedy is to decompose the contract into role interfaces sized to one coherent client type's usage footprint. The implementing class implements each applicable role. For instance, a Document can implement Saveable, Printable, Translatable, and SpellCheckable, while backup, printing, and translation services each import only their role. ISP applies Parnas-style information hiding and coupling minimization at the method-contract level. Interface granularity determines a change's blast radius, and the right granularity follows the client's footprint, not the implementer's convenience.

Scope of Application

Lives across the subfields of software design that share a typed contract whose declaration creates compile-, link-, or deploy-time coupling across a dependent build graph; its reach is within that domain.

  • Object-oriented method contracts — splitting Readable/Writable/Seekable out of a fat File.
  • RPC and REST API design — dividing endpoint surfaces by client persona rather than implementation.
  • GUI toolkits — role interfaces (Focusable, Resizable) rather than one giant Widget.
  • Plugin architectures — focused per-event hooks rather than one fat ExtensionPoint.
  • Trait and type-class design — Rust traits, Haskell type classes, small role-specific contracts.

Clarity

ISP makes legible a coupling invisible at the level of method calls: a client is coupled to every method it declares a dependency on, not merely those it invokes — so a backup service that never calls spell-check still recompiles when a spell-check signature changes. It also sharpens whose needs an interface is for: a service to its consumers, sized to one client role's footprint, not a manifest of what the implementer happens to do. That distinction separates ISP from its SOLID siblings that constrain the implementation or governs access.

Manages Complexity

The dreaded question — if I change this method, what breaks? — is, under fat interfaces, an intractable graph walk that even a call-graph trace answers wrongly. ISP collapses it to one readable quantity: interface granularity. Once each interface is sized to a client role's footprint, the blast radius is simply the set of clients of the affected sub-interface, read directly off the boundary. It installs a clean discrimination — implementer's manifest versus consumer's footprint — and separates the contract axis (ISP) from the implementation-cohesion axis (single-responsibility).

Abstract Reasoning

ISP licenses a diagnostic (read spurious rebuilds of a client that never calls the changed method back to a fat interface, recognizing the declaration is the coupling channel), a predictive read of change-propagation off interface granularity, an interventionist refactor (decompose to role interfaces sized to the consumer's footprint) with predicted structural insulation, and boundary-drawing that keys the pathology to typed compiled substrates and separates ISP from single-responsibility and least-privilege.

Knowledge Transfer

Within software design ISP transfers as mechanism — the diagnostic, the sizing rule, the blast-radius prediction, and the sibling discriminations carry intact wherever a typed contract's declaration creates build-graph coupling, from OO method contracts to REST surfaces to traits and type classes. Beyond typed software the transfer is mixed: surface analogues (over-bundled job descriptions, over-broad forms) are metaphor, since the type-system-mediated dependency propagation is absent. The genuinely portable insight — minimize shared knowledge, size a boundary to the consumer's need — travels as the parents Interface, Modularity, and need_to_know (information hiding); ISP is what those jointly prescribe for OO method contracts.

Relationships to Other Abstractions

Local relationship map for Interface segregation principleParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Interfacesegregation principleDOMAINPrime abstraction: Interface — presupposesInterfacePRIMEPrime abstraction: Modularity — is a decomposition ofModularityPRIME

Current abstraction Interface segregation principle Domain-specific

Parents (2) — outgoing typed relations

  • Interface segregation principle presupposes Interface Prime

    Interface segregation presupposes a rule-governed dependency surface whose exposed contract can be compared with each client's actual use.

  • Interface segregation principle is a decomposition of Modularity Prime

    ISP is modular decomposition applied to a contract surface, partitioning a fat interface into independently changing role-sized units.

Hierarchy paths (2) — routes to 2 parentless roots

  • Interface segregation principle → presupposes Interface → is a decomposition of Boundary

Neighborhood in Abstraction Space

Interface segregation principle sits in a moderately populated region (60th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Software Evolution Laws & Code Smells (17 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25