From 8a7dfa0972c83fd811a4296e7373574bea4a28d0 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 19 Jul 2020 20:34:40 +0700 Subject: [usth/ICT2.7] Remove Udacity transcribes --- ...1 - Decompose Conditionals - lang_en-us_vs2.srt | 263 --------------------- 1 file changed, 263 deletions(-) delete mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt (limited to 'usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt') 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 deleted file mode 100644 index ef89eb8..0000000 --- a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt +++ /dev/null @@ -1,263 +0,0 @@ -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. -- cgit 1.4.1