A class should have only one reason to change.
This principle states that if we have 2 reasons to change for a class, we have to split the functionality into two classes. Each class will handle only one responsibility and if in the future we need to make one change we are going to make it in the class which handles it.
If there are two different reasons to change, it is conceivable that two different teams may work on the same code for two different reasons. Each will have to deploy its solution, which in the case of a compiled language (like C++, C# or Java), may lead to incompatible modules with other teams or other parts of the application.
This principle is closely related to the concepts of coupling and cohesion. Coupling refers to how inextricably linked different aspects of an application are, while cohesion refers to how closely related the contents of a particular class or package may be. All of the contents of a single class are tightly coupled together, since the class itself is a single unit that must either be entirely used or not at all.