#Single responsibility principle functions code#
I say that because I find an implication that by breaking up code into individual responsibilities, the resulting code should be better - more solid and stable, easier to read and understand - than it would have been if responsibilities were combined. However, there's a tradeoff in that by taking this approach, you're likely to introduce more dependencies to any given piece of code, which can also increase complexity.īecause the idea is for code to stay focused on one thing, I often describe this principle as a chunk of code should do one thing and do it well. It's often easier for a new developer to jump into the code and understand what the code is doing.By keeping functions and responsibilities separated, it increases the stability of the other parts within the larger system. In other words, a class should focus only on one logical function. It also says that the class should only have one reason to change. It states that every method, class, or module should have one and only one responsibility. If multiple responsibilities are combined and one needs to change, it's more likely to break other responsibilities. The single responsibility principle (SRP) is a rule of thumb that can help you answer this question.It's easier to test code that has a primary purpose, making it more likely to be solid and stable.a class, function, module, plugin - should do one thing. It means that, in programming, everything - e.g. That's all from me today.The single-responsibility principle is somewhat self-explanatory. So for the sake of your code and for the sake of other coders learn the principle, love the principle, and live the principle. If the code is compartmentalized you can look where is necessary and tackle the problem at its root. We don't read every single line in the code cause a lot of it isn't immediately relevant to what we're trying to address. Would you prefer to see a wall of text in that single function? No of course not. Lastly, imagine working on a team or in a pair programming session and someone asks you to check out their function and maybe help them troubleshoot it. Chances are you can use one of those pieces you created in a future function and won't have to rewrite it again and again.
It's okay to build your function out and make sure you're able to reach the end result you need but it's best from that point to take a look at your code and break it down its base units and separate them into their own individual functions. You might be asking "Well how do I know what building blocks I would be needing until I know what the tools are?", and that's where refactoring comes in.
As opposed to just creating the tool to get the job done create the building blocks that allow you to build whatever tools are needed for the job. At that point your writing the same code inside multiple functions when you could just break each thing down to it's base functionality and piece them together for what you need. As you write out more and more functions and features on your application or web-page you'll find that a lot of them do very similar things if not the same thing with different pieces of data. You can then just grab the one attachment and fix that part specifically as it's what's causing the problem without it affecting the machine as a whole.Īnother reason to apply the SRP to your coding practices moving forward is because of another core coding tenet, keep your code DRY. You have a machine with many attachable parts that each have their own functionality and one of them breaks. The only way to fix it is to tear the whole machine apart and fix it but once your done another function of the machine is now not working. You have a machine that accomplishes many things but it stops being able to do one of the things. One thing you will hear repeatedly in coding culture is that you can spot bad code when you see a function handling too many things. Now that applies to good coding because not only does it add possible reusability and versatility to your code base but it also cleans it up and makes it easier to troubleshoot any current and future issues that may appear. It doesn't do this and that, it simply does this, or it simply does that but never both. The Single Responsibility Principle (SRP) is the concept that any single object in object-oriented programing (OOP) should be made for one specific function. SRP means that every function or method in your code has one single responsibility and functions for one specialized role. It's a pretty self descriptive principle but let's talk about what it means and why it applies to writing good code. The job gets done right? Sure, but when it comes down to it, it doesn't just look bad it handles bad. That in turn makes it just as easy to end up with very bulky yet working functions.
When writing code it's easy to get carried away when trying to solve some kind of problem and write line after line of grabbing, manipulating and passing around data. Today we're going to discuss the Single Responsibility Principle(SRP) and how it applies to writing javascript functions.
0 kommentar(er)
