1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
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.
|
