Question The Single responsibility principle

[Lars]

According to the https://en.wikipedia.org/wiki/Single_responsibility_principle a method should only do one thing. But the caller of that method will probably do 5,6,7 tasks. You could write the name of that task to make it look like it performs one task, which is what it does, but it will do it by delegating 7 subtasks. A colleague of mine complained that one of my methods dod more than one thing. Can someone ellaborate on the matter? Isn't it only the leaf methods which will perform one task?

 

[jmcilhinney]

It depends on your definition of a task. For instance, a computer factory could be said to have the single responsibility of building computers. Obviously though, the responsibility of building a computer can be broken up into smaller tasks and some part of the factory will each have the single responsibility of performing each of those. Each of those subtasks can be broken down again and maybe some person within the part of the factory will have the single responsibility of performing one of those. What constitutes a single responsibility depends on exactly what level you're looking at. The SRP is a guiding principle only, so there's no one right way to implement it. Some implementations would be obviously right and some obviously wrong but there's a whole lot of grey area.

To comment on your specific case, we'd need to see the method at least, but also possibly know more about the specific context.

 

[stevensrmiller]

As I recall it, the Single Responsibility Principle applies to a class as a whole, which includes methods. Unfortunately (in my humble opinion), the principle is often expressed in a sort of academic form, as "a class should only have one reason to change." For someone new to the concept, that can be hard to put to use. In practice, I think it tends to mean that a class has more than one responsibility if what you use it for could be handled with two classes, each of which can do its job without referring to the other. For example, if you have this class:

class Employee
{
    public String FirstName;
    public String LastName;
    public long IDnumber;

    public boolean IsPromotionDue()
    {
    // promotion logic
    }
}

It makes little sense to divide the first name, last name, and ID number of an employee into separate classes, because you're probably going to need all three of those pieces of data anytime you need any one of them. But you're not going to ask if an employee is due for promotion each time you refer to an employee. Separating that functionality out into another class helps the Employee class remain responsible solely for maintaining employee descriptive information.

class Employee
{
    public String FirstName;
    public String LastName;
    public long IDnumber;
}

class Promotions
{
    public boolean IsPromotionDue(Employee employee)
    {
    // promotion logic
    }
}

If the way an employee's description is kept changes (you want to maintain their starting date, for example), that class, and that class alone, has to change. If the basis upon which an employee is due for promotion changes, the Employee class does not have to change; the Promotions class does.

This is mostly about maintainability. That is, keeping classes limited to one responsibility makes it easier to create, debug, and update them than it would be if classes had multiple responsibilities. It can also improve the chances that a class can be used in another application (though I personally believe the notion of "reusability" is more theoretical than practical, unless one is developing an actual library instead of a particular application). This is especially true if you are working with others, as one of you might be assigned to make a change to how an employee's descriptive data is maintained, while another is assigned to change how promotion eligibility is determined. By keeping those responsibilities in separate classes, each of you can change the relevant class at the same time as the other is changing their relevant class, with no collisions or complicated control tools being needed.

Methods are similar: to the extent it can, a method should do only one thing. When you find a method doing more than one thing, that's a sign that each of those things should be done by each of more than one method, with some other method calling them.

The Single Responsibility Principle is the "S" in the acronym "SOLID," which stands for five principles of good object-oriented design. Google that and you'll get all kinds of (potentially) useful design guidance.