1
00:00:00,080 --> 00:00:02,740
Let's now see a related refactoring, which is the

2
00:00:02,740 --> 00:00:06,200
decompose conditional refactoring. What happens here is that in some

3
00:00:06,200 --> 00:00:08,980
cases, the complexity of the conditional logic in a program

4
00:00:08,980 --> 00:00:12,040
can make a method hard to read and understand. Specifically

5
00:00:12,040 --> 00:00:15,760
we might have one or more particularly complex conditional

6
00:00:15,760 --> 00:00:18,580
statements. And similar to what we discussed for the previous

7
00:00:18,580 --> 00:00:21,630
refactoring, the conditional, if it's too complex, might tell you

8
00:00:21,630 --> 00:00:25,170
what happens, but obscure why it happens. To address this

9
00:00:25,170 --> 00:00:27,520
issue, you can do a similar thing to what we did in

10
00:00:27,520 --> 00:00:31,800
the previous refactoring. You can transform the condition into a method and then

11
00:00:31,800 --> 00:00:35,260
replace the condition with a call to that method. And if you give

12
00:00:35,260 --> 00:00:37,930
the right name to the method, as we saw in the last example,

13
00:00:37,930 --> 00:00:41,730
that can make the code much clearer and much easier to understand. In

14
00:00:41,730 --> 00:00:44,360
addition here you can also do something else. Let's assume that those are

15
00:00:44,360 --> 00:00:47,430
the then and else part of the conditional are complex. We can do

16
00:00:47,430 --> 00:00:50,180
the same thing with them. So what we can do, we can modify

17
00:00:50,180 --> 00:00:53,570
the then and else part of the conditional by extracting the corresponding

18
00:00:53,570 --> 00:00:57,070
code, making also that one into a method, suitably naming the method,

19
00:00:57,070 --> 00:00:59,930
and then having the call to the method only in the then

20
00:00:59,930 --> 00:01:03,540
and else part of the conditional statement. So let's see how that works

21
00:01:03,540 --> 00:01:06,940
with an example. Here we have the matter that computes some charge.

22
00:01:06,940 --> 00:01:10,350
And it computes the charge based on some corrective uses of the date

23
00:01:10,350 --> 00:01:12,930
that is provided as input, or it's imagined or is just, you

24
00:01:12,930 --> 00:01:15,410
know, one of the fields in the class. So as you can see,

25
00:01:15,410 --> 00:01:18,140
there is a conditional here that checks that if the

26
00:01:18,140 --> 00:01:21,535
dates is before the beginning of the summer, so before summer

27
00:01:21,535 --> 00:01:25,180
start. Or it's after the summer end. Then it compute

28
00:01:25,180 --> 00:01:29,152
the charge using some winterRate. Otherwise, if we are in the

29
00:01:29,152 --> 00:01:32,288
summer, it will compute the quantity, the charge using a

30
00:01:32,288 --> 00:01:35,440
summerRate. And this is just a small example, so it might

31
00:01:35,440 --> 00:01:37,990
not look that complex. But, you know, just project this on

32
00:01:37,990 --> 00:01:40,458
more realistic code, on larger code. You can end up with

33
00:01:40,458 --> 00:01:43,656
the conditions that are hard to understand. And even in this case, even

34
00:01:43,656 --> 00:01:45,944
such a small piece of code, you have to kind of look at

35
00:01:45,944 --> 00:01:48,752
the conditionals, figure out what does it mean for the date to be

36
00:01:48,752 --> 00:01:51,800
before the summer start and after the summer end. We can make this much

37
00:01:51,800 --> 00:01:54,780
clearer. So, how can we do it? By applying this refactoring as we

38
00:01:54,780 --> 00:01:56,190
described. Let's see what happens when

39
00:01:56,190 --> 00:01:58,380
I apply the decompose conditionals refactoring to

40
00:01:58,380 --> 00:02:01,530
this method. The first thing I will do is to take this condition,

41
00:02:01,530 --> 00:02:05,640
create a method that perform exactly the same check, give it a meaningful name.

42
00:02:05,640 --> 00:02:09,380
In this case I called it notSummer, which is pretty self-explanatory, and then

43
00:02:09,380 --> 00:02:12,340
replacing the condition with a call to that matter. As you can see

44
00:02:12,340 --> 00:02:15,230
here, there's a clear improvement in the code, because here I just need

45
00:02:15,230 --> 00:02:17,810
to look at this statement and I see right away that the check. What

46
00:02:17,810 --> 00:02:20,680
the check is doing is just checking whether the date is in the

47
00:02:20,680 --> 00:02:24,320
summer or not. So, much easier than having to interpret this condition. And

48
00:02:24,320 --> 00:02:26,910
the second thing I do is to take the code that computes the

49
00:02:26,910 --> 00:02:28,600
charge and also in this case, creating

50
00:02:28,600 --> 00:02:31,028
suitable methods that compute the winterCharge and

51
00:02:31,028 --> 00:02:34,838
the summerCharge. And I called them exactly winterCharge and summerCharge which

52
00:02:34,838 --> 00:02:38,278
again is self explanatory. And then I replace this computation with

53
00:02:38,278 --> 00:02:40,710
a call to that method. So again, when I look at

54
00:02:40,710 --> 00:02:43,280
this code, I can clearly see that the charge is computed

55
00:02:43,280 --> 00:02:46,570
using some sort of winterCharge calculation and then using some sort

56
00:02:46,570 --> 00:02:50,490
of summerCharge calculation. And if I don't want to know how

57
00:02:50,490 --> 00:02:52,670
this is exactly computed, that's all I need to know to

58
00:02:52,670 --> 00:02:56,100
understand what this method does. Easier and faster than looking at

59
00:02:56,100 --> 00:02:57,970
this method and figuring out what it does. And if

60
00:02:57,970 --> 00:02:59,950
I need to look at the details, exactly like in the

61
00:02:59,950 --> 00:03:01,550
previous case, I can just go and look at the

62
00:03:01,550 --> 00:03:04,170
implementation of winterCharge and summerCharge. But I will be looking at

63
00:03:04,170 --> 00:03:06,980
that in its specific context. So, without having to understand

64
00:03:06,980 --> 00:03:09,760
everything at once. So in this way, you make it clear

65
00:03:09,760 --> 00:03:12,840
both why you're doing something, because it is notSummer, and

66
00:03:12,840 --> 00:03:16,300
what exactly you're doing. You're computing a winterCharge, or a summerCharge.