Let's now see a related refactoring, which is the
decompose conditional refactoring. What happens here is that in some
cases, the complexity of the conditional logic in a program
can make a method hard to read and understand. Specifically
we might have one or more particularly complex conditional
statements. And similar to what we discussed for the previous
refactoring, the conditional, if it's too complex, might tell you
what happens, but obscure why it happens. To address this
issue, you can do a similar thing to what we did in
the previous refactoring. You can transform the condition into a method and then
replace the condition with a call to that method. And if you give
the right name to the method, as we saw in the last example,
that can make the code much clearer and much easier to understand. In
addition here you can also do something else. Let's assume that those are
the then and else part of the conditional are complex. We can do
the same thing with them. So what we can do, we can modify
the then and else part of the conditional by extracting the corresponding
code, making also that one into a method, suitably naming the method,
and then having the call to the method only in the then
and else part of the conditional statement. So let's see how that works
with an example. Here we have the matter that computes some charge.
And it computes the charge based on some corrective uses of the date
that is provided as input, or it's imagined or is just, you
know, one of the fields in the class. So as you can see,
there is a conditional here that checks that if the
dates is before the beginning of the summer, so before summer
start. Or it's after the summer end. Then it compute
the charge using some winterRate. Otherwise, if we are in the
summer, it will compute the quantity, the charge using a
summerRate. And this is just a small example, so it might
not look that complex. But, you know, just project this on
more realistic code, on larger code. You can end up with
the conditions that are hard to understand. And even in this case, even
such a small piece of code, you have to kind of look at
the conditionals, figure out what does it mean for the date to be
before the summer start and after the summer end. We can make this much
clearer. So, how can we do it? By applying this refactoring as we
described. Let's see what happens when
I apply the decompose conditionals refactoring to
this method. The first thing I will do is to take this condition,
create a method that perform exactly the same check, give it a meaningful name.
In this case I called it notSummer, which is pretty self-explanatory, and then
replacing the condition with a call to that matter. As you can see
here, there's a clear improvement in the code, because here I just need
to look at this statement and I see right away that the check. What
the check is doing is just checking whether the date is in the
summer or not. So, much easier than having to interpret this condition. And
the second thing I do is to take the code that computes the
charge and also in this case, creating
suitable methods that compute the winterCharge and
the summerCharge. And I called them exactly winterCharge and summerCharge which
again is self explanatory. And then I replace this computation with
a call to that method. So again, when I look at
this code, I can clearly see that the charge is computed
using some sort of winterCharge calculation and then using some sort
of summerCharge calculation. And if I don't want to know how
this is exactly computed, that's all I need to know to
understand what this method does. Easier and faster than looking at
this method and figuring out what it does. And if
I need to look at the details, exactly like in the
previous case, I can just go and look at the
implementation of winterCharge and summerCharge. But I will be looking at
that in its specific context. So, without having to understand
everything at once. So in this way, you make it clear
both why you're doing something, because it is notSummer, and
what exactly you're doing. You're computing a winterCharge, or a summerCharge.