One and Only one reason to Create!

This article is about SRP of the S.O.L.I.D.

SOLID is mnemonic acronym for five design principles Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and the last one is Dependency Inversion Principle.

In object-oriented computer programming, the term SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable.  Wikipedia

SRP stands for Single Responsibility Principle, lets see what Wiki says, "SRP is design principle that states that every module should have responsibility over a part of the functionality provided by the software." pretty straight forward.

Sir Robert C Martin (aka. Uncle Bob) expresses more on the same, He says that "A Class should have one and only one reason to change." which is more detailed and logical explanation.

Argue for Change

We may come with reasons! which might more of the arguments! like "my manager asked me to change it" or "higher management want this feature asap thus i got great reason to change it". Does this sounds familiar to you ? have you entertained such arguments or reasons to change?

If Yes, Its sad to know that, those are not valid reasons to change the design, If you are doing so! its incorrect practice.

I believe

After analysing various references, notes and problem statements related to srp, I could say that...

"There should be one and only one reason to write a class." -Me

This looks quite similar to uncle bob's quotation for the single responsibility principle as end goal is to achieve single responsibility for the module, with above statement I am trying to develop mindset to take care about design principle at the beginning while writing the code rather thinking while changing it.

Class or module developed to address multiple reasons are building blocks of the code smell, which isn't good sign for any application.

Address the Issue

Saying it in more generalised way, there should be one and only one feature provided by the module. what is module ? for object oriented programming module can be class, for the functional programming language module can be function.

In general, a module is blueprint of the feature, its standard independent unit of work.

Reason to change

Responsibility is also being referred as a 'Reason to Change', Now the question is how to identify the responsibilities that a class or a module has? How we can be sure that there is only one reason to change? or while writing a new module, How to be sure that we are creating module per reason? and not mixing multiple responsibilities int single module.

There can be various approaches for the same, one of them could be asking the questions like ... How many things are being done or expected to be done by the class? when we ask this question we will get more generalised answer like "class is processing a csv file".

Looking at this sort and sweet answer it seems like the class is performing only one responsibility which is to process the csv file. that's it.

No, it may not be that simple to identify the responsibilities straightaway! Processing csv file itself may not be a single responsibility, it may involved in various different tasks of selecting the csv file, reading the csv file data, transforming the csv file data, inserting the data to sql table or to creating another file from the process data. We need to think up to granular level feature that a class or module would going to provide.

Each individual granular level activity or feature can be treated as separate responsibility or reason to change and should forged with individual class only.

CSV Processing is big responsibility thus it is not an ideal case to implement in the single class or module to implement it, this should have given a good thought to identify granular level responsibilities like Reading CSV, Writing CSV, Parsing CSV and so on... big responsibility or big reason should always get divided into smaller logical maintainable responsibilities so that feature or class will have one and only one reason to change.

Feel free to share your thoughts regarding your way of thinking about the single responsibility principle.

Happy Learning

Thanks