Difference between Single Responsibility Principle and Separation of Concerns

Question

What is the difference between Single Responsibility Principle and Separation of Concerns?

Answer 1

Single Responsibility Principle (SRP)- give each class just one reason to change; and “Reason to change” == “responsibility”. In example: Invoice class does not have a responsibility to print itself.

Separation of Concerns (since 1974). Concern == feature of system. Taking care of each of the concerns: for each one concern, other concerns are irrelevant. Hiding implementation of behavior.

From here.

Answer 2

Separation of Concerns is a process; the Single Responsibility Principle is a design / architecture philosophy. They're not completely disjoint, but they serve different purposes.

Answer 3

Separation of Concern vs Single Responsibility Principle ( SoC vs SRP )

From the linked article:

Separation of Concerns (SoC) – is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. http://en.wikipedia.org/wiki/Separation_of_concerns

Single Responsibility Principle (SRP) – every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility. On some level Cohesion is considered as synonym for SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle

Answer 4

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.

Answer 5

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.

Answer 6

In my opinion Single Responsibility Principle is one of the tools/idioms to achieve Separation of Concerns.