S : The Single Responsibility Principle

A class should have one, and only one, reason to change.

# A Class with Too Many Responsibilities

• each responsibility is also a reason to change_._
• For a class with multiple responsibilities when one of the responsibilities requires a change, the entire class needs to be opened and modified, while most of it may have nothing to do with the requested change itself.
• Changing existing code needs to minimised and responsibilities are reasons to change, try to minimise the number of responsibilities of each class.
  • This would minimise the chance that the class has to be opened for modification.
• A class with no responsibilities is a useless class so reduce it to one.

Recognising Violations of the Single Responsibility Principle

• Symptoms of a class violating the Single Responsibility principle:
  • The class has many instance variables.
  • The class has many public methods.
  • Each method of the class uses different instance variables.
  • Specific tasks are delegated to private methods.
  • it is likely to have many dependencies .
    • It probably gets many objects injected as constructor arguments to be able to fulfill its goal.

# Refactoring: Using Collaborator Classes

• The way we can refactor a class with multiple responsibility is by extracting collaborator classes.

Example

class ConfirmationMailMailer has dependencies a templating engine for rendering the body of the email message, a translator for translating the message’s subject, and a mailer for sending the message

it has responsibilty to create a confirmation mail and to send it.

Since the class is a “mailer,” it should have responsibility of sending the message to the user.

Extract the responsibility of creating the message, he creation logic of the confirmation mail has been placed inside ConfirmationMailFactory

# Advantages of Having a Single Responsibility

• A side effect of the refactoring to single responsibilities, is easier testing. Test each responsibility separately.
  • Having a single responsibility will make a class smaller, so will have to write fewer tests to keep that class covered.
  • Small classes will have fewer private methods with effects that need to be verified in a unit test.
• smaller classes are simpler to maintain.
  • It is easier to grasp their purpose and all the implementation details are where they belong: in the classes responsible for them.

# Packages and the Single Responsibility Principle

• In the context of package design, “having only one reason to change” becomes “being closed against the same kind of changes”.
  • The corresponding package principle is called the Common Closure principle
• When a package has many dependencies, it is tightly coupled to each of them, which means that a change in one of the dependencies will likely require a change in the package too.
• Applying the Common Closure principle to a package means reducing the number of reasons for a package to change.
  • Removing dependencies, or deferring them to other packages, is one way to accomplish this.