Single Responsibility Principle

Ah yes, the Single Responsibility Principle. From the first two weeks on at Turing School, this concept was drilled into us as new developers. I love this concept dearly because it was the first where I realized programming truly is an art form. Essentially, the idea is that each class and module in a program should focus exclusively on a single task. This can quickly lead us onto a slippery slope of trying to define what a single task is, resulting in a never ending debate. I don’t want to pick up arms, but I do want to pin the idea down a little further before diving into why it matters.

Let’s take the example of a bicycle. It will have two tires, a frame, a seat, a pair of handlebars, maybe even a light. Each of these components combined makes up the bike as a whole. The bike can be thought of as a complete working application, with the parts being separate classes broken out into separate files, with objects passing information between one-another. Besides maybe being more tidy, how does this help us though? Now let’s imagine that bike comes mass produced as a single unit on an assembly line. This assembly line works fantastic, until one day our customers ask that we add a new feature to the bike. Now they want to have a horn attached to the handlebars. Well since the bike is produced as a single unit, we need to go back and redesign part of the assembly line to take care of this issue. OK! We did that! It was super painful, cost lots of money and time, but now our customers are happy again… A few weeks go by and now they’re asking for another new feature! This is too painful, we’d be better off just starting from scratch with a new assembly line than to try and accommodate for a new feature.

This is an extreme example of what it’s like to work with brittle code — i.e. code that is very difficult to change once we have it working to do a specific task. One of the reasons I love OOP (Object Oriented Programming) is because with some careful thought, we can make it so our code is easy to work with by splitting up responsibility between separate tasks in our applications.

Consider the following example snippet:

Now, without being able to look closely at the code, what general theme do you notice? Everything is broken up into bite sized methods. This Class, called Haiku, makes — you guessed it! — Haikus. What applies to classes and modules also applies to methods. We want each method to have a single responsibility! When writing the first version of this application, I had one giant method that did everything. It was ugly, hard to read, and hard to debug. This current version has a method called ‘build’ that calls another method, which calls another method, thus, splitting up the logic to make it more modular. This in turn serves to make the code easier to work with when we want to change something or a bug shows up because we’ve isolated our application into small chunks of logic.

Let’s go back to the bicycle assembly line. New management has decided to break up each component into its own assembly line, instead of building the whole bicycle on one. This way, as new requirements come in, it doesn’t demand that we supplant the entire assembly line. Rather, we can add and remove features of individual bikes as needed make our assembly design much more modular. This is the essence of single responsibility.

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade