The first example I want to mention is this called duplicated
code. So what happens here what the symptom is, is that you
have the same piece of code. The same fragment of code or
code structure replicated in more than one place. And that's pretty common
when we do for example copy and paste programming. Is something
that we mention at the beginning of the lessons. So for example
we are just instead reimplementing a piece of functionality we know we
already have. We simply copy from a different part of the code.
So what do you do if you have duplicated code? This can
be a problem over time because we might end up with a lot
of duplication in your system. You can use the extract method. Refactoring that
we just saw, and basically create a method that has exactly the same
function as this fragment of code and then replace the fragment of code
with an invocation to run and you will do it in all the
places where the code is duplicated. That simply finds the code and favors
reuse, because there can be more
places that benefit from that additional method.
Especially if it implements some popular piece of functionality. Another example
of best mal a typical one is the long method. So you
have a very long method with a lot of statements. And we
know that the longer procedure, the more difficult it is to understand
it and maintain it. So what I'm going to do in this
case is to factor in such as an extract method or a
decompose conditional to make the code simpler, shorten it. And extract some
of the functionality into other methods. So basically break down the method
in smaller methods that are more cohesive. Another typical example
of best mail which is something that can happen very
commonly during maintenance, is that you keep adding functionality to
a class and you end up with a large class. So
class is clearly to big. It contains too many fields
too many methods, and is just too complex to understand. This
case the obvious solution is to use the extract class
or subclass and basically break down the class in multiple classes.
Each one with a more cohesive piece of functionality. So, the
classes are more cohesive, are more
understandable, and the overall structure The
structure of the system is improved. Shotgun surgery is an interesting smell
and the case here is we are in a situation and you,
probably will happen to you, it definitely happened to me, in
which every time you make some kind of change to the system
you have to make many little changes. All over the place to
many different classes. And this can be a symptom of the fact
that the functionality is spread among these different classes. So
there's too much coupling between the classes and too little
cohesion within the classes. Also in this case you can
use refactoring, for example by using the move method or move
field or inline class to bring the pieces of related
functionality together. So that your resulting classes are more cohesive, you
reduce the dependencies between the different classes, and you address
this problem. Because at this point, each class is much more
self-contained and therefore it can be
modified by itself without having to affect
the rest of the system. The last smell I want to mention is
one I really like, is the feature envy, and it refers to a
method that seems more interested In a class other than the one it
belongs to. So for example this method is using a lot of public
fields of another class, is calling a lot of methods of the other
class. And so in this case the solution is really clear. What you
want to do it to perform the extract method refactoring and then the move
method refactoring so as to take the jealous
method out of the class where it doesn't
belong and get it home. To the class where it really belongs and once more the
effect of this is that you decrease the
coupling between the two classes and therefore you
have a better system and also you eliminate
the envy. Which is always a good thing.