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.

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

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.