about summary refs log tree commit diff
path: root/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt
blob: b26a6982db77516b075371db69d762dfe28dc050 (plain) (blame)
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,100 --> 00:00:03,080
The first example I want to mention is this called duplicated

2
00:00:03,080 --> 00:00:06,950
code. So what happens here what the symptom is, is that you

3
00:00:06,950 --> 00:00:10,400
have the same piece of code. The same fragment of code or

4
00:00:10,400 --> 00:00:14,570
code structure replicated in more than one place. And that's pretty common

5
00:00:14,570 --> 00:00:16,880
when we do for example copy and paste programming. Is something

6
00:00:16,880 --> 00:00:19,730
that we mention at the beginning of the lessons. So for example

7
00:00:19,730 --> 00:00:22,780
we are just instead reimplementing a piece of functionality we know we

8
00:00:22,780 --> 00:00:25,510
already have. We simply copy from a different part of the code.

9
00:00:25,510 --> 00:00:27,760
So what do you do if you have duplicated code? This can

10
00:00:27,760 --> 00:00:30,100
be a problem over time because we might end up with a lot

11
00:00:30,100 --> 00:00:34,480
of duplication in your system. You can use the extract method. Refactoring that

12
00:00:34,480 --> 00:00:37,610
we just saw, and basically create a method that has exactly the same

13
00:00:37,610 --> 00:00:40,700
function as this fragment of code and then replace the fragment of code

14
00:00:40,700 --> 00:00:43,030
with an invocation to run and you will do it in all the

15
00:00:43,030 --> 00:00:47,520
places where the code is duplicated. That simply finds the code and favors

16
00:00:47,520 --> 00:00:48,660
reuse, because there can be more

17
00:00:48,660 --> 00:00:51,050
places that benefit from that additional method.

18
00:00:51,050 --> 00:00:54,960
Especially if it implements some popular piece of functionality. Another example

19
00:00:54,960 --> 00:00:57,930
of best mal a typical one is the long method. So you

20
00:00:57,930 --> 00:01:00,530
have a very long method with a lot of statements. And we

21
00:01:00,530 --> 00:01:03,570
know that the longer procedure, the more difficult it is to understand

22
00:01:03,570 --> 00:01:05,650
it and maintain it. So what I'm going to do in this

23
00:01:05,650 --> 00:01:08,690
case is to factor in such as an extract method or a

24
00:01:08,690 --> 00:01:12,900
decompose conditional to make the code simpler, shorten it. And extract some

25
00:01:12,900 --> 00:01:16,450
of the functionality into other methods. So basically break down the method

26
00:01:16,450 --> 00:01:20,180
in smaller methods that are more cohesive. Another typical example

27
00:01:20,180 --> 00:01:22,380
of best mail which is something that can happen very

28
00:01:22,380 --> 00:01:25,720
commonly during maintenance, is that you keep adding functionality to

29
00:01:25,720 --> 00:01:28,470
a class and you end up with a large class. So

30
00:01:28,470 --> 00:01:32,410
class is clearly to big. It contains too many fields

31
00:01:32,410 --> 00:01:35,620
too many methods, and is just too complex to understand. This

32
00:01:35,620 --> 00:01:37,990
case the obvious solution is to use the extract class

33
00:01:37,990 --> 00:01:42,230
or subclass and basically break down the class in multiple classes.

34
00:01:42,230 --> 00:01:45,390
Each one with a more cohesive piece of functionality. So, the

35
00:01:45,390 --> 00:01:46,930
classes are more cohesive, are more

36
00:01:46,930 --> 00:01:48,360
understandable, and the overall structure The

37
00:01:48,360 --> 00:01:52,440
structure of the system is improved. Shotgun surgery is an interesting smell

38
00:01:52,440 --> 00:01:55,980
and the case here is we are in a situation and you,

39
00:01:55,980 --> 00:01:58,270
probably will happen to you, it definitely happened to me, in

40
00:01:58,270 --> 00:02:01,110
which every time you make some kind of change to the system

41
00:02:01,110 --> 00:02:03,850
you have to make many little changes. All over the place to

42
00:02:03,850 --> 00:02:07,280
many different classes. And this can be a symptom of the fact

43
00:02:07,280 --> 00:02:11,080
that the functionality is spread among these different classes. So

44
00:02:11,080 --> 00:02:13,610
there's too much coupling between the classes and too little

45
00:02:13,610 --> 00:02:16,540
cohesion within the classes. Also in this case you can

46
00:02:16,540 --> 00:02:19,540
use refactoring, for example by using the move method or move

47
00:02:19,540 --> 00:02:22,650
field or inline class to bring the pieces of related

48
00:02:22,650 --> 00:02:26,470
functionality together. So that your resulting classes are more cohesive, you

49
00:02:26,470 --> 00:02:29,220
reduce the dependencies between the different classes, and you address

50
00:02:29,220 --> 00:02:32,305
this problem. Because at this point, each class is much more

51
00:02:32,305 --> 00:02:34,020
self-contained and therefore it can be

52
00:02:34,020 --> 00:02:36,100
modified by itself without having to affect

53
00:02:36,100 --> 00:02:38,560
the rest of the system. The last smell I want to mention is

54
00:02:38,560 --> 00:02:42,040
one I really like, is the feature envy, and it refers to a

55
00:02:42,040 --> 00:02:45,340
method that seems more interested In a class other than the one it

56
00:02:45,340 --> 00:02:48,370
belongs to. So for example this method is using a lot of public

57
00:02:48,370 --> 00:02:51,030
fields of another class, is calling a lot of methods of the other

58
00:02:51,030 --> 00:02:53,830
class. And so in this case the solution is really clear. What you

59
00:02:53,830 --> 00:02:57,420
want to do it to perform the extract method refactoring and then the move

60
00:02:57,420 --> 00:02:59,680
method refactoring so as to take the jealous

61
00:02:59,680 --> 00:03:01,210
method out of the class where it doesn't

62
00:03:01,210 --> 00:03:04,770
belong and get it home. To the class where it really belongs and once more the

63
00:03:04,770 --> 00:03:06,790
effect of this is that you decrease the

64
00:03:06,790 --> 00:03:09,990
coupling between the two classes and therefore you

65
00:03:09,990 --> 00:03:11,910
have a better system and also you eliminate

66
00:03:11,910 --> 00:03:13,150
the envy. Which is always a good thing.