1 files changed, 263 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt
new file mode 100644
index 0000000..ef89eb8
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt
@@ -0,0 +1,263 @@
+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.