Single Responsibility Principle: What Exactly Is It

We have all read how a module should have one, and only one, responsibility. Additionally the responsibility is defined as “reason to change”. This is all well and good until we start reasoning (no pun intended) about what constitutes a reason.

If you are a software developer, you may have read about SOLID design principle by Robert C. Martin. The S in this acronym stands for Single Responsibility Principle (SRP). Even if you haven’t heard about these principles, SRP can still come across in day to day programming in various forms, like:

• This class is too long, it’s doing too much.
• This code is very complex to understand.
• Let’s rename this class to a “SomethingManager” for now and refactor this later.

The point is, it’s very obvious for a developer to intuitively recognize when a class is doing too much. Additionally, implementing Single Responsibility Principle isn’t overly difficult. Therefore, it’s a no brainer to apply SRP right from the beginning when defining a class.

So what gives?

What makes Single Responsibility Principle hard for developers to follow is not having a clear definition of a class’s responsibility. It’s not a coding problem, it’s a communication problem. If everyone is on the same page regarding what a class is supposed to, and more importantly not supposed to do, the SRP suddenly becomes a child’s play.

Unless we take time to understand & define what a module’s responsibility is, we cannot ensure that it sticks to that responsibility.

The better your team gets at understanding & defining the responsibilities of a class or for that matter even an entire project, the quicker you can reap the benefits and progress towards a well designed software architecture.

The flip side is true too! Complicated and unclean architectures are usually a result of vaguely defined responsibilities and a lazy approach to setting up context. This, in turn, leads to a lack of understanding, confusion and unintentional bugs, ultimately hampering the team’s productivity and eroding confidence levels.

If you’ve been following till here, the next question that you might ask is:

How can we define the responsibility of a module such that each member in a team clearly understands it?

This is exactly what I will address in my next post. This is not an intentional cliffhanger. Believe me I hate cliffhangers more than I hate the code I wrote 2 days ago. But the answer deserves it’s own post! And frankly, I need to get some sleep now!

🤫 Hint Hint: I already covered some of it in my last article. But the answer is easier than you think, and it’s not documentation!