Single Responsibility Principle

The Single Responsibility Principle says a software unit should have one responsibility and one reason to change.

The SRP is the first of the SOLID Principles. See also Separation of Concerns.

“A class should have one, and only one, reason to change.”
– Robert C. Martin
A module/class/function should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the module/class/function.

A module/class/function should

be responsible only and fully for a single part of the functionality, and
have all its services narrowly aligned with that responsibility.

Advantages

Code becomes more reusable
Separate responsibilities are only loosely coupled and can be replaced easily
Single responsibilities can be tested in isolation

Example

class TwitchStats
  def initialize(daily_viewers:)
    @stats = daily_viewers
  end

  def report
    sum = 0
    stats.each_pair { |day, viewers| sum = sum + viewers }
    puts "Total viewers: #{sum}"
    avg = sum / stats.length
    puts "Average viewers per day: #{avg}"
  end
  
  private
    attr_reader :stats
end

In this class, the report method does more than just calculate the results, it also formats them into strings which it then outputs to the screen.

This makes it less reusable because neither can we get the raw results alone nor can we influence the output formatting.
We can’t build tests for the method because it doesn’t return any useable data.

Antipatterns

Kitchen sink class

Boolean method arguments

A method that takes a Boolean argument by definition has two responsibilities; one for a value of true, another for false.