Single-responsibility principle
The single-responsibility principle (SRP) is a computer programming principle that states that "A module should be responsible to one, and only one, actor."[1] The term actor refers to a group (consisting of one or more stakeholders or users) that requires a change in the module.
Robert C. Martin, the originator of the term, expresses the principle as, "A class should have only one reason to change".[2] Because of confusion around the word "reason" he has also clarified saying that the "principle is about people."[3] In some of his talks, he also argues that the principle is, in particular, about roles or actors. For example, while they might be the same person, the role of an accountant is different from a database administrator. Hence, each module should be responsible for each role.[4]
History
The term was introduced by Robert C. Martin in his article "The Principles of OOD" as part of his Principles of Object Oriented Design,[5] made popular by his 2003 book Agile Software Development, Principles, Patterns, and Practices.[6] Martin described it as being based on the principle of cohesion, as described by Tom DeMarco in his book Structured Analysis and System Specification,[7] and Meilir Page-Jones in The Practical Guide to Structured Systems Design.[8] In 2014 Martin published a blog post titled "The Single Responsibility Principle" with a goal to clarify what was meant by the phrase "reason for change."[1]
Example
Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to be changed (e.g. rewritten).
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 different causes. 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 a greater danger that the printing code will break if it is part of the same class.
See also
- Chain-of-responsibility pattern
- Coupling (computer programming)
- GRASP (object-oriented design)
- Information hiding
- SOLID – the "S" in "SOLID" represents the single-responsibility principle
- Separation of concerns
References
- ↑ Martin, Robert C. (2018). Clean architecture : a craftsman's guide to software structure and design. Boston. ISBN 978-0-13-449432-6. OCLC 1003645626. https://www.worldcat.org/oclc/1003645626.
- ↑ Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. p. 95. ISBN 978-0135974445. https://books.google.com/books?id=0HYhAQAAIAAJ.
- ↑ Martin, Robert C. (2014). "The Single Responsibility Principle". https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html.
- ↑ Robert C. Martin (2018). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. ISBN 978-0-13-449416-6. https://books.google.com/books?id=8ngAkAEACAAJ.
- ↑ Martin, Robert C. (2005). "The Principles of OOD". http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod.
- ↑ Martin 2003, pp. 95-98
- ↑ DeMarco, Tom. (1979). Structured Analysis and System Specification. Prentice Hall. ISBN 0-13-854380-1. https://archive.org/details/structuredanalys0000dema.
- ↑ Page-Jones, Meilir (1988). The Practical Guide to Structured Systems Design. Yourdon Press Computing Series. p. 82. ISBN 978-8120314825.
External links
- "The Principles of OOD" by Robert Martin
- "The Single Responsibility Principle" by Robert Martin
 |
