19

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

14

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.

  • "After reading the full post in JB King's answer, I think that's a good post as well." But JB King's answer is claiming the opposite of your answer - namely that SoC is also about single responsibility, only that it can be applied at higher levels than SRP – user1483278 Jul 4 '12 at 20:05
2

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.

  • So if we assume that SRP can also be applied at higher levels, then the difference between SRP and SoC is that SRP has a single responsibility, while SoC can have a set of closely related responsibilities? – user1483278 Jul 4 '12 at 19:34
  • @user1483278 : Well I am very familiar with SRP but I first heard of SoC while reading this question so I cannot answer the question in your comment. From the semantics it seems SRP is about having 1 responsability and SoC seperating concerns, I know that's a pedantic answer but in application bother principles produce similar results. – Gilles Mar 13 '13 at 15:45
0

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

0

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/

protected by gnat Apr 28 '17 at 9:08

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.