Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I designed a function which, afterwards, I noticed it is clearly doing 2 very different tasks in the same time.
So now I am thinking to split it into 2 different functions, each one of them doing only what it should do (SRP). Obviously, one of these functions will call to the services of the other one.
But I wonder if this is really a good decision because I tend to think this call increases tight coupling as per this (?)
So my question is: does SRP increase tight coupling?
There's a lot of confusion out there about SRP. Here an article of Uncle Bob, who "invented" SRP, that explains it much better than I could. In short:
SRP is not about what the class does (the responsibility of the class). So it doesn't force you to break down classes into tightly coupled twins just because they would perform several things.
SRP is about the reason to change (the responsibility for the class). It encourages encapsulation and facilitates the principle of least knowledge, which combined should lead to less coupling.
Is his book Clean Code, Uncle Bob recommend that functions inside a class or a module "Do one thing". It may sound like SRP but is something very different. Together with "Keep it small", and "One level of abstraction per function", it promotes a proper functional decomposition into smaller parts that are easier to understand and maintain.
Of course, a function will depend on the sub-functions that were created to decompose it. Inside the same class, coupling is unavoidable. But this is not a problem as long as you don't expose these internal details to the outside world.
One of the key benefits of low coupling is that it reduces the number of things you need to consider simultaneously to understand a single component of a system -- allowing among other things for easier debugging, easier maintenance, and better extendability. A reasonable way to answer your question is to consider whether or not SRP would improve your code with respect to these metrics.
My claim is that SRP has the ability to reduce coupling, but that reduced coupling is not guaranteed. I'll illustrate this with two scenarios.
foo().foo() violates SRP, so re-factor it into bar() and baz().bar() and baz().foo() needs a modification. Most of the logic in foo() is implemented in bar() and baz(), so to change behavior in foo() we change the behavior in bar() and baz() instead.Even though SRP has the ability to reduce coupling (at least I'm claiming it does), in this example the programmer is treating foo(), bar(), and baz() as a single unit AND they have the additional complexity of that unit being split between multiple function definitions and maybe even multiple files. The SRP was in name only and had no real benefits because of how the functions were being used.
foo().foo() violates SRP, so re-factor into bar() and baz().bar() and baz().foo() needs a modification, but we don't have an appropriate low-level component lying around with the desired functionality, so we make a new function bizz().foo() consists of bar() and bizz(), and everything else still works fine.In this example, it is easy to reason about the behavior of foo() because we're treating its two constituent parts as atomic. They have a well-defined behavior, and combined they make up foo(). When those behaviors are insufficient, we make a new atomic component with the desired functionality. This approach easily leads to code re-use and prevents API-breaking changes. Moreover, all the components are small enough and can be easily reasoned about and proven to be correct.
Extras: Even though SRP can decrease coupling in a sense, if functions are not grouped appropriately it has the potential to have every module in an application depending in some way or another on every other module. Designing the entire system to be loosely coupled is every bit as important as designing functions to be loosely coupled, and for roughly the same reasons.
From any reasonable point of view, the action of extracting of part of function into another function does not cause any harm which can attributed to a coupling. What may be bad is that later somebody reuses the extracted functions without careful consideration is it really the same functionality (as in scenario described in another answer). So you should consider it carefully, and limit usage of the sub-functions, by using the measures provided by your language (private methods etc.)
