single responsibility principle functions

Single responsibility principle functions software#
Single responsibility principle functions code#

Single responsibility principle functions software#

If you cannot come up with such a name, then alas, let the name as it is now, naming things is one of the toughest tasks in software development -)

To make the different levels of abstraction more transparent, it is often a good a idea to give a function like runTrafficAndCheckIfItPassed a different name, one which summarizes the combined actions under one concise term. Things which may be seen as one operation on a higher level usually consist of lots of single commands, actions and steps on a lower level.

To apply the 'do one thing' metapher correctly, one needs to take different levels of abstraction into account.

Single responsibility principle functions code#

The operational code for those two actions included, however, is in runTraffic and checkIfTrafficPassed, which are two functions for which we can assume they 'do one thing' as well, but on a lower level of abstraction.

Though the name gives a different impression, the function runTrafficAndCheckIfItPassed does only 'one thing' in the 'clean code sense': it coordinates the calls to two other functions. HasAllTrafficPassed=checkIfTrafficPassed(trafficResults) Here's how I used it: runTrafficAndCheckIfItPassed(TCPTraffic): So do you have any examples or tips why it is considered wrong? Why wouldn't it be right to call the runTrafficAndCheckIfItPassed function and why is it way better to call the functions inside separately?Īs far as I see, if there will be a change in the runTraffic function, for example to receive another parameter, the change will be implemented in one place, only in runTrafficAndCheckIfItPassed, which we see will be easy to maintain.īut if I will use the functions separately I will need to change it in any place. sometimes I need to check that traffic has failed, and sometimes I need to check if it passed. Now let's say that in my software I need to run traffic and to check it's result in a lot of places in my software. Let's say I have a method called runTrafficAndCheckIfItPassed and it calls two methods inside of it: runTraffic and checkIfTrafficPassed. Now, I would like to understand how is it now possible to reuse a code that does multiple things. Martin) talks about a single responsibility that a function should have in a program. The original version can be found here.I've just read the book called Clean Code. This work is a derivative of 'Single-responsibility principle' by multiple authors, originally licensed under CC BY SA 3.0. Continuing with the foregoing example, if there is a change to the report compilation process, there is a greater danger that the printing code will break if it is part of the same class. The reason it is important to keep a class focused on a single concern is that it makes the class more robust. It would be a bad design to couple two things that change for different reasons at different times. The single-responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should, therefore, be in separate classes or modules. These two things change for different causes. Second, the format of the report could change. First, the content of the report could change. Imagine such a module can be changed for two reasons. rewritten).Īs an example, consider a module that compiles and prints a report. Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to be changed (e.g. Martin described it as being based on the principle of cohesion, as described by Tom DeMarco in his book 'Structured Analysis and System Specification' and Meilir Page-Jones in 'The Practical Guide to Structured Systems Design' In 2014 Martin wrote a blog post entitled The Single Responsibility Principle with a goal to clarify what was meant by the phrase 'reason for change.' Example Martin in an article by the same name as part of his 'Principles of Object Oriented Design' made popular by his 2003 book 'Agile Software Development, Principles, Patterns, and Practices'. Hence, each module should be responsible for each role. For example, while they might be the same person, the role of an accountant is different from a database administrator. In some of his talks, he also argues that the principle is, in particular, about roles or actors. Martin, the originator of the term, expresses the principle as, 'A class should have only one reason to change,' although, because of confusion around the word 'reason' he also stated 'This principle is about people.' All of that module, class or function's services should be narrowly aligned with that responsibility. From absolutely messy functions that do scary things to simple callable objects with dependency injection that respect Single Responsibility Principle. The single-responsibility principle is a computer-programming principle that states that every module, class or function in a computer program should have responsibility over a single part of that program's functionality, and it should encapsulate that part.