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.