1 files changed, 263 insertions, 0 deletions
diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt
new file mode 100644
index 0000000..b26a698
--- /dev/null
+++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt
@@ -0,0 +1,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.