Difference between Single Responsibility Principle and Separation of Concerns

开发者_StackOverflow社区What is the difference between Single Responsibility Principle and Separation of Concerns?

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.

The Single Responsibility Principle and Separation of Concerns are really the same thing.

Sure, you can get bogged down in an academic discussion trying to tease out some kind of difference between the two, but why? For all intents and purposes, they describe the same thing. The biggest problem is people get so caught up in wanting to know exactly what a "concern" and "responsibility" are, that they perhaps miss the important idea behind SRP and SoC.

That idea is simply to split your codebase into loosely coupled, isolated parts. This allows multiple developers to work on different parts without affecting each other, it also allows a single developer to modify one isolated part without breaking another.

This is applied at the module level, e.g. MVC is an architectural pattern promoting SRP and SoC. The codebase is split out into isolated models, views and controllers. That way, the modification of a view can be done independently of a model. The two aren't horrifically intertwined.

At a lower level, this should be applied to classes too. Instead of putting dozens of methods in a single class, split the code out into several. For the same reasons.

Also, even at a method level, split large methods out into smaller methods.

In principle. SRP is a principle, not a rule, so you don't have to (read: can't/shouldn't) follow it religiously to the extreme. It doesn't mean going too far and having only one seven line method in each class, for example. It just means a general principle of splitting out code into isolated parts. The point is it will lead to a better codebase and more stable software.

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

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

Single Responsibility states that an Object be responsible for a single unit of work.

Seperation of Concerns states that applications should be split in to modules whose functionalities overlap as little as possible.

Similar end results...slightly different applications.

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.

Separation of concerns (SoC). Divide your application into distinct features with as little overlap in functionality as possible. (Microsoft).

“Concern” = “distinct feature” = “distinct section”

“Concern” works at both high and low levels

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. (Wikipedia definition)

“Responsibility” = “reason to change” change what? “a single part of the functionality provided by the software” = Basic Unit

Conclusion

• Single Responsibility Principle works on basic units -> works at low level

• Separation of Concerns works at both high and low levels

• SRP and SoC work together for separation of concerns. They are
  exactly the same at low level

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.

Similar but: SoC is related to concerns: to break down a complex problem into several concerns, SRP is to have just one responsibility.

SRP and SOC work on different level of abstraction. The purpose is in both cases to reduce the coupling and strengthen the cohesion. While SRP works more on an object level, SOC may also work on the implementation of function level. A function can be implemented by one object but also by several objects. Therefore the coupling and the cohesion of both principles may differ.

I tried to draw a comparison between Separation of concerns(SoC) and Single Responsibility Principle(SRP).

Differences

• The SRP is at the class level, but SoC is in each computer program, abstraction ... or sometimes architectural level.

• The SRP is about the quality of (how not what) dividing your domain into cohesive classes which have just one responsibility (one reason to change). In other side, SoC is a design principle for separating a context into distinct sections, such that each section addresses a separate concern(what not how), as there are a lot of tools (for example classes, functions, modules, packages, ...) to reach this goal different levels.

• The concept of SRP is based on the cohesion (high cohesion), whereas SoC is close to Molecularity, divide and conquer (D&C), ... in each level of abstraction.

• SoC is a good design principle to cope complexity, such as abstraction whereas to reach single responsible classes you can use SoC principle as a great solution. As, a way to know that a class has more than one responsibility is if you can extract another responsibility(concern) from that class.

Similarities

• After applying each of these principles, your context becomes more reusable, maintainable, robust, readable, ... .

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.