Refactoring

1. Refactoring Improving the structure of existing code Refactoring

2. Refactoring, the idea • Make software more supportable • Understandable • By other programmers and other human readers • Maintainable • Correcting errors • Adapting to new requirements • Introducing new qualities. • Scalable • Scale up in response to growth in demand for its functionality • More users • More CPU’s Refactoring

3. Refactoring targets“Bad smells in code” • Duplicated code • Long method • Large class • Long parameter list • Shotgun surgery • A simple change spreads over several classes. • Feature envy • Method uses a lot of methods from other classes • Data clumps • Same data clumps in many classes • Example: first name, last name, address • Explaining comments • Comments often cover (try to explain) code that is otherwise difficult to read. Refactoring

4. Categories of refactorings • Composing methods • Moving features between objects • Organizing data • Simplifying conditional expression • Making method calls simpler • Dealing with generalization Refactoring

5. Composing methods Extract method Introduce explaining variable Remove assignments to parameters Moving features between objects Move method Move field Extract class Inline class Organizing data Replace magic number with symbolic constant Encapsulate field Encapsulate collection Simplifying conditional expressions Remove control flag Replace conditional with polymorphism Introduce assertion Making method calls simpler Rename method Remove setting method Hide method Replace constructor with factory method Replace error code with exception Replace exception with test Dealing with generalization Pull up field Pull up method Pull up constructor body Extract subclass Extract superclass Extract interface Replace inheritance with delegation Some refactoring methods (refactorings) Refactoring

6. Composing methods • Common problems (“smells in code”) • Long method • Duplicated code • Comments to explain hard-to-understand code • Refactorings • Extract method • Turn a code fragment into a method whose name explains the purpose of the method • Comment no longer necessary • Introduce explaining variable • Put the result of an expression in a temporary variable with a name that explains the purpose. • Remove assignments to parameters • Use a temporary variable Refactoring

7. Moving features between objects • Common problems • Data class • A class with only get and set methods, and nothing else • Feature envy • A method is more interested in other classes methods than in it own class’ methods. • Large class • Refactorings • Move method • Move a method from one class to another • Move field • Move a field from one class to another • Extract class • Create a new class and move field + methods to the new class. (Rest of) old class references the newly extracted class. • Inline class • Move fields + methods to another class. Refactoring

8. Organizing data • Common “smells” • Explaining comments • Public fields • Refactorings • Replace magic number with symbolic constant • Area = 3.14159265 * r * r; // bad • Static final int PI = 3.14159265; • Area = PI * r * r; // better • Encapsulate field • Public fields are bad • Use private field + get / set methods • Encapsulate collection • Methods must generally return read-only views of collections Refactoring

9. Simplifying conditional expressions • Common “smells” • Lots of conditions in loops. • Refactorings • Remove control flag • Don’t use a lot of conditions in a loop. Use break or return (or continue) • Replace conditional with polymorphism • If you have different types of objects from the same class consider making subclasses. • Introduce assertion • If you have any assumptions about the state of the program, you should make an assertion in the program • assert object != null Refactoring

10. Making method calls simpler • Refactorings • Rename method • If the method name does not reveal the methods purpose, rename the method. • Remove setting method • If the field is supposed to be read-only, remove the set method. • Hide method • If the method is not used by other classes, make the method private • Replace constructor with factory method IMPORTANT! • If you want to do more than simple creation, use a factory method. • Example: java.text.DateFormat • Replace error code with exception • -1 or null might not be appropriate error codes • Replace exception with test • Give the caller a chance to test the condition of an object before calling the real method. • Example: java.util.Iterator Refactoring

11. Dealing with generalization • Refactorings • Pull up field • Two subclasses have the same field • Pull up method • Two subclasses have the same method • Pull up constructor body • Two subclasses have constructors with similar bodies • Extract subclass • A class has features that are use only in some instances. • Create a subclass for that subset of features. • Extract superclass • Two classes with similar features. • Create a superclass with the common features. • Extract interface • Several clients use the same subset of features of a class. • Extract the subset into an interface • Replace inheritance with delegation IMPORTANT! • Subclass uses only a part of a superclass • Example (don’t do this at home): Stack extends Vector • Properties extends HashTable • Use delegation Refactoring

12. Unit testing • Before you do any refactoring you must have a reliable unit test. • Run the test before the refactoring. • Run the test after the refactoring • To check that nothing bad happened due to the refactoring. Refactoring

13. Small steps • Refactoring must be done in small steps. • Don’t assume that you can do a lot in one big step. • Example: Extract class • Create the new (but empty class) • Make a link from the old to the new class • Use move field (another refactoring) to move fields to the new class • Run test after each separate move • Use move method (another refactoring) to move methods to the new class. • Run test after each separate move • Decide whether to expose the new class • Should if be public or not? Refactoring

14. Refactoring is not debugging • Your program must be working and tested before you start refactoring. • If your refactoring reveals a previously unknown bug • Stop refactoring • Write an new test case that shows the bug • Run the new test case • Do your debugging • Run the test case: Now shows that the bug has gone • Go back to refactoring Refactoring

15. NetBeans assistance • NetBeans can help do simple refactorings • Rename a class, method, or field • Across all files in a project • Move class from one package to another • Encapsulate field • Make the field private • Generate get and set methods • Change parameters to a method • Across al files in a project • Extract method • And many other refactorings Refactoring

16. PMD • PMD scans Java source code and looks for potential problem (smells) like • Possible bugs • Dead code • Sub-optimal code • Overcomplicated expressions • Duplicate code • http://pmd.sourceforge.net/ • PMD suggests simple refactorings • PMD is a plugin for NetBeans, and other IDEs Refactoring

17. RefactorIT • RefactorIT is a plug-in to NetBeans • And other IDE’s • RefactorIT can detect simple smells in your code • Use the Auditsfeature • Like PMD, but more rules … • RefactorIT can assist you in doing several refactorings • basically the same as NetBeans • Unfortunately RefactorIT only works with NetBeans 5.5 Refactoring

18. References Fowler et al.Refactoring: Improving the Design of Existing Code, Addison Wesley 1999. Chapter 1 Refactoring, a First Example, page 1-52. • This is THE book on refactoring Martin Fowler whttp://www.refactoring.com Catalog of refactorings William C. Wake Extreme Programming Explored, Addison Wesley 2002 • Chapter 2. Refactoring, page 23-43 Maciaszek & LiongPractical Software Engineering, Addison Wesley 2005. Chapter 15 Architectural Refactoring, page 478-508 • Modern books on software engineering has chapters on refactoring Joshua KerievskyRefactoring to Patterns, Addison Wesley Professional 2005 The code www.industriallogic.com/xp/refactoring/catalog.html Arie van Deursen et al.Refactoring Test Code, http://homepages.cwi.nl/~leon/papers/xp2001/xp2001.pdf • Any code can benefit from refactoring, even test code. Refactoring