Single Responsibility Principle

“Memorising in childhood is like engraving on a stone while memorising at an old age is like writing on water".


Welcome back fellow software developer, in this topic, I will discuss an important topic for a software developer which is SOLID principles for Object-oriented programming (OOP). What is the relationship between the above quote and SOLID principles? as usual, be patient I am about to tell you.


First of all, let’s define a principle. A principle defines how a particular thing works, and often than not, a principle does not change. In addition, according to the Cambridge dictionary, a principle means a basic idea or rule that explains or controls how something happens or works.


Now since that is out of the way, let us go back in time when you was a kid. Can remember any principle taught to you by your family? don’t you think it’s fascinating how a principle sticks on you from an early age until today? The same thing applies to software development.

In software development, we have principles that you should be aware of, and never forget them!. Knowing such principles, will broaden your knowledge and give you a solid ground when construing a software project. Furthermore, the most known design principles are SOLID

Wait, how come I said five and I mentioned a single word? SOLID is a mnemonic word and each letter represents a single design principle as follows.

  • S – Single Responsibility Principle.

  • O – Open/Closed Principle.

  • L – Liskov Substitution Principle.

  • I – Interface Segregation Principle.

  • D – Dependency Inversion Principle (Side note: I am in love with this)

In this post, I will deep dive into the first principle, and leave the rest for the upcoming post. Therefore, the rest of this post is structured as follows.

  • The definition of the Single Responsibility Principle.

  • Examples in our daily life.

  • Class example.

  • The principle outcome

  • Final thoughts.

The Definition of Single Responsibility Principle

This principle is pretty simple, a class should only be responsible for a single functionality. Keep in mind, I don’t mean a single method, I mean the scope of the methods should be highly related. This gives the class one reason to change only, and the change will only be related to a specific scope in the entire application.

Don’t worry if you didn’t understand, it will get clearer with the examples. 

Examples in our daily life

If we observed our jobs we will notices that each employee has specific tasks. Those tasks are defined within the job description. You are legally compelled to do tasks related to your job description only, and nothing else. Furthermore, another example is your responsibilities at home. Often then not, parents distribute a specific responsibility to each member of the family. For instance, memeber1 responsible for getting the trash out, memeber2 responsible for cleaning the dishes, member3 is still a kid and don’t have responsibilities.

What I am trying to say is that in life, everyone will have specific duties and responsibility that define his overall character. The same thing should be applied to the classes in your application. Let’s go with the technical examples to grasp more understanding. 

Class Example

The above diagram describes a class with the name Calculator having two fields firstNumber and secondNumber. In addition, the class has three methods sum, multiply and printInJsonFormat. 


Observe carefully and try to find what’s wrong in this class. Did you find it? if you did then congratulations, you grasped the first principle by heart. If you didn’t, don’t worry, I will tell you everything you need to know.


The printInJsonFormat method does not share a common responsibility with other methods in the class. To illustrate, the methods sum and multiply are core mathematics functions related to this class. But printInJsonFormat is not. Therefore, will have multiple reasons for change, which are printing functionality as well as the mathematics functions. In addition, it does not make sense to call printInJsonFormat from another class as again it’s not logically related

The Principle Outcome

Following this principle will enhance understanding the aim of the class. In addition, assessing the impact of a change in a class will be much easier. 

Final Thoughts

The single responsibility principle is one of the easiest principles to understand, implement and remember. In addition, it has a huge impact on understanding the objective of the class, as well as increasing the maintainability in the long run.

Side note: as usual do not take anything that I write religiously, as a software developer you should assess the implementation of patterns and principles described in this blog in general.

Support Ideas

If you liked the content and thought of supporting the creator, below are some ideas to do so.

  • your engagement in the comment will help giving more value to the content.
  • spreading the content in social media will help attract more readers and google ranking
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on email
You Can

Buy me a Coffee

  • also consider subscribing to the newsletter list


  1. […] to Design Patterns & Singleton and Single Responsibility Principle (Anwar Al […]

  2. […] Side note: this class is a good example of  Single Responsibility Principle.  […]

  3. […] or returning not implemented exception is a violation of LSP. In addition, we also discussed the Single Responsibility Principle which in short says a class should only be responsible for a scoped […]

Leave a Reply

Physical Address

304 North Cardinal St.
Dorchester Center, MA 02124