Time and time again we are taught that if you just stick to the single responsibility principle (SRP) you will be fine. Make your methods/functions do one thing and do it well and all will be well in the land. But for all the good intentions, I have never seen a codebase which does not permeate with exceptions to this rule. What if we just can’t do it, what if it’s a just not feasible, not just in software development, but in government and society in general. Maybe that’s ok?
I came across this article from norwegian media. The topic is food waste and what we can do about it. What caught my eye is how 3 different government ministers were involved. The ministers for environment, fishing and consumers clearly all felt a responsibility for this. For some reason this got me thinking about the SRP. How come we need 3 departments to spearhead food waste issues, have they not heard of the SRP!
Fortunately I have the solution: we split things up. First we create a food wastage ministry, with a “no food shall go to waste” minister. We have applied the SRP, the minister will do one job and him/her will do it well. But what about other waste like bottles and plastic? They should not go to waste either. We need recycling. Recycling is currently under the environmental department. That department also deals with oil spillage and other nasty business, clearly a violation of the SRP. So again we apply the SRP, create a separate “recycle bottles, but not food” minister, the minister will do one job and him/her will do it well.
So far so good, we are applying the SRP and designing our “system” well, everyone can see that recycling bottles and stuffs is different than using up your food before little green aliens start growing on them.
We need to continue this strategy, of Norway’s 15 departments, many of them do more than one thing. In fact 9 of 15 departments have names with “and” in them. They readily admit they are doing more than one thing, it is in their name! It is like calling a software class “CustomerAndOrderFactory”. So we split the “and departments” up as well. We now have a more logical 27 departments.
If you run with this you can split things up into near infinity, but you get the picture. Ultimately you would end up with a lot of ministers at the king’s table:
The prime minister might even forget some of the names of her ministers, embarrassing. I am also pretty sure that no matter how far we split things up, there will always be an edge case we can’t logically place in one department over the other.
Similarly we split everything up in software development, smaller pieces are good, I am not going to argue bringing back 300 line functions and enormous classes, but all things have a limit. The SRP tells us a class should have only one reason to change, to make it more robust. I say we can never accomplish this because we come across the same edge cases as the department planners. For instance, say you have a class which is responsible for Yin and Yang. If Yin or Yang changes, the class has reason to change. We therefore create two classes, it would be the “correct” thing to do. But maybe Yin and Yang are just two states of the same entity. Such an entity could be “illumination” with the states “light/dark”.
I don’t think you should follow the SRP to the degree that you separate inseparable things. The world is a complex place, software is a complex place, some things are so related and intertwined that it makes no sense to split them up. You can always identify smaller components, but does it make sense? The SRP is an ideal, it is perhaps the best advice you could give a fellow developer starting out. It helps them create understandable and maintainable code, but leave Yin and Yang alone..