SOLID Design Principles. Single Responsibility Principle

If you are reading this article, at least my initial goal is achieved and I got one stranger who I virtually can talk to throughout next several minutes.

Solid, I mean S O L I D(just spell it:). If you are involved with computer science, probably the very first thing that comes to your mind after hearing this word is some kind of “structure”, a “rule” or if u are a bit more advanced u may think of some kind of design principles that were introduced by the guy called Robert C. Martin a.k.a Uncle Bob(Don’t confuse names with 2 different people, like I did in the beginning of my journey to CS world:))).

To understand the exact idea of design principles, first we have to dig deeper into metaphysical understanding of human mind, and investigate quantum nature of the universe. Theory of special relativity states ………………………Come on. Who cares about this stuff here. That’s definitely out of the scope of our topic. Let’s get back to earth.

Single Responsibility Principle aka SRP, aka the first letter in SOLID. As the name suggests itself, we are dealing with some kind of separation or partitioning of our program. One of the most common problems in software development is extreme coupling of software components. The moment when you discover, that after adding a single button on the UI, your program may crash for some other reason. It’s like bringing your car to service for seat belt issue. And next day when you get back the “Fixed” car discover engine problems. Here comes the definition of SRP[1]:

A module/class should have one, and only one reason to change.

There should be no reason of changing a car engine, while fixing seat belt issues. Other wise you will have to revisit car service, this time for engine problem. And who knows which part will be next… Let’s get back to the software. What makes a software system to change? Definitely not us, developers. Systems are changed to satisfy users and stakeholders requirements’. It’s them, who tell us what to change. They are “the reason to change”. Let’s redefine the definition[1]:

A module/class should be responsible to one, and only one, user or stakeholder.

To understand it better, let’s have a look at an example. You can search for “Employee SRP example” the famous one, but here let me introduce a different case. Take a look at the image below.

Imagine, in your system you have a class “Data”, which has 2 methods. getWebPageData, returning data to display on web-site and getDatabaseData, returning data to be stored into a database. In the company, that uses your software, there are 2 dudes. Bob is responsible for marketing and therefore proper UI of the web-site, whereas Rob is responsible for technical side and therefore properly storing data into the database. Bob’s responsibility covers using getWebPageData method, correspondingly Rob uses getDatabaseData method. One day you receive an email from Rob(the tech guy) stating that after some technical updates, their database no longer supports storing images of current format. He asks to change image format in getDatabaseData method. Of course you immediately accept Rob’s demand. It appears that images are generated from the “getImageData” method. And you just change it’s implementation to return image of new format. Then you proudly deploy the software and get deserved credits from Rob(the tech guy). After brilliant evening, you open your inbox next morning and unfortunately receive a complaint email from Bob(the marketing guy), stating that since last night, the web-site was down. Literally it’s crashed. That’s the moment when you realized the true nature of single responsibility principle.

It appears, that both getWebPageData and getDatabaseData methods, use same getImageData method to get image. While changing implementation of getImageData method to satisfy Rob’s(tech) needs, you accidentally messed up with Bob(marketing). The example shows that it’s extremely bad idea to have several responsibilities able to change same things. In this case Tech and Marketing responsibilities are mixed and a change in the one has a negative effect on the other. This is the violation of Single Responsibility Principle.

By the end of the story, let me show one more thing. This interesting activity is called SRP Analysis[2]. Using SRP analysis, you can test your classes for SRP violation. Note that this may not work for many special cases, then you’ll have to rely on your understanding of SRP as well as your programming experience and skills. For general purposes let’s consider an example, an Automobile class.

As you can see from the image there are different methods in the class. Lets apply SRP analysis to Automobile and check whether it violates or not. For the analysis we will need to write down lines in this format: <The “class name” “method name” itself>. See below image for already completed SRP Analysis for Automobile class.

After writing lines down you can carefully read them out loud. Does what you just said make any sense? If what you’ve just said, does not make any sense that method is probably violating the single responsibility principle. Think of moving those methods to different classes. Just go from multiple responsibility class to several, single responsibility classes. You can have a look at some notes on the image and get the idea better.

[1]: Robert C. Martin — Clean Architecture_ A Craftsman’s Guide to Software Structure and Design-Prentice Hall (2017)

[2]: Brett McLaughlin, Gary Pollice, David West — Head First Object-Oriented Analysis and Design_ A Brain Friendly Guide to OOA&D-O’Reilly Media.