S of S.O.L.I.D. or Single Responsibility Principle

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 eternal part 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.

And if you have any thoughts on these points, then do share them.

Happy Coding…!!!

About Jasminder

.Net developer and blogger by profession, keen to learn new technologies, love nature, music and cricket.
This entry was posted in SOLID Principles and tagged . Bookmark the permalink.

I have a suggestion..

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s