This is a long awaited return to my TDD “series” that I started in 2005 with 1, 0, 0 in x seconds . In that post I talked about the development loop of test driven development, or the red -> green -> refactor method. I still strive for this today. But it’s gotten quite complex. This post will look at another aspect of good clean architecture by talking about SRP.
What is SRP?
I’m finishing up reading a book called Clean Architecture by Uncle Bob Martin. It is in this book that he explains the SOLID principals that so many of us attach so much meaning to day in and day out of programming. In particular it’s the S in SOLID or the Single Responsibility Principal (SRP) that I’d like to write about here today.
You see for a long time I thought that the SRP means that a function has one job to do and that’s it. I see this everywhere from blog posts to memes about programming. However, I don’t think SRP means what we think it means. Uncle Bob goes a long way in Clean Architecture to describe that SRP means that a function should have only one reason to change, not one thing to do.
What does that mean?
Well, to me it sounds like he is saying that if you look at the actors that would be cause for change of a function there should be only one (Highlander quote). Meaning that if a function represents a change to a model and that both finance and customer support rely on that function, then it is violating the SRP. The function should only exist for either finance or customer support but not both (it’s an XOR). You would need two functions in this case, one for Finance and one for Customer Support. That’s just an example, but a lot of people get this wrong. Duplication of code is okay in these scenarios.
Why do I bring all of this up?
I recently read a blog post called Stop Making a Mock
The author goes on to say this:
This principle leads you to create small classes, each with their own little responsibility. This means we’re breaking up the functional problem we’re trying to solve and splitting it into smaller classes.
Again, what’s wrong with small classes that have their own responsibility? It makes them more testable, and in the future when requirements change you don’t have to change half the system to accommodate. Yes we are breaking up the functional problem into smaller classes to help us program the thing. It’s called engineering. You wouldn’t want a monolithic single class app would you?
In the end…
By the end of the article I’m not sure where the author is going. He is saying that Uncle Bob’s SOLID principals are bad. Then using incorrect ideas of what SRP stands for to prove it. Code is not meant for the person coding the system right now, it is for the unfortunate soul that has to maintain the system next.
In my illustrious career I’ve had the misfortune of working with 10x Engineers that think they can do everything from code and read in minified JavaScript to write Functional Programs that can do everything in a single line of code. That engineer is never the one that has to maintain the mountain of spaghetti. They don’t hire 10x Engineers for that job, and frankly they shouldn’t hire 10x Engineers for any job.
Our job is to make our own lives easier. Following SOLID principals and SRP in particular helps us do that by compartmentalizing where the changes can possibly happen. Small, focused classes are good because we don’t have to recompile the whole system just because finance wants negative numbers to be red and in parenthesis. Customer support doesn’t care about that. And the poor Ops person that has to deploy it would be thankful if they only had to replace a single DLL/Jar/gem file.
This has been a bit of a rant, and I’m sorry for that. I’m really not picking on the author, I just have a different opinion. Let me know what you think. Tweet me @spatacoli .
