The Single Responsibility Principle

This principle is often known as the Single Responsibility Principle or SRP. In short, it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is a class that has methods that deal with business rules, reports, and database:

Good system design means that we separate the system into components that can be independently deployed. Independent deployment means that if we change one component we do not have to redeploy any of the others. However, if Employee is heavily used by many other classes in other components, then every change to Employee is likely to cause the other components to be redeployed; thus negating a major benefit of component design (or SOA if you prefer the more trendy name).

public class Employee {
}
public class EmployeeReporter {
  public String reportHours(Employee e) ...
}
public class EmployeeRepository {
  public void save(Employee e) ...
}

The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.

Careful application of the SRP, separating things that change for different reasons, is one if the keys to creating designs that have an independently deployable component structure.

by Uncle Bob