The difference between the principle of shared responsibility and the separation of problems

Question

What is the difference between the principle of shared responsibility and the separation of problems?

Answer 1

Unified Responsibility Principle (PSA) - give each class only one reason for change; and “Reason for change” == “duty”. In the example: The invoice class is not responsible for printing. A.

Separation of problems (since 1974). Concern == Feature of the system. acceptance to take care of each of the problems: for each one problem, the other problems do not matter. Hiding implementation behavior.

From here .

Answer 2

Separation of Concern vs Single Responsibility (SoC vs SRP)

From a related article:

Separation of problems (SoC) is the process of breaking down a computer program into separate functions that overlap functionality as little as possible. Of concern is any interest or focus in the program. Typically, problems are synonymous with functions or behavior. http://en.wikipedia.org/wiki/Separation_of_concerns

The principle of single responsibility (SRP) - each object should have one responsibility and that all its services should be narrowly coordinated with this responsibility. At some level, Cohesion is considered synonymous with SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle

Answer 3

In my opinion, the principle of single responsibility is one of the tools / idioms for achieving separation of problems.

Answer 4

The single responsibility states that the facility is responsible for the unit of work.

The Concerns section says that applications should be divided into modules whose functions overlap as little as possible.

Similar end results ... several different applications.

Answer 5

The principle of shared responsibility and separation of problems are one and the same.

Of course, you can get bogged down in an academic discussion, trying to figure out some difference between them, but why? In all senses and purposes they describe the same thing. The biggest problem is that people are so passionate that they want to know exactly what “care” and “responsibility” is, that they may be missing the important idea behind SRP and SoC.

The idea is to simply break your codebase into loosely coupled isolated parts. This allows several developers to work in different areas without affecting each other, and also allows one developer to modify one isolated part without disturbing the other.

This is applied at the module level, for example MVC is an architectural template promoting SRP and SoC. The code base is divided into isolated models, views, and controllers. Thus, a change of view can be made regardless of the model. Two two are not terribly intertwined.

At a lower level, this should also apply to classes. Instead of introducing dozens of methods into one class, split the code into several. For the same reasons.

Also, even at the method level, break large methods into smaller methods.

Basically. SRP is a principle, not a rule, so you do not need to (read: I can not / should not) follow it to the extreme. This does not mean that going too far and having only one method of seven lines in each class, for example. It just means the general principle of dividing code into separate parts. The fact is that this will lead to a better code base and more stable software.

Answer 6

Separation of Problems (SoC). Divide the application into separate functions with minimal overlap of functionality. (Microsoft).

"Concern" = "separate function" = "separate section"

Concern operates both high and low

The principle of single responsibility states that each module or class must be responsible for one part of the functionality provided by the software, and that responsibility must be fully encapsulated by the class. All of his services should be closely linked to this responsibility. (Wikipedia definition)

"Responsibility" = "reason for change" change what? "one piece of software functionality" = Main unit

Conclusion

• A single principle of responsibility works with basic units → works at a low level

• Problem separation works both high and low

• SRP and SoC work together to separate issues. They
  similarly low

Answer 7

Separation of problems is a process; The principle of shared responsibility is a design / architecture philosophy. They do not completely overlap, but they serve different purposes.

Answer 8

Similarly, but: SoC is associated with fears: to break a complex problem into several problems, SRP should have only one responsibility.

Answer 9

SRP and SOC work at different levels of abstraction. The goal in both cases is to reduce traction and increase traction. Although SRP works more at the object level, the SOC can also work on the implementation of the function level. A function can be implemented by one object, but also by several objects. Therefore, the connection and cohesion of both principles may vary.

Answer 10

I tried to make a comparison between separation of problems (SoC) and the principle of single responsibility (SRP).

Differences

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

• SRP is the quality (if not that) that divides your domain into cohesive classes that have only one responsibility (one of the reasons for the change). SoC, on the other hand, is a design principle for dividing the context into separate sections, so that each section addresses a separate problem (which is not so), since there are many tools (e.g. classes, functions, modules, packages, ...) to achieve this goal at different levels.

• The concept of SRP is based on cohesion (high cohesion), while SoC is close to Molecularity, divides and wins (D & C), ... at each level of abstraction.

• SoC is a good design that allows you to cope with complexity, such as abstraction, while to achieve individual responsible classes you can use the SoC principle as an excellent solution. As a way to find out that a class has more than one responsibility, you can extract another responsibility (concern) from this class.

Similarities

• After applying each of these principles, your context becomes more reusable, maintained, reliable, readable, ....

Answer 11

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

Martin's inspiration for PSP came from David Parnassus, Edsger Dijkstra (who coined the term “Separation of Problems”) and Larry Constantine (who coined the terms “Combination and Cohesion”). Martin combined his ideas in PSP.

Another formulation of the principle of shared responsibility:

Pack things that change for the same reasons. Separate those things that change for various reasons.

If you think about it, you will realize that this is just another way of determining cohesion and cohesion. We want to increase cohesion between things that change for the same reasons, and we want to reduce the connection between these things that change for different reasons.

However, when you think about this principle, remember that the causes of change are people. These are people who require change. And you don’t want to confuse these people or yourself by mixing code that cares about different people for various reasons.

Regarding the initial question, the slight difference between SRP and SoC is that Martin clarified the term “problems” to mean people.

Answer 12

Answer:

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

The principle of single responsibility (SRP) is used to discuss SoC at lower levels, for example, in the classroom

---

Ways to think about it:

1. At a low level, SoC and SRP are synonymous. So you can say that 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 if it is a high-level SoC or a lower-level SoC

3. To remember that SRP is a term only for lower levels, think about it: in everyday language, “responsibility” is usually a well-defined thing that can be tied to a specific code, while “problems” are usually unclear and they can cover a lot of related things, so maybe that’s why SoC is more naturally suitable for discussing the system level than SRP

4. SoC is, in a sense, a stricter requirement / principle than SRP, because it is applied at the system level, and in order to be truly achieved at the system level, it should also be used in the development of system components. That is, a high SoC level implies a decent SoC / SRP at lower levels - but the opposite is not true, that is, a lower SoC / SRP level does not imply a SoC or anything else for the next higher level, not to mention the covering system. For an example of SoC / SRP, which is achieved at the method level, but then broken at the class level, check out this post on Arthur Trosin's blog .