Lets go with the SOLID series from Uncle Bob! Give me a S! Yes, you got it, today we start with the Single Responsibility Principle, what does it says to us? Lets first enunciate it:
There should never be more than one reason for a class to change.
A reason to change, for the SRP, would be the equivalent to a responsibility. What happens if a class has more than a responsibility? These responsibilities would be coupled and dependent upon each other, making that a change in one of them could break the already working code of the other. Lets see it with an example. Imagine that you have a Rectangle class that is being used by two applications at the same time, the first application is a geometrical one, it does geometric computations, whereas the other one is a GUI made to render shapes in an User Interface. Lets say that we need the rectangle to be drawn in a different way, how can we ensure that it’s not going to affect the computational geometry app? With this design we can’t, and a change in the other side will have the same result. This means that this class has two responsibilities, and that we should separate them in two different classes, like Rectangle, RectangleDrawer or GeometricRectangle.