Refactoring

1. Refactoring

2. Refactoring Overview What is refactoring? What are four good reasons to refactor? When should you refactor? What is a bad smell (relative to refactoring )? Be able to name three bad smells. Be able to name three refactorings.

3. Refactoring • Changing the implementation of current code without changing its functionality • Why? • Improve clarity • Ease the addition of functionality • Remove duplication • What are four good reasons to refactor? • improves the design of software • makes the software easier to understand • helps you find bugs • helps you program faster

4. Bad Smells in Code • Duplicated code: • the same code (essentially) in more than one place, e.g., • same expression in two methods of the same class • same expression in two sibling subclasses • Long parameter list: • passing in lots of parameters to a method (because global data is deemed evil) • difficult to understand • pass only enough so that the method can get to everything it needs

5. Bad Smells in Code • Large class: • a class trying to do too much • e.g., too many instance variables • factor out some related set of variables and methods using Extract Superclass or Extract Subclass • Divergent change: • when one class is commonly changed in different ways for different reasons • no single clear point for where to make changes • probably two (or more) classes are better than one • use Extract Class

6. Sample Refactorings (cont.) • Extract Component • You have one class doing the work that should be done by two—Create a new class and move the relevant fields and methods from the old class into the new class.

7. Bad Smells in Code • Long method: • long, difficult-to-understand methods • want short, well-named methods • need to aggressively decompose methods • can often use Extract Method

8. Sample Refactorings (cont.) • 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.

9. Bad Smells in Code • Shotgun surgery: • the opposite of divergent change • making a change requires many little changes to many different classes • consolidate the changes to a single class • can use Move Method and Move Field • balance with divergent change

10. Sample Refactorings (cont.) • 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 method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether.

11. Bad Smells in Code • Feature envy: • a method seems more interested in a class other than the one it is actually in • e.g., invoking lots of get methods • can use Move Method and Extract Method

12. Bad Smells in Code • Data class: • classes that are all data (manipulated by other classes) • e.g., a Point record that has other classes manipulating its coordinates • in early stages, it’s all right to use public fields • study usage and move behavior into data classes • can use Extract Method, Move Method, Encapsulate Field

13. Sample Refactorings • Self Encapsulate Field • You are accessing a field directly, but the coupling to the field is becoming awkward—Create getting and setting methods for the field and use only those to access the field

14. Bad Smells in Code • Alternative classes with different interfaces: • methods that do the same thing but have different signatures • e.g., put() versus add() • can use Rename Method

15. Sample Refactorings (cont.) • Rename Method • The name of a method does not reveal its purpose—Change the name of the method

16. Sample Refactorings (cont.) • Parameterize Method • Several methods do similar things but with different values contained in the method body—Create one method that uses a parameter for the different values

17. Sample Refactorings • Pull Up Field • Two subclasses have the same field—Move the field to a superclass • Pull up Constructor Body • You have constructors on subclasses with mostly identical bodies—Create a superclass constructor; class this from the subclass methods

18. Sample Refactorings (cont.) • Form Template Method • You have two methods in subclasses that perform similar steps in the same order, yet the steps are different—Get the steps into methods with the same signature, so that the original methods become the same. Then you can pull them up. • Pull Up Method • You have methods with identical results on subclasses—Move them to the superclass.

19. Sample Refactorings (cont.) • Substitute Algorithm • You want to replace an algorithm with one that is clearer—Replace the body of the method with the new algorithm • Replace Magic Number with Symbolic Constant • You have a literal number with a particular meaning—Create a constant, name it after the meaning, and replace the number with it.

20. Refactoring Tools • Easy to do manually • Tools help it go faster • Minimum standards • "Move Method" capability- move a method body from one class to another, AND alter the callers. • Ability to do various kinds of renaming, such as Rename Method, AND adjust in callers. • Move Class • Extract Method- more than cut and paste. You have to analyze the method, find any temporary variables, then figure out what to do with them. • http://www.refactoring.com/tools.html

21. Refactoring Principles • What problems or limitations are there with refactoring? • Potential limitations: • too much indirection • changing published interfaces • significant design changes possible? • performance

22. Refactoring Principles • When not to refactor: • when you should rewrite • If you have no design to begin with! • when you are close to a deadline • The quick and dirty solution is always faster in the short term