Originally posted at ellehallal.devπ©π½βπ»
The Single Responsibility Principle(SRP) is one of the five SOLID principles of object-oriented programming. The intention is to βmake software designs more understandable, flexible and maintainableβ.
SRP is the concept that a class should have one responsibility, and therefore only one reason to change.
Implementing The Principle
Iβm currently working on a Tic Tac Toe game in Ruby, where I have been provided with a number of user stories. The first user story is: as a user, I can see the initial board.
Breaking this down, my understanding is there needs to be a Tic Tac Toe board, and the user needs to be able to see it.
Creating The Board
class Board
  attr_reader :board
  def initialize(board)
    @board = board
  end
end
Above, the Board class takes a board as an argument when initialised. For a Tic Tac Toe game, an array containing numbers 1β9 will be passed when an instance of Board is initialised.
board = Board.new([1, 2, 3, 4, 5, 6, 7, 8, 9])
Displaying The Board
To show the Tic Tac Toe board, a method is needed to show the output to the user. For example:
def display_board(board)
  print """
    #{board[0]} | #{board[1]} | #{board[2]}
    -----------
    #{board[3]} | #{board[4]} | #{board[5]}
    -----------
    #{board[6]} | #{board[7]} | #{board[8]}\n"""
end
It would be natural to assume this method should be within the Board class, simply because that is where the Tic Tac Toe board lives.
However, what if changes were to occur in the future? For example, if the application was to become web-based, rather than command line based, display_board would be a redundant method. As a result, it is likely that any methods within Board containing output would need to be changed.
What would happen if all output was contained within a separate class? In the case above, the Board class wouldnβt need to be amended because it doesnβt contain methods that are printing to the command line.
With this in mind, a new class called Display, was created with the display_board method added:
class Display
  def display_board(board)
    ...
  end
end
For other user stories, where printing a message to the command line is needed, such as prompting the user for a move and displaying the current player, it will be contained within this class.
Conclusion
By implementing the Single Responsibility principle, the Board and Display classes have one responsibility each and only one reason to change.
The Board class manages the state of the Tic Tac Toe board. In relation to the user story, it creates a Tic Tac Toe board.
The Display class manages printing output to the command line for the user to see. In relation to the user story, the user can see the initial board.
              
    
Top comments (0)