Single responsibility principle
|This article needs additional citations for verification. (January 2010) (Learn how and when to remove this template message)|
The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. Robert C. Martin expresses the principle as follows:
|“||A class should have only one reason to change.||”|
The term was introduced by Robert C. Martin in an article by the same name as part of his Principles of Object Oriented Design, made popular by his book Agile Software Development, Principles, Patterns, and Practices. Martin described it as being based on the principle of cohesion, as described by Tom DeMarco in his book Structured Analysis and Systems Specification, and Meilir Page-Jones in The Practical Guide to Structured Systems Design.
Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change. As an example, consider a module that compiles and prints a report. Imagine such a module can be changed for two reasons. First, the content of the report could change. Second, the format of the report could change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.
The reason it is important to keep a class focused on a single concern is that it makes the class more robust. Continuing with the foregoing example, if there is a change to the report compilation process, there is greater danger that the printing code will break if it is part of the same class.
The responsibility is defined as a charge assigned to a unique actor to signify its accountabilities concerning a unique business task.
- Separation of concerns
- Chain-of-responsibility pattern
- Cohesion (computer science)
- Open/closed principle
- SOLID - the "S" in "SOLID" stands for the single responsibility principle
- GRASP (object-oriented design)
- Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. p. 95. ISBN 978-0135974445.
- Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. pp. 95–98. ISBN 0-13-597444-5.
- DeMarco, Tom. (1979). Structured Analysis and System Specification. Prentice Hall. ISBN 0-13-854380-1.
- Page-Jones, Meilir (1988). The Practical Guide to Structured Systems Design. Yourdon Press Computing Series. p. 82. ISBN 978-8120314825.
- Feltus C. (2014). Aligning Access Rights to Governance Needs with the Responsibility MetaModel (ReMMo) in the Frame of Enterprise Architecture (PDF).