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.
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.
See section contrary principles.
Discuss this wiki article and the principle on the corresponding talk page.