Single responsibility principle in object oriented design

Share This Post

In object-oriented programming, there are five basic principles (OOP principles, SOLID) that, properly applied, make the difference between a good and a bad design. The difference between an application that is easy to maintain and one that is not. The difference between a good developer and a bad one. Today I would like to concentrate on the first principle in object oriented design (single responsibility principle) but first let’s mention the 5 solid principles:
  • Single Responsibility Principle
  • Open/Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle


We’re going to start with the first one, the Single Responsibility Principle (SRP) that is defined by Robert C. Martin in his book “Agile Software Development, Principles, Patterns, and Practices”. The principle is actually a very simple concept to explain, however, difficult to implement. As its name suggests, it implies that a class or module must have a unique responsibility. Within the context of the Single Responsibility Principle, responsibility is defined as a reason to change. That is why I consider the phrase of Robert C. Martin as a perfect definition of what is the Single Responsibility Pinciple:

“A class should have only one reason to change.”

By following the single responsibility principle, you make sure that your class or module has high cohesion, which means that your class does not more than what it should do. In short, one unique reason to change. If on the contrary, you build a class with more than one responsibility, what you’re doing is that you’re engaging these responsibilities. This leads to a design that is fragile and difficult to maintain, with all that that entails.
  Notes on DDD Europe conference I - 2018 edition



In this simple example, you can see a rectangle class that has two methods; Area () & Draw ().
  • Area () has the responsibility to return the area of a rectangle
  • Draw () has the responsibility to draw the rectangle itself

In this design, it can be seen that, if there are changes in the GUI, we must modify the Rectangle class, then we are obliged to test again the other application that attacks the same class. The solution to this problem is to divide the class in two, so that each class has a unique responsibility. One will be responsible for calculating and another one for painting:

single responsibility principle

It’s important to keep in mind that this principle leads to many other nuances and concepts, and not only those that fall within SOLID, but others that should be known and able to apply to to get an application with a solid design.


  1. Williamki

    wow, awesome article. Really looking forward to read more.

  2. Dudi

    Thank you !

  3. Tom Miriam

    Tom Miriam seember
    Computer science education
    1) With the aid of a suitable diagram give two examples that suitable explain the single Responsibility principle (SRP) of OOP
    2) Give two benefits of the SRP in software development.
    Examples of responsibility principle (SRP) of OOP.
    1) Motivation: in this content, a responsibility is considered to be one reason to Change. This principles States that if we have 2 reasons to change for a class, we have to split the functionality in 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 handle it.
    When we need to make a change in a class having more responsibilities the change might affect the other functionality related to the other responsibility of the class.
    The single Responsibility Principle is a sample and intuitive principle, but in practice it is sometimes hard to get it right.
    A class should have only one reason to change. E.G
    Let’s assume we need an object to keep on email message. We are going to use the IEMAIL interface and Email class have 2 responsibilities ( reason to change) one would be the use of the class in some email protocols such as POP3 or IMAP. If other protocol’s must be supported the objects should be serialized in another manner and çode should be added to support new protocols. Another one would be for the content field.even if content is a string maybe we want in the future to support HTML or other for mats. If we keep only one class, each change for a responsibility might affected the other one.
    * Adding a new protocol will create the need to add code for parsing and serializing the content for each type of field
    * Adding a new content type make us to add code for each protocol implemented.
    Example 2
    Single Responsibility principle
    Interface I email £
    Public void setsender (string sender)
    Public void set receiver (stringreceiver)
    Public void set content (I content content)
    Interface content
    Public string get as string// used for serial
    Class Email implements I Email
    Public void set sender (string sender)
    Public void set receiver (string receiver)
    Public void set content (I content content)
    The single Responsibility principle represents a good way of identifying classes Euro the design phase of an application and it reminds you to think of all the ways a class can evolve .
    A separation of responsibilities is done only when the fully picture of how the application should work is well understand.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Subscribe To Our Newsletter

Get updates from our latest tech findings

Have a challenging project?

We Can Work On It Together

apiumhub software development projects barcelona
Secured By miniOrange