Single Responsibility Principle Analogy

The single responsibility principle is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. Source

Maybe that brief explanation of single responsibility will make sense if you are software engineer, but if you not, you will wondering what is class? what is module? what is encapsulated? So let's dive in into SRP using real life easy-to-understand (hopefully ✌️) analogy.

A long time ago in galaxy far, far away... there are an agency that have video editor position, each video editor had raw video footage (which is unedited video), they also can do some behavior for example editing video (obviously).

Video Editor here act as class it's define what video editor had (state) and what video editor do (behavior). John, Kendrick, and Jim here act as a instance, a manifest of video editor.

Now, imagine you are social media admin for this agency, and you need to post video that recorded yesterday. You know that videographer already handed the raw video footage to vide editor, now what you do? ask for the raw video to video editor? or tell them to create social-media-ready video? of course we do the second option, because it's their job. On technical term this is called encapsulated you don't ask them to provide what they had, instead ask them to do their job (behavior).

The next day, your agency hiring a new position for video editor, you don't need to be software engineer to know that this job opening is wrong, why? because the job description is outside the scope of video editor. Single responsibility principle in software engineer also applied the same way with this example. A class (video editor) should have responsible only to behavior (job description) and state that within their scope. So, what the agency should do now? of course separate the job opening into video editor, photo editor, videographer, and it support, for fix AC they should just call AC service 🤣. If we develop software and found similar cases where one class had many responsibilities we should separate them into smaller class.

Conclusion

In above example it's important to separate the responsibility of each position in the agency, if one person had a lot of responsibility it will frustrate them, in software engineer also the same, if you make class to large and had a lot of responsibility it will also frustrate the developer who maintained it.

That's all, Thanks for reading this far ✌️. I'm eager to hear your thoughts about this analogy and single responsibility principle.

3
Subscribe to my newsletter

Read articles from Kadek Dhiva Tiradika directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Kadek Dhiva Tiradika
Kadek Dhiva Tiradika