-The next re-factoring which is also the last one that we'll - -2
-see, extract method is one of the most commonly used re-factoring. As - -3
-it is applicable in many, many situations. The starting point is - -4
-a method that is too long and contains cohesive code fragments, that - -5
-really serve a single very specific purpose. So we start from - -6
-a cohesive code fragment in a large method. What we can do - -7
-in this case, is to create a method using that code fragment. - -8
-And then replacing the code fragment with a call to that method. - -9
-Let's look at this with an example. Here over this method called - -10
-print owing, and what it does, imagine that it does a lot - -11
-of operations here that I'm just not listing, and then it's got - -12
-a set of print statements. That are just printing a lot of details - -13
-about the owing information. And then again, a lot of code after - -14
-that. So what I could do in this case to simplify. The - -15
-method is to transform this set of statements. They are cohesive in - -16
-the sense that they do just one thing, they just print these details - -17
-into a method, and then I had, replace the statements with a - -18
-call to that method. Which is actually something similar to what we did - -19
-as part of some the previous re-factoring's. Here I'm showing the result. - -20
-So here is the method that I extracted. As you can see. It - -21
-contains the code that was previously here. I give you the meaningful - -22
-name, I called it printDetails so it's clear what it does. And now - -23
-the print owning method is simpler. Because I still have the remaining code - -24
-the one I didn't touch. But now this potentially long list of details. - -25
-Of prints, of details is not replaced by a single method code. - -26
-So a gain similar to the previous refactorings that we saw. If - -27
-we just look at the printing method, it's very easy to figure - -28
-out what this part does. Oh, print some details. And once more I - -29
-really want to stress this. If you don't care about how, this - -30
-is implemented and knowing that this print some details is enough. Then - -31
-you're done. You don't need to understand anything more. It's clear, it's - -32
-self explanatory. And if you'll need to look at what print details does, - -33
-you just go and look at print details. And you look at - -34
-it in isolation. So it's easier to understand what this does without having - -35
-to think the rest of the code. So once more the color we - -36
-factor in is just to improve your design, made the code more readable - -37
-Make the code more maintainable. And also keep in mind all of these, - -38
-are kind of small examples. You also always have to think about the - -39
-effect that this can have on larger codebases. It can really improve a - -40
-lot. The understandabililty, and maintainability of - -41
-your code. So in general, it's design. -- cgit 1.4.1