Entry-1: S - in SOLID

There is a common misunderstanding at-least from articles and videos on the topic where the "S" short for the single responsibility principle has been mentioned to mean.

A module should do just one thing.

Although there is a principle like that, this does not capture the entire idea. What the “*S”* essentially was intended to mean is.

"A module should be responsible to one, and only one, actor."

The term actor refers to a group (consisting of one or more stakeholders or users) that requires a change in the module.

where a module is regarded as a source file. a cohesive set of functions and data structures.

Still here? let’s go further…

A way we could discuss this is in the results. say we have a student class which has the following functions, calculateFees(), calculateClassHours().

public class Student {
    public void calculateFees(){
        //logic
    }

    public void calculateClassHours(){
        //logic
    }
}

This class violates the SRP because those two methods are responsible to two very different actors.

• The calculateFees() method is specified by the accounting department, which reports to a financial officer
• The calculateClassHours() method is specified and used by the Lecturers, which reports to the H.O.D for some reason to the team.

From a bird’s eye-view, no deep thoughts into the matter, the code above will work as intended but will lead to some challenges. ie. making the code reusable,tight coupling etc. and due to the way programs tend to work ie. the larger the code-base -> the proportional logic, making it even harder to understand what is going on.

So… How can we solve?.

A simple way would be to incorporate a design pattern called the Facade, which could mean a figure head for the methods, wherein we move the core logic to a separate class and then make use of those classes in the facade. Well confusing… see below.

// First, we create the student facade
public class StudentFacade {

    public void calculateFees(args1, args2){ // this should have types but we digress

    //perform logic to calculate the fees.
    HourReporter hourReporter = new HourReporter();
    hourReporter.reportHours();

    }

  public void calculateClassHours(args1, args2){
   //logic
    FeeCalculator feeCalculator = new FeeCalculator();
    feeCalculator.calculateFees();
  }
}

public class HourReporter {
    public void reportHours(){
        //logic
    }
}

public class FeeCalculator {
    public void calculateFees(){
        //logic
    }
}

So now the classes are not tightly coupled + the student facade contains very little code. It is responsible for instantiating and delegating to the classes with the functions.

Konclushun.

The SRP has the tendency to be easily misunderstood due to the name of which I hopefully clarify with some examples and improvements we can make going forward. so…what next?

You could get the Book by Uncle bob on Clean architecture, this goes deeper or dive into the references (excluding the book) to have a feel. Connect with me on the linkedIn or twitter, comment (I would love to see your thoughts), throw me a question or do something out of the blue you fancy.

That being said, this is all i have for now, thanks for coming to my talk.

References

• https://en.wikipedia.org/wiki/Single-responsibility_principle
• The Facade Pattern Explained and Implemented in Java
• Clean Architecture - Robert C. Martin , SRP: The Single Responsibility Principle chapter 7.

External Links

• Twitter: @benny_wayn
• LinkedIn: Ibenge-uforo
• Ongoing Research: Social Survey