I've published a new paper: Why SRP Is Wrong: The Cardinality Error in the Single Responsibility Principle.
SRP — "a class should have only one reason to change" — is wrong. Not vague or misunderstood. Wrong.
The adapter pattern is a counterexample. A Stripe payment adapter has two reasons to change: the internal PaymentProcessor interface changes, or Stripe's API changes. Under Martin's own interpretation of his terms, that's two — not one.
SRP's prescribed remedy is to split the module. But splitting an adapter destroys its function — mediation requires both domains' knowledge in the same reasoning step. Three salvage attempts (DTO intermediate, mapping table, delegation) all fail. The adapter is irreducibly composite.
The class of counterexamples is not marginal. Every façade, bridge, API gateway, protocol translator, and anti-corruption layer that mediates between independent domains is equally a counterexample. Most complex systems contain them.
The paper formalizes the refutation in the change-driver apparatus with complete theorems and proofs. The formal apparatus is not needed to follow the argument — the counterexample stands alone — but is provided for readers who want the argument in precise, verifiable form.
Paper: Why SRP Is Wrong: The Cardinality Error in the Single Responsibility Principle., May 2026.
If you teach SRP or apply it in code reviews: does this refutation change how you think about the principle?
