This principle is first one of the 5 principles which are defined as an acronym S.O.L.I.D. This principle is further having an acronym called S.R.P. which is Single Responsibility Principle.

The general definition of this principle is

There should never be more than one reason for a class to change.

What this definition actually means is that each class should be given only one responsibility to handle, which is same as what the name of this principle implies. However, it might sound a bit confusing with the generic definition discussed above. So lets try to understand with an example. Consider the following code :

What this code is actually doing that it is saving the record in the database and sending the confirmation email to the users,

So far, so good. You know changes are an eternalpart of a software application. In future, a new requirement arrives that you need to save the data in another table in the SaveUser function, or add another parameter in the SendEmail function, or add any type of logging function in this class. So what you are required to do is, you have to perform more than one change in the same single class, and quite a good amount of chances are that the client code where this is used, will be affected by this change.

This is what is called the violation of the SRP or Single Responsibility principle.

So, to apply this principle, we have to separate the functions into separate classes, so that the email function becomes a common function (and can be used in different situations), and the SaveUser, can be independently used/modified.

So this is just an example of what is is the problem in the code and how we can apply this principle.

Two points that come to my mind from this principle are :

Using this principle does not means that we need to create a class for each and every function we need to perform (of-course practically this is not possible also)

At first, It might seem to violate the FACADE design pattern. This is not the case. Facade design pattern is designed to encapsulate the complex logic of the functionality so that the end user is not required to interact with each and every component individually, to achieve its goal. So, As long as the logic is based on single functionality/base, for all the sub-tasks in the facade implementation, it is not violating the S.R.P. .This is at-least, what i feel.