Wrong, wrong, wrong. Oh brother, you are sooo wrong. Let’s look at the use of the term responsibility in this article.
http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/
That is to say, no element should share in the responsibilities of another or encompass unrelated responsibilities.
Plural, as in, a concern has responsibilities. More than one class, because a class should only have one responsibility.
Separation of concerns is achieved by the establishment of boundaries. A boundary is any logical or physical constraint which delineates a given set of responsibilities.
We are back to a “set” of responsibilities. A SET Tony!
Though the process of achieving separation of concerns often involves the division of a set of responsibilities, the goal is not to reduce a system into its indivisible parts, but to organize the system into elements of non-repeating sets of cohesive responsibilities.
Oh, a beautiful sentence, which you should be choking on!
Third, the strategies required to ensure each component only concerns itself with a single set of cohesive responsibilities often result in natural extensibility points.
Set of cohesive responsibilities. A set. Not one. A set or them. A concern is a set of responsibilities, not just one.
Within large companies, ensuring that groups and sub-organizations are assigned a unique set of cohesive responsibilities helps to facilitate overall business goals by minimizing the coordination necessary between teams and maximizing the potential of each team to focus on their collective responsibility and center of competency.
More than one again. Oh, but a set of responsibilities that belong to a team of people, who have a collective responsibility. Has nothing to do with SRP. NOTHING!
When responsibilities are properly delineated, problem identification becomes easier, resolution becomes faster, and personal accountability is increased.
No mention about SRP being the same as SoC.
Delegating concerns refers to the process of assigning the responsibility for fulfilling behavior to a subordinate component. This strategy separates the concerns of responsibility from execution, and is beneficial for designing components whose implementation details may vary depending on external conditions.
Ok, this is as close as you’ll get to the author saying SRP is in anyway similar to SoC, in that he mentions “components”. A class can be a component, but also a group of classes could also form a component. So you lose. He doesn’t mean at all that SRP and SoC are the same.
Scott