Thanks for this write-up! It's short and sweet.
Can you help me to see why this isn't overkill? As you can probably tell, I currently write my functions like the first example and only refactor if I start to need to reuse code. It's a "Refactor when it's needed" approach. The reason I ask is, i don't feel like I'm presented with enough information to decide when it's broken down too much. Anything can be defined as a single responsibility. This function is supposed to get the percentage of word occurances, that's a single responsibility. But so is grabbing a file from disk and so is converting the file to a string. How does one know where to draw the line?
That's actually a very good question! Breaking down code into functions/classes with single responsibility makes it easy to extend the code when needed as well as debug and modify. So it is a good practice to write smaller functions right from the start so you don't have to suffer when your code gets bigger. So the line is in the question: what does my function/class do? If it is one thing, you are good to go.
Imagine that you want to calculate the percentage of word's occurrences from AWS S3 bucket file instead of a local file. Since the functions are broken down, you just need to write a function that retrieves the content from S3 file (which you can also reuse in other tasks). Next you just combine it with percentage_of_word() function.
If you had it all in one function you would need to modify the code inside the function. But what if you wanted to be able to use both local file and S3? Now you would need an if statement which makes code bulky and slows it down. What if you needed even more content sources? Even more complexity to your function.
The Single Responsibility Principle is actually very connected with the Open/Close Principle which I am going to write next about. The principle says that the code should be open for extension and closed for modification. That is, instead of modifying the existing code it should be rather extended using already existing components and adding what is necessary.
Yes, it's a great point. I would have some if statements in there. My code tends to have a lot of those. I appreciate you writing these in such a short format because it's difficult to understand SOLID as a whole in large chunks
The reality is there is no golden rule that it going to be correct in all cases.
I think the example in this article is something that is manufactured for the purposes of illustration & possibly a bit artificial.
Ultimately, if you can ask the question "what does this function/class do?" and there is one obvious answer you are probably doing ok. It is probably easier to spot a function that is doing too many things rather than one that just does one thing.
Some good indicators of a function that is trying to do too much could be
when a large number of parameters are being passed to the function or
when the function receives a Boolean "flag" as an argument which is designed to modify it's behaviour.
There's a great chapter in "clean code" with lots more information on this topic 👍
Hey, as Uncle Bob said(the creator of SOLID principles) Single responsibility principle is not only about splitting the code to the smallest possible chunks - as in this article - but to split by business domain. There should be only one business/technical/finance etc. reason to change that class.
Here is the link with a good example from SOLID author: blog.cleancoder.com/uncle-bob/2014...
So in my opinion example from this article is not about SRP, but about code splitting.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for this write-up! It's short and sweet.
Can you help me to see why this isn't overkill? As you can probably tell, I currently write my functions like the first example and only refactor if I start to need to reuse code. It's a "Refactor when it's needed" approach. The reason I ask is, i don't feel like I'm presented with enough information to decide when it's broken down too much. Anything can be defined as a single responsibility. This function is supposed to get the percentage of word occurances, that's a single responsibility. But so is grabbing a file from disk and so is converting the file to a string. How does one know where to draw the line?
That's actually a very good question! Breaking down code into functions/classes with single responsibility makes it easy to extend the code when needed as well as debug and modify. So it is a good practice to write smaller functions right from the start so you don't have to suffer when your code gets bigger. So the line is in the question: what does my function/class do? If it is one thing, you are good to go.
Imagine that you want to calculate the percentage of word's occurrences from AWS S3 bucket file instead of a local file. Since the functions are broken down, you just need to write a function that retrieves the content from S3 file (which you can also reuse in other tasks). Next you just combine it with percentage_of_word() function.
If you had it all in one function you would need to modify the code inside the function. But what if you wanted to be able to use both local file and S3? Now you would need an if statement which makes code bulky and slows it down. What if you needed even more content sources? Even more complexity to your function.
The Single Responsibility Principle is actually very connected with the Open/Close Principle which I am going to write next about. The principle says that the code should be open for extension and closed for modification. That is, instead of modifying the existing code it should be rather extended using already existing components and adding what is necessary.
Hope it answers your question!
Yes, it's a great point. I would have some if statements in there. My code tends to have a lot of those. I appreciate you writing these in such a short format because it's difficult to understand SOLID as a whole in large chunks
The reality is there is no golden rule that it going to be correct in all cases.
I think the example in this article is something that is manufactured for the purposes of illustration & possibly a bit artificial.
Ultimately, if you can ask the question "what does this function/class do?" and there is one obvious answer you are probably doing ok. It is probably easier to spot a function that is doing too many things rather than one that just does one thing.
Some good indicators of a function that is trying to do too much could be
when a large number of parameters are being passed to the function or
when the function receives a Boolean "flag" as an argument which is designed to modify it's behaviour.
There's a great chapter in "clean code" with lots more information on this topic 👍
Hey, as Uncle Bob said(the creator of SOLID principles) Single responsibility principle is not only about splitting the code to the smallest possible chunks - as in this article - but to split by business domain. There should be only one business/technical/finance etc. reason to change that class.
Here is the link with a good example from SOLID author: blog.cleancoder.com/uncle-bob/2014...
So in my opinion example from this article is not about SRP, but about code splitting.