Most developers have heard of the Single Responsibility Principle (SRP). It is one of the principle pillars of SOLID and frequently touted as a core principle that all developers should strive for when designing their code. It is also one of the least understood principles I’ve ever seen. Most developers will agree that it’s really important, but these same developer will have a hard time defining SRP means in concrete terms. They have an even harder time translating the amorphous concept into their code.
This became painfully clear to me when we had a particularly bright 1 developer create a Rest API Client for our app 2. He was an enthusiastic proponent of SRP and sought to employ the principle in all of his code. Unfortunately, he left soon thereafter for a better job, because to this day, I do not understand what he wrote. His client spanned across 10 different classes and so fully conformed to the SRP principle that no one in our team ever managed to understand how all the pieces came together. Whenever it came to modifying the client to fix a bug or add functionality, that task became one of the few tasks no developer wanted to take up 3. In the end, I recreated the API client as a single class that contained one fifth the original code 4. The experience was eye opening to me. I thought I was a proponent of SRP until he showed exactly how far I hadn’t taken the concept.
Often, complicating a class is simpler than abstracting it out. Except, of course, when it’s not.