Understading Refactorings

Transcription

1 Understading Refactorings Ricardo Terra Marco Túlio Valente UFMG, 2010 UFMG, 2010 Understanding Refactorings 1 / 36

2 Agenda 1 Overview 2 Refactoring 3 Final Considerations UFMG, 2010 Understanding Refactorings 2 / 36

3 Overview UFMG, 2010 Understanding Refactorings 3 / 36

4 Overview What is it? Refactoring is the process of changing a computer program s source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software Advantages: code readability reduced complexity to improve maintainability more expressive internal architecture or object model to improve extensibility UFMG, 2010 Understanding Refactorings 4 / 36

5 Overview What is it? By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you ll find that it is easier to extend and maintain code. Joshua Kerievsky, Refactoring to Patterns UFMG, 2010 Understanding Refactorings 5 / 36

6 Overview History of Use In the past, refactoring was not a common practice in development processes For example, CVS (created in 1984) does not version the moving or renaming of files and directories Nowadays, refactoring is one fundamental technique adopted in agile methodologies extreme Programming, Scrum, etc UFMG, 2010 Understanding Refactorings 6 / 36

7 Overview When do I use? Bad smells! A structure in the code suggests, and sometimes even scream for, opportunities for refactoring This humorous advice rely on the experience of programmers and on the clarity of code Indications to possible bad smells: Duplicated code (share one same method) Long method (extract one or more smaller methods) Large class (divide in more cohesive classes) Long parameter list (encapsulate them)... UFMG, 2010 Understanding Refactorings 7 / 36

8 Refactoring UFMG, 2010 Understanding Refactorings 8 / 36

9 Refactoring There is a almost a hundred catalogued refactorings each one has a name, a motivation, and a mechanics They are usually organized into the following groups: Composing Methods Moving Features Between Objects Organizing Data Simplifying Conditional Expressions Making Method Calls Simpler Dealing with Generalization Big Refactorings UFMG, 2010 Understanding Refactorings 9 / 36

10 Refactoring In this section, we will explain some refactorings and show an example of its usage We have chosen the popular refactorings, more specifically, refactorings that Eclipse IDE has already automated: Extract Method Pull Up Method Move Method Extract Superclass Introduce Parameter Object UFMG, 2010 Understanding Refactorings 10 / 36

11 Refactoring #1 Extract Method You have a code fragment that can be grouped together Turn the fragment into a method whose name explains the purpose of the method UFMG, 2010 Understanding Refactorings 11 / 36

12 Refactoring #1 Extract Method Theoretical Example 1 void printowing ( double amount) { 2 printbanner ( ) ; 3 4 // p r i n t d e t a i l s 5 System. out. p r i n t l n ( "name: " + t h i s.name) ; 6 System. out. p r i n t l n ( "amount : " + amount ) ; 7 } 1 void printowing ( double amount) { 2 printbanner ( ) ; 3 p r i n t D e t a i l s (amount ) ; 4 } 5 6 void p r i n t D e t a i l s ( double amount) { 7 System. out. p r i n t l n ( "name: " + t h i s.name) ; 8 System. out. p r i n t l n ( "amount : " + amount ) ; 9 } UFMG, 2010 Understanding Refactorings 12 / 36

13 Refactoring #1 Extract Method Motivation It is one of the most common refactorings Long methods or look at code that needs a comment to understand its purpose So, I turn that fragment of code into its own method. Reasons to do that: Increases the chances that other methods can use a method when the method is fine-grained Allows the higher-level methods to read more like a series of comments Overriding also is easier UFMG, 2010 Understanding Refactorings 13 / 36

14 Refactoring #1 Extract Method Practice UFMG, 2010 Understanding Refactorings 14 / 36

15 Refactoring #2 Pull Up Method You have methods with identical results on subclasses Move them to the superclass UFMG, 2010 Understanding Refactorings 15 / 36

16 Refactoring #2 Pull Up Method Theoretical Example UFMG, 2010 Understanding Refactorings 16 / 36

17 Refactoring #2 Pull Up Method Motivation Eliminating duplicate behavior is important if not, the risk that a change to one not be made to other The easiest case occurs when the method have the same body of course it is not always obvious as that. So, look for the differences and test for safety A special case occurs when you have a subclass method that overrides a superclass method yet does the same thing The most awkward case is when the body of the method may refer to features that are on the subclass but not on the superclass so, possible solutions: generalize methods, create abstract method on superclass, change a method s signature, create a delegating method... UFMG, 2010 Understanding Refactorings 17 / 36

18 Refactoring #2 Pull Up Method Practice UFMG, 2010 Understanding Refactorings 18 / 36

19 Refactoring #3 Move Method A method is, or will be, using or used by more features of another class than the class on which it is defined Create a new method with similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it together UFMG, 2010 Understanding Refactorings 19 / 36

20 Refactoring #3 Move Method Theoretical Example UFMG, 2010 Understanding Refactorings 20 / 36

21 Refactoring #3 Move Method Motivation Moving methods is the bread and butter of refactoring classes with too much behavior classes are collaborating too much and are too highly coupled By moving methods around: make classes simpler classes end up being a more crisp implementation of a set of responsibilities UFMG, 2010 Understanding Refactorings 21 / 36

22 Refactoring #3 Move Method Practice UFMG, 2010 Understanding Refactorings 22 / 36

23 Refactoring #4 Extract Superclass You have two classes with similar features Create a superclass and move the common features to the superclass UFMG, 2010 Understanding Refactorings 23 / 36

24 Refactoring #4 Extract Superclass Theoretical Example UFMG, 2010 Understanding Refactorings 24 / 36

25 Refactoring #4 Extract Superclass Motivation Duplicate code is one of the principal bad things in systems One form of duplicate code is two classes that do similar things in the same way or similar things in different ways Even OO providing inheritance, you often do not notice the commonalities until you have created some classes, in which case you need to create the inheritance structure later UFMG, 2010 Understanding Refactorings 25 / 36

26 Refactoring #4 Extract Superclass Practice UFMG, 2010 Understanding Refactorings 26 / 36

27 Refactoring #5 Introduce Parameter Object You have a group of parameters that naturally go together Replace them with an object UFMG, 2010 Understanding Refactorings 27 / 36

28 Refactoring #5 Introduce Parameter Object Theoretical Example UFMG, 2010 Understanding Refactorings 28 / 36

29 Refactoring #5 Introduce Parameter Object Motivation Often you see a particular group of parameters that tend to be passed together It is worthwhile to turn these parameters into objects just to group the data together This refactoring is useful because it reduces the size of the parameter lists, and long parameter list are hard to understand Deeper, when you do this refactoring, you can see common manipulations of the parameter values. By moving this behavior into the new object, you can remove a lot of duplicated code UFMG, 2010 Understanding Refactorings 29 / 36

30 Refactoring #5 Introduce Parameter Object Practice UFMG, 2010 Understanding Refactorings 30 / 36

31 Final Considerations UFMG, 2010 Understanding Refactorings 31 / 36

32 Final Considerations Why should I refactor? Improves the design of software sometimes the code loses its structure (changes). Loss of the structure has a cumulative effect. Regular refactorings helps code retain its shape Makes software easier to understand when you refactor, your code is more readable, i.e., make the code better communicate its purpose Helps you find bugs when you refactor, you work deeply on understanding what the code does, and put that new understanding right back into the code helps you program faster this sounds counterintuitive. But, good design allows rapid development. Without a good design, you spend time finding and fixing bugs instead of adding new functions UFMG, 2010 Understanding Refactorings 32 / 36

33 Final Considerations Refactoring vs Performance Optimization Like refactoring, performance optimization does not usually change the behavior of a component (other that its speed); it only alters the internal structure. However, the purpose is different Refactoring: to make the software easier to understand and modify Performance Optimization: often makes code harder to understand and modify but you need to do it to get the performance you need UFMG, 2010 Understanding Refactorings 33 / 36

34 Final Considerations When should I refactor? Refactoring if something you do all the time in little bursts. You don t decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing. Martin Fowler, Refactoring: Improving the Design of Existing Code UFMG, 2010 Understanding Refactorings 34 / 36

35 References Martin Fowler et al. Refactoring: Improving the Design of Existing Code. Addison Wesley, Joshua Kerievsky. Refactoring to Patterns. Addison Wesley, UFMG, 2010 Understanding Refactorings 35 / 36

36 Thanks a lot!!! UFMG, 2010 Understanding Refactorings 36 / 36