Skip to content

Single-Responsibility Principle

A module should have exactly one reason to change — read as one external change-driver, not one function — so that aligning each boundary with a single driver keeps every edit's blast radius contained.

Core Idea

The Single-Responsibility Principle, the S of the SOLID canon, holds that a module — class, function, or microservice — should have exactly one reason to change. "Reason to change" is operative: responsibility is read not as what the unit does but as which actor or change-driver could force it to be edited. A class that computes payroll and formats reports has two reasons to change and thus two sources of coupling. The prescription is to decompose along the change-axes, aligning each boundary with exactly one change-driver.

Scope of Application

The principle lives across the design subfields of software and computing, recurring at every unit of decomposition.

  • Object-oriented class design — the canonical home and the S of SOLID; split along change-drivers.
  • Function design — a function that both validates and writes to disk forces callers to inherit both concerns.
  • Microservice architecture — each service owns one business capability; aggregating two brings joint deployment risk.
  • Module and component boundaries — the same change-axis alignment cuts package seams so blast radius stays contained.

Clarity

The principle's force is redefining "responsibility" from what a unit does — hopelessly elastic — to reason to change, which actor could force an edit. That replaces an argument about functional description with an enumerable question about the environment, making the diagnostic concrete: list every distinct driver; more than one unrelated entry means the seam is misplaced. It also names the cost as blast radius escaping its reason.

Manages Complexity

Carving a system into modules is a combinatorial sprawl where "do one thing" gives no purchase. SRP compresses it onto one external coordinate — the finite list of change-drivers in the environment — so decomposition is read off directly (one module per driver), and the blast radius of any future change reduces to tracking whether each unit maps to exactly one driver.

Abstract Reasoning

SRP supports enumeration run against the environment not the code (count drivers, read a verdict), a predictive move forecasting blast radius from driver count, an interventionist move decomposing along change-axes (while supplying no unique algorithm), and a boundary-drawing move — deciding which candidate drivers are genuinely distinct versus facets of one responsibility — that it explicitly marks as judgment, not mechanism.

Knowledge Transfer

Within software SRP transfers as mechanism across every unit of decomposition — the responsibility-as-reason-to-change reinterpretation, the enumeration test, and the blast-radius prediction carry intact at class, function, and service grain. Beyond software the structural insight is carried at that generality by the parents modularity, separation_of_concerns, and cohesion; SRP adds no structural move not already inside them, only software-specific operationalization and rule-force. Reaching for it outside a development regime is mostly analogical.

Relationships to Other Abstractions

Local relationship map for Single-Responsibility 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.Single-ResponsibilityPrincipleDOMAINPrime abstraction: Modularity — is a decomposition ofModularityPRIME

Current abstraction Single-Responsibility Principle Domain-specific

Parents (1) — more general patterns this builds on

  • Single-Responsibility Principle is a decomposition of Modularity Prime

    SRP is modular boundary drawing specialized to one external change-driver per software unit.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Single-Responsibility Principle sits in a sparse region of the domain-specific corpus (91st percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (309 abstractions)

Nearest neighbors

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