Difference between Concern and Responsibility ( ie difference between SRP and SoC )?

Question

SRP - each class should have just one responsibility ( ie reason to change)
Separation of Concerns 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. (Concern == feature of system. )

a) To my understanding the only difference between the two is that SRP tries to separate responsibilities into different classes and SoC tries to separate concerns into different modules?!

b) If assumption under a) is correct, what is the difference between a concern and a responsibility ( besides the fact that responsibility exists at a lower level of abstraction )?

Thank you

Answer 1

That is how I view them - the same principle, usually referenced at different levels of abstraction.

Answer 2

Nice question. :) Disclaimer: Just my thoughts. I have not thought about the distinction before. I don't think there is much difference between the two concepts.

However, here is what I would say: I know only about cross cutting concerns. Although the basic idea of a concern is, as you put it, any piece of interest or focus in a program, do the concerns become responsibilities if they are not cross cutting?

I think the principle is same. And even my understanding is same as yours. In a shopping cart system, adding items to cart can be considered as a concern... the main thing that use case is supposed to do. The involved classes are not really concerned about logging, security etc. Even if the logging is not there, an item can be added to the class. But for a cart or service must expose a functionality to add items otherwise, the use case fails. Similarly, for a logging use case, if the logger fails to to log the activity, it will mean that the logging use case is not working, even if the item was added to the cart.

Somewhat like, whose responsibility is it to add item to cart? (Let's say CartService) Will it be held accountable if the AddItemToCart story fails? Yes. Will it be held accountable if the LogAddItemActivity fails? No. Is AddItemToCart story concerned with logging activity. It is. Can it be separated from the activities CartService is responsible for? Modules and classes are abstractions at different levels.