If you are a programmer, you may have heard of the SOLID principles. This acronym, among others like TDD, DI, etc. is unfortunately more and more used as buzzwords. It is not rare to hear a candidate quoting the definition of the SOLID principles in a technical interview: single responsibility, dependency inversion… However, the most interesting part may be how to effectively use them everyday.
Robert C. Martin promoted the SOLID principles around 2003. Each letter defines a principle:
- Single Responsibility Principle
- Open Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Knowing the definition of each principle is a good start. Nevertheless, it can be hard to use them without guidelines or techniques. In this series, I will do my best to explain how to apply these principles to your code by following some practices that I have acquired by reading and watching resources authored by famous programmers: Robert C. Martin - of course, Martin Fowler, Kent Beck, etc.
The Single Responsibility Principle, first of the five SOLID principles
Do One Thing and Do It Well
The Single Responsibility Principle states that a class should do one thing, and that it should also do it well.
It is not an easy thing to achieve such a goal. When you look at the source code of many programs, you often see classes as chunks of code that handle multiple purposes. It hides the intent of the class, making the life of programmers harder. You have difficulties to find the code behind use cases and user stories.
Writing code that does not violate the Single Responsibility Principle can be hard to do. One does not simply write methods and classes that have a single purpose in one go. Instead, it is a continuous process that involves many refactoring techniques over the time.
Refactor by extracting methods
Extract Till You Drop - Robert C. Martin
Do not aim for perfection at the first attempt. Start by writing code that works. It’s even better when you write it tests first. This way, you will be able to refactor it with very limited risk of introducing bugs.
The best refactoring technique to use is Extract Method. Take advantage of the features of your IDE. Extract methods out of big methods until they are small enough to do only one thing. How do you know that a method is doing one thing only? Well, if you can split a method in two, then it means that the method was doing at least two things.
Extracting methods can cause side effects. If you use many local variables, then the extracted methods may use them as “in” and maybe “out” parameters. You can avoid this by writing code that is more object-oriented — use private members!
Create new classes that have single responsibility
Now that you have many new small methods, take a step back. Is your class doing one thing? As an example, if your class now has methods that compute things, methods that render strings to be displayed to the user and other methods that communicate with a web server, then your class is doing three different things.
Extracting methods actually helps you see the big picture, identify the different concerns and then extract new classes. You can go even further by grouping new related classes together.
Final words
I wrote some code in my article Caching method results easily with AOP. I will soon publish a thread-safe version that follows the Single Responsibility Principle.
I’m currently using this principle when I write code. However, it is a principle, not a rule. It is not perfect truth. There are extremes. Creating too many methods or too many classes are an extreme. It requires practice.
This article is highly inspired from the work of Robert C. Martin and I highly recommend you study it.
Buy me a coffee