about summary refs log tree commit diff
path: root/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt
diff options
context:
space:
mode:
Diffstat (limited to 'usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt')
-rw-r--r--usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt263
1 files changed, 0 insertions, 263 deletions
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
deleted file mode 100644
index ef89eb8..0000000
--- a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.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.