Episode 09 – Single Responsibility Principle

Clean Code

Episode 09

The ninth episode talks about the Single Responsibility principle.

  • Responsibility
    • Function and module.
    • Best module has only one responsibility
  • It’s about user
    • Responsibility that classes and function has to the user, who will request changes.
    • Responsibility can be view as the sources of change.
    • e.g. Employee class with method calculatePay, save, empolyeeInfo.
      • user for calculatePay maybe from accountants.
      • user for save maybe from DBA if the data is save in the database.
      • user for employeeInfo maybe from people who request the report.
  • It’s about role
    • Avoid coupling software, separate the user of the software from the role they play.
    • When user play a certain role, they are call actor. Responsibility is tied to actor and not to individual.
  • Reprise
    • Responsibility is a family of function serve one particular actors.
  • The two values of software
    • Secondary value is its behavior (no bug, no crashes).  Achieve by meeting the user’s need.
    • Primary value is the ability to change.
  • Friction
  • CM Collision
    • When a software with multiple responsibility is being changed by multiple users, changes would collide.
  • Fan out
    • Multiple responsibility will force the class to use multiple API. Thus, a large fan out is sensitive to changes in large array of API and cause the software its stability.
  • Collocation is coupling
    • When a software with multiple responsibility, changes from one of the users may force all other users calling this module to have to recompile and re-deploy when the changes has nothing to do with them.
  • Encroaching Fragility
    • Changes come from one user in module with multiple responsibility can affect another user when the two users initially share the usage of the same function.
  • SRP
    • Gather things that changes for the same reason and separate things that are not change for the same reason.
  • Invert Dependency
    • Separate the employee class into implementation and interface but the actors are still coupling
  • Extract Class
    • Separate the employee into three classes for each actors. However, its hard to find the right function for an employee class since it is now three different classes.
  • Facade
    • All users are using the facade class which delegate the implementation to different classes (like previously). However, actors still coupled.
  • Interface Segregation
    • Create 3 interface classes but one implementation class (see Invert dependency). Each actor is entirely decouple from the other because each actor uses its own interface. But developer need to hunt for the interface they need (see Extract Class) and implement still coupled because they are in the same implementation class.
  • Welcome to Engineering
    • No one solution fit all, balance the tradeoff.
  • Faking it
    • The episode follows a waterfall development cycle but in fact, it was done using TDD.
  • References