Single Responsibility 1/5

In this article I am going to talk about the first letter of the S.O.L.I.D principles, Single responsibility. I am going to release 5 articles in total, in each article I will talk about the principle that letter stands for. Why? Firstly, to improve my own understanding of these concepts. Secondly, to share this so you can learn something too!

About me

My name is Mark van der Steenhoven, a Dutch programmer based in Amsterdam working for the Dutch Postcode lottery. I studied computer science for 4 years and have been working for 3 years as a software developer. I used to work a lot in PHP, Java, and JavaScript. At this point, I primarily program in Javascript and TypeScript on both front-and-backend. Also I love to work with PHP, Java and GoLang!

The SOLID Principles

What are the solid principles? The solid acronym stands for the five most important principles in Object Orientated programming ( OOP ).

• Single responsibility principle.
• Open/Closed principle.
• Liskov substitution principle.
• Interface segregation principle.
• Dependency inversion principle.

The acronym was created by Micheal Feathers for the first five principles that Robert C. Martin described in the early years of 2000. With these principles together it is more likely that a programmer will write code which is more maintainable, extendable and easier to understand.

Single Responsibility

What does single responsibility stand for? Uncle Bob defined this as the following.

‘A class should be responsible for one thing.’

He then later defined it as:

‘A class should only have one reason to change.’

At first glance, the principle sounds straight forward. Yet when I ask the question “what is a change?” the answers differ. One programmer will say; when the code needs refactoring! Another will say, when there is a bug! Yes these are changes, but they do not change the determined business rules. Bug fixes and refactoring are the responsibility of the programmer. So maybe a better question is, who is responsible for changes?

class User {
public calculatePay(): Money {}
public save(): void {}
public reportHours(): string {}
}

Look at the above code sample, uncle Bob used this piece of code to perfectly answer the question who is responsible for changes. This class is now responsible for calculating the pay of a user with some algorithm, reporting hours made and saving the user into a database. An improvement on this class would be to move the save(); method to something like:

class UserRepository {
save(user: User) {
  //Do some database call
}
}

The User class now has one less reason to change. We now clearly separated the procedure to store a user into some database. If the persistence layer of an application changes it would be weird that you would also have to change your business logic, most of the time. Your database is not a part of your business, it is just a place where you store information about the business.

We could do the same for the calculatePay() or reportHours() and create classes like MoneyCalculator and UserHourReporter or something along those lines. After doing this, the User class has only one reason to change. This reason would be if business changes regarding users. Users get new properties like address or registration number because the business needs to give context to this data and user seems like a nice place to do it.

A good way to enforce this principle before you start programming is to ask yourself. “Is and should this class be responsible for this functionality? ” If you ever run into the above example, the answer is simple. Yet sometimes it can be hard to figure out where the responsibility lies. Getting it right takes practice.

To sum up

Thank you for reading! I hope you learned something, I most definitely did.
Next up is the Open/Closed principle where I will explain the following quote/principle as best as I can.

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”