|WikiProject Computing / Software||(Rated Start-class, Low-importance)|
I have a copy of Demarco's book Structured Analysis and Systems Specification and chased down some references to Chapter 25, page 310 where Demarco discusses Cohesion. I was unable to find any reference to "Single responsibility principle." The phrase is not in the glossary or index. While the concept is present, the words are not used. I also have Page-Jones book The Practical Guide to Structured Systems Design. This has a more thorough discussion of Cohesion. While the concept "single responsibility principle" is present, again, I do not find the phrase. I do not know the source of this phrase, but it does not seem to be from either of these two books.
Martin states clearly that he use the term to describe the concept defined by DeMarco and Page-Jones. Other authors (C. Larman, e.g.) use high cohesion or separation of concerns referring to similar principles. 184.108.40.206 (talk) 13:42, 16 March 2015 (UTC)220.127.116.11
"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." I believe that the term was introduced in PPP in 2003. The first mention of the object-oriented commandments were in 1995, but doesn't mention it. After that, in a set of articles in ObjectMentor.com (1997) Martin discuss other principles, but not the SRP. Also there's no mention of it in the summary of 2000. 18.104.22.168 (talk) 14:57, 16 March 2015 (UTC)
"The responsibility is defined as a charge assigned to a unique actor to signify its accountabilities concerning a unique business task." This line is irrelevant for the concept defined by Martin. It's not Martin definition. 22.214.171.124 (talk) 15:01, 16 March 2015 (UTC)
"As an example, consider a module that compiles and prints a report." The following statements in that paragraph don't take into account the granularity problem of the modules. The granularity of the responsibility is relative. A module with such responsibility could be a Report Manager class, in which changes in format or printing are a single responsibility, under the reporting management perspective. Too much granularity could implies a class with a single method, but a high level view could adversely derives into a class as a program. How concrete or abstract is a main concern to this principle. How could you evaluate the correct granularity?