1. 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.

2. 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

3. Basic Code Metrics  Lines of Code More lines of code = more maintenance. Of two programs of “equal functionality,” it is better to have fewer lines of code.  Philosophy: Consistent with the “refactoring” philosophy, we want code to be properly abstracted, less complex, and readable Number of Classes  To a point, more classes are preferred over less classes.  Avoid “god class” or “blob class”

4. Coupling and Cohesion  Excessive coupling Detrimental to modular design and prevents reuse  Larger number of couples, higher sensitivity to changes in other parts of the design  maintenance is more difficult  Any measure of disparateness of methods helps identify flaws in the design of the classes.  Cohesiveness of methods within a class is desirable, since it promotes encapsulation.  Lack of cohesion implies classes should probably be split into two or more subclasses.

5. Inheritance  Depth of Inheritance Tree: maximum length from the class node to the root/parent of the class hierarchy tree (number of ancestor classes. ) Tradeoff:  Deep trees  conceptual integrity problem (hard to understand, so more complex)  but greater reuse  Number of Children: Number of direct descendants (subclasses) for each class. Classes with large number of children are considered to be difficult to modify and usually require more testing because of the effects on changes on all the children. They are also considered more complex and fault-prone because a class with numerous children may have to provide services in a larger number of contexts and therefore must be more flexible.

6. 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

7. 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

8. 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.

9. 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

10. 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.

11. 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

12. 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.

13. 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

14. 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

15. 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

16. 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

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

18. 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

19. 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

20. 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.

21. 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.

22. Reading & Questions for Next Class  Catalog of refactorings http://www.refactoring.com/catalog/index.html

23. 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.Rename Method  Move Class 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. Extract Method  http://www.refactoring.com/tools.html http://www.refactoring.com/tools.html

24. Software Refactoring Example  http://www.refactoring.com/rejectedExample.pdf http://www.refactoring.com/rejectedExample.pdf  http://www.refactoring.com http://www.refactoring.com

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

26. 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