Skip to content

Single Responsibility Principle

A module should have one, and only one, reason to change, because change from multiple sources creates conflicting modification pressures that fragment cohesion.

Tension Addressed

Flexibility vs. Simplicity

Recognizable As

Classes/modules that change together for the same business reason; code where a single stakeholder "owns" the change decisions; functions that do one thing at one level of abstraction

Canonical Sources

Martin, "Agile Software Development" (2002); Constantine & Yourdon, "Structured Design" (1979) - cohesion concept

Transfers To

Software Architecture (service boundaries), API Design (endpoint cohesion), Database Design (table responsibility)

The principle is often misunderstood as "do one thing" when it actually means "have one axis of change." A class calculating tax and formatting reports has two responsibilities not because it does two things, but because tax law changes and report format changes come from different stakeholders on different timelines.