Skip to Content
Today, we will explore about the Single Responsibility Principle.
Definition:
According to Robert C. Martin, Single Responsibility Principle (SRP) by definition is: There would not be more than one reason to change the class. Class would always represent only one responsibility. Here responsibility is the reason tot change the class.
We must not create a single class which has more than one responsibility. If the class has more than one responsibility, than that would be more than one reason to change that class. Classes with more than one responsibility would have a tendency to break more easily than the classes with less responsibility. Whenever, we do the changes in multi responsibility classes, we have to make sure we don’t break the other responsibility of that class – more responsibilities leads to more testing.
Example:

image

We have to develop a simple report to select the data and than display this data as an ALV. If we design only one single class ZCL_REPORT to achieve this requirement, than we are giving more than one responsibility to this class: 1) Data Selection, 2) Output of DATA (ALV). Clearly, there are two reasons which lead to change this class: Change in Data selection (e.g. changing the formula to calculate the net price) and change in ALV processing (e.g. adding a provision to display default variant). There is no clear distinction between the attributes which belong to which responsibility and we might change them accidentally. So, we need to test the entire class and make sure we haven’t broken this functionality.
We can avoid this risk by segregating both responsibilities in separate classes: class for data selection ZCL_DATA_SELECT & class for ALV ZCL_OUTPUT_ALV. Since we have different classes, we don’t have to worry about making accidental update in the other classes’ attributes. We can still create a class ZCL_REPORT which uses both data selection ZCL_DATA_SELECT and ALV ZCL_OUTPUT_ALV classes.

image

Dilemma: 

SRP seems to be the simplest principle but it is one of the hardest to get right. Segregating the responsibilities would depend always on the developer. One could still find more than one responsibility in the data selection class ZCL_DATA_SELECT: data selection from DB ZCL_DATA_DB & Data manipulation ZCL_DATA_PROCESS. Class Data selection from DB ZCL_DATA_DB would be still segregated in to more than one responsibility: data selection for each individual sub objects like Class to select material data ZCL_MATERIAL, class to select Customer data ZCL_CUSTOMER etc. We need to find the optimal segregation of the responsibilities between our classes.
To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Prince JOSHI

    Hi Naimesh,

    I just found this blog which was posted long back.

    After seeing your above example where you said instead of creating single class for:

    1) Data Selection &

    2) Output of DATA (ALV)

    It is better to Segregate them into 2 different class to perform the specific functionality.

    But in practical scenarios, Do we really need to Segregate the class to this level?

    I mean if the logic is as below:

    1. To fetch some data and process it(calculations or etc..)
    2. To update some table(or use BAPI’s for update )
    3. To generate spool output.

    If we go as per your blog then we have to create 3 classes.

    Shouldn’t that be irrelevant to create 3 classes, if we can perform the task in same class using 3 methods.

    I completely agree that we should Segregate the classes if they meant to different context or the logic is vast then we should do it for better readability.

     

    Could you please explain?

     

    Regards,

    Prince

    (0) 

Leave a Reply