From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- .../11 - Decompose Conditionals - lang_en_vs8.srt | 263 +++++++++++++++++++++ 1 file changed, 263 insertions(+) create mode 100644 usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt (limited to 'usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt') diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt new file mode 100644 index 0000000..ef89eb8 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.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. -- cgit 1.4.1