This is an old revision of the document!
Table of Contents
Single Responsibility Principle (SRP)
Variants and Alternative Names
- One Responsibility Rule
- Separation of Concerns (this originally was a broader term but is mostly used just like SRP)
Context
Definition
Description
Every module should have one single responsibility. This means two separate concerns/responsibilities/tasks should always be implemented in separate modules. Robert C. Martin defines a “responsibility” as a “reason to change”. If a module has several responsibilities, there are several reasons to change this module—namely the requirements for each responsibility may change. On the other hand a reason to change a module also means that it is the responsibility of the module to implement the aspect that is changed.
Depending on whether a module in the given context is a class, a method, a library, etc. (i.e. the level of abstraction), the granularity of what is seen as a responsibility may differ.
Rationale
When this rule is not adhered to, one module has several tasks. If one of these tasks changes, there is the risk that this also has an effect on the other task that normally should be independent. Thus unrelated functionality may break.
Origin
Evidence
Relations to Other Principles
Generalizations
Specializations
Contrary Principles
Complementary Principles
Principle Collections
Example
Description Status
Further Reading
- Robert C. Martin: Agile Software Development, Principles, Patterns, and Practices