The term was introduced by Robert C. Martin and he concludes that a class or module should have one, and only one, reason to change. But how can we apply this principle in the most effective way?

One of the bad examples we can give is putting business rules that are constantly changing inside database models. For instance:

public class Student {
	getGradesReport();
	getAge();
	getName();
	calculateAverage(int year);
	save();
}
  • calculateAverage(int year): calculates the average of all the grades in a specific year. This calculation can change with time, and should be in a difference class.
  • getGradesReport(): generates a report with all the grades. Besides the need of injecting maybe new dependencies in order to generate a report, this report can change a lot of time. That is why it is a good idea to put this in the model. save() is the method used to persist the object in the database. The persistence should be only responsibility of the class.

We want to minimise the number of changes in our project. If we don’t separate the business rules (BRs) of the model, future changes will need a new change in that file.

When we notice that a class has many methods we need to try to divide them in several classes and interfaces in order to isolate future changes in the code.

Bibliography

http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod