Difference between Single Responsibility Principle and Separation of Concerns

Since none of the previous answers quote Robert Martin, who created the Single Responsibility Principle, I think a more authoritative answer is needed here.

Martin's inspiration for the SRP was drawn from David Parnas, Edsger Dijkstra (who coined the term Separation of Concerns) and Larry Constantine (who coined the terms Coupling and Cohesion). Martin consolidated their ideas into the SRP.

Another wording for the Single Responsibility Principle is:

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

If you think about this you’ll realize that this is just another way to define cohesion and coupling. We want to increase the cohesion between things that change for the same reasons, and we want to decrease the coupling between those things that change for different reasons.

However, as you think about this principle, remember that the reasons for change are people. It is people who request changes. And you don’t want to confuse those people, or yourself, by mixing together the code that many different people care about for different reasons.

To the original question, the minor difference between the SRP and SoC is that Martin refined the term concerns to refer to people.

Answer:

Separation of Concerns (SoC) is a more versatile term - it can be applied at the system level or at lower levels such as classes (or even the methods within a class)

Single Responsibility Principle (SRP) is used to discuss SoC at the lower levels e.g. in a class

Ways to think about it:

1. At the low level, SoC and SRP are synonymous. So you could say SRP is a redundant term - or that SoC should only be used to discuss the system level

2. Given (1), the term SoC is somewhat ambiguous. You need context to know whether the discussion is about high level SoC or lower level SoC

3. To remember that SRP is the term for only lower levels, think of this: in everyday language, a "responsibility" is usually a well-defined thing that can be tied to specific code, whereas "concerns" are usually kind of vague and may encompass a bunch of related things, which is perhaps why SoC is a more natural fit for discussing the system level than is SRP

4. SoC is in some sense a stronger requirement/principle than SRP because it applies at the system level, and to be truly achieved at the system level must also be used in the development of the system components. That is, a high level of SoC implies decent SoC/SRP at the lower levels - but the reverse is not true, that is, lower level SoC/SRP does not imply SoC or anything at all for the next higher level, never mind the encompassing system. For an example of SoC/SRP that is achieved at the method level, but then violated at the class level, check out this Artur Trosin's blog post.

Separation of Concerns

The Separation of Concerns (SOC) principle states that a code artifact should allow one to focus one's attention upon a certain aspect. A code artifact can be anything, from a specific function, to a class, or a whole package, or even an entire application. The SOC principle can be applied to every architectural level in one's applications. An example of an architecture where SOC is applied is a layered architecture.

Single Responsibility Principle

The Single Responsibility Principle (SRP) states that "A module should have one, and only one, reason to change" (Clean Architecture, Martin, p. 62). The SRP applies to the module level and when applying the SRP one should be focused on the reason to change.

Conclusion

The SOC principle states that a code artifact should allow one to focus one's attention upon a certain aspect. The SRP makes this concrete by stating that at the module level we should focus our attention at the reason of change. Thus the SRP is a SOC.

P.S. For completeness: the Common Closure Principle

The Common Closure Principle (CCP) is a restatement of the SRP at an even higher level, the component level. The CCP states that classes that change for the same reasons and at the same times should be gathered into the same components (Clean Architecture, p. 105). The CCP is another example of a SOC.