Refactoring1 Improving the structure of existing code

Refactoring2 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

Refactoring3 Refactoring targets “Bad smells in code” Duplicated code Long method Large class Long parameter list Divergent change –If you have to change 3 methods when you have a new database. 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.

Refactoring4 Categories of refactorings overview Composing methods Moving features between objects Organizing data Simplifying conditional expression Making method calls simpler Dealing with generalization

Refactoring5 Some refactoring methods (refactorings) 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

Refactoring6 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

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

Refactoring8 Organizing data Common “smells” –Explaining comments –Public fields Refactorings –Replace magic number with symbolic constant Area = * r * r; // bad Static final int PI = ; 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

Refactoring9 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

Refactoring10 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.DateFormatjava.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.Iteratorjava.util.Iterator

Refactoring11 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 delegationIMPORTANT! Subclass uses only a part of a superclass –Example (don’t do this at home): java.util.Propertiesjava.util.Properties Use delegation

Refactoring12 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

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

Refactoring14 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?

Refactoring15 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

Refactoring16 References Fowler et al. Refactoring: Improving the Design of Existing Code, Addison Wesley Chapter 1 Refactoring, a First Example, page –This is THE book on refactoring Martin Fowler Catalog of refactoringshttp://refactoring.com William C. Wake Extreme Programming Explored, Addison Wesley 2002 –Chapter 2. Refactoring, page Maciaszek & Liong Practical Software Engineering, Addison Wesley Chapter 15 Architectural Refactoring, page –Modern books on software engineering has chapters on refactoring Joshua Kerievsky Refactoring to Patterns, Addison Wesley Professional 2005 The code Arie van Deursen et al. Refactoring Test Code, xp2001.pdf xp2001.pdf –Any code can benefit from refactoring, even test code.