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.

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.

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) — more general patterns this builds on

  • 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

Neighborhood in Abstraction Space

Interface segregation principle sits in a crowded region of the domain-specific corpus (38th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Software Evolution & Systemic Laws (16 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12