a)What is the difference between SRP and SoC? Perhaps that SRP is applied at class level, while SoC can be applied at system, subsystem, module, class or function levels.
b) If answer to a) is yes, is then SoC applied at class level a synonym for SRP?
thank you
The Single Responsibility Principle is about your code doing only 1 thing and you can split all functionality in several classes which all are meant for doing 1 specific thing. An example is a specific class for validation, doing some business logic, enriching a model, retrieving data, updating data, navigation, etc.
The Separation of Concerns is about your code not being tightly coupled to some other classes/systems. Using interfaces in your code helps a lot, this way you can loosly couple classes/systems to you code. A plusside on this is that it's easier to unit-test your code also. There are a lot of (IoC) frameworks which can help you achieve this, but you can implement such a thing yourself also of course.
An example of something SoC, but not having SRP
public class Foo
{
private readonly IValidator _validator;
private readonly IDataRetriever _dataRetriever;
public Foo(IValidator validator, IDataRetriever dataRetriever)
{
_validator = validator;
_dataRetriever = dataRetriever;
}
public NavigationObject GetDataAndNavigateSomewhereIfValid()
{
var data = _dataRetriever.GetAllData();
if(_validator.IsAllDataValid(data))
{
object b = null;
foreach (var item in data.Items)
{
b = DoSomeFancyCalculations(item);
}
if(_validator.IsBusinessDataValid(b))
{
return ValidBusinessLogic();
}
}
return InvalidItems();
}
private object DoSomeFancyCalculations(object item)
{
return new object();
}
private NavigationObject ValidBusinessLogic()
{
return new NavigationObject();
}
private NavigationObject InvalidItems()
{
return new NavigationObject();
}
}
As you can see, this code isn't tightly coupled to classes or other systems, because it only uses some interfaces to do stuff. This is good from a SoC standpoint.
As you can see this class also contains 3 private methods which do some fancy stuff. From a SRP standpoint, those methods should probably be placed within some classes of their own. 2 of them do something with navigation, which would fit in some INavigation class. The other does some fancy calculations on an item, this could probably be placed within an IBusinessLogic class.
Having something like this, you both have the SoC and SRP in place:
public class Foo
{
private readonly IValidator _validator;
private readonly IDataRetriever _dataRetriever;
private readonly IBusinessLogic _businessLogic;
private readonly INavigation _navigation;
public Foo(IValidator validator, IDataRetriever dataRetriever, IBusinessLogic businessLogic, INavigation navigation)
{
_validator = validator;
_dataRetriever = dataRetriever;
_businessLogic = businessLogic;
_navigation = navigation;
}
public NavigationObject GetDataAndNavigateSomewhereIfValid()
{
var data = _dataRetriever.GetAllData();
if(_validator.IsAllDataValid(data))
{
object b = null;
foreach (var item in data.Items)
{
b = _businessLogic.DoSomeFancyCalculations(item);
}
if(_validator.IsBusinessDataValid(b))
{
return _navigation.ValidBusinessLogic();
}
}
return _navigation.InvalidItems();
}
}
Of course you could debate if all this logic should be placed in the GetDataAndNavigateSomewhereIfValid method. This is something you should decide for yourself. To me it looks like this method is doing way too much stuff.
As for SRP being only applied at class level, in his books Robert C. Martin (as far as I know he popularized if not came up with the concept) states:
Clean Code, page. 138 : "The Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change."
In Agile Principles, Patterns and Practices in C#, page 116 : "[...] and relate cohesion to the forces that cause a module, or a class, to change."
Emphasis mine.
In APPP he talks in greater length about SRP and focused almost entirely on the class level. While he does seem to focus on the class level, I feel the principle is also directed to modules and other higher level constructs.
For such reason I would not qualify SRP as SoC at class level as you suggest in your question.
Here is my understanding of these principles.
Separation of Concerns (SoC) — is about a dividing a software system into smaller modules, each on these modules is responsible for a single concern. A concern, in this case, is a feature or a use case of a software system. A module has a well-defined API (interface) as a result making a whole system highly cohesive. There are two major types: horizontal and vertical.
Single Responsibility Principle (SRP) — is a design principle that states that each building block (it can be a class, a module, an object or even a function) of a system should have only a single responsibility. Robert C. Martin. Martin describes a responsibility as a reason to change. In general, it is much better to have a single class/object that has responsibility over a single part of the functionality instead of being able to perform a lot of, sometimes even unrelated, functions, making this class large and tightly coupled, so-called “God object”.
Also I described these principles in greater details in my blog post, please have a look.
https://crosp.net/blog/software-architecture/srp-soc-android-settings-example/
Here you can find a short video explaining clearly the difference between those terminologies. https://www.youtube.com/watch?v=C7hkrV1oaSY
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
