About Me – Frank Xu

1. About Me – Frank Xu • Education • North Dakota State University • Ph.D. in Software Engineering • Towson University • MS in Computer Science • Southeast Missouri State University • BS in Computer Science, Minor in Math • Working Experience • GE Transportation, 2008- present, • Consultant • Gannon University, 2008- present • Director of Keystone Software Development Institute, Assistant Professor of SE • University VA –Wise, 2007- 2008 • Assistant Professor of Software Engineering • Swanson Health Products, MIS department, 2005 ~ 2007 • Sr. Programmer Analyst • Volt Information Science Inc., 2004 ~ 2005 • Software Engineer

2. Refactoring - A disciplined approach to rework for better design.

3. Objectives • What is refactoring? • Why should I refactor? • When should I refactor? • How to refactor?

4. Definition • Refactoring is a disciplined technique for restructuring an existing body of code, • altering its internal structure • without changing its external behavior. • It makes the software easier to understand and cheaper to modify.

5. A simple example • Example: compute gravitational potential energy • PEgrav = mass * g * height Magic number • double potentialEnergy(double mass, double height) { • return mass * height * 9.81; • } assertEquals(9.81, new RefactoringDemo().potentialEnergy(1,1),0.0); static final double GRAVITATIONAL_CONSTANT = 9.81; double potentialEnergy(double mass, double height) { return mass * height * GRAVITATIONAL_CONSTANT; }

6. Properties of refactoring • One step at a time • Preserve correctness • Frequent testing

7. Why refactor? • Improves the design of software. • Without refactoring, the design of the program will decay • Makes software easier to understand. • A good design is easy to understand • Helps you find bugs. • The clarification process helps find bugs • Helps you program faster. • Poor design slow you down

8. When to Refactor? • As you develop • Example: change a variable name to something more meaningful. • Before adding functions. • Sometimes the existing design does not allow you to easily add the feature. • When you need to fix a bug • The bug exists because the code was not clear enough for you to see the bug in the first place. • When you do a code review • Code reviews help spread knowledge through the development team. • Works best with small review groups

9. Steps to refactoring • Identifying bad smells of code • a “bad smell” = a warning sign in the code • e.g., time consuming code • Designing solid tests • for the section of code under analysis. • Refactoring the code • based on the type of the smell • Applying tests.

10. Bad Smells in Code • Parallel Interface Hierarchies • Lazy Class • Speculative Generality • Temporary Field • Message Chains • Middle Man • Inappropriate Intimacy • Incomplete Library Class • Data Class • Refused Bequest • Duplicated Code • Long Method • Large Class • Long Parameter List • Divergent Change • Shotgun Surgery • Feature Envy • Data Clumps • Primitive Obsession • Switch Statements

11. Bad smells in code • Smells within classes • Duplicated code • Long method • Large class • … • Smells between classes • Primitive obsession • Inappropriate intimacy • Middle man • …

12. Duplicated Code – (1) • “The #1 bad smell” • Copy & paste • What if duplicates changes • Refactoring solutions • Pull up a field • Form a template method • Substitute algorithm

13. Duplicated Code – (2) • Bad Smell • Two subclasses have the same field. • Refactoring • Pull up a field: Move the field to the superclass. Employee Salesman Engineer name name

14. Duplicated Code – (3) • Bad Smell • You have two methods in subclasses that perform similar steps in the same order, yet the steps are different. • Refactoring: Form a template method • Get the steps into methods with the same signature, so that the original methods become the same. Then you can pull them up.

15. Duplicated Code – (4) Customer getBaseAmt() getTaxAmt() PersonalCustomer CorporateCustomer getBillableAmt() getBillableAmt() getBaseAmt() getTaxAmt() getBaseAmt() getTaxAmt() double base=unit*rate*0.5 double tax=base*Site.TAX_RATE*0.2; return base+tax double base=unit*rate double tax=base*Site.TAX_RATE; return base+tax return getBaseAmt()+getTaxAmt()

16. Duplicated Code – (5) • Bad smell • Similar logic • Refactoring: Substitute algorithm • Replace the body of the method with the new algorithm. duplications

17. Long Method – (1) • The longer the method the harder it is to see what it’s doing. • Poorly thought out abstractions and boundaries • Refactoring solutions • Extract method • Replace temp with query • Introduce parameter object • Preserve whole object

18. Long Method – (2) • private void m1(){ • Statement 1; • .. • Statement 9; • } • private void m2(){ • Statement 10; • .. • Statement 19; • } • private void m3(){ • Statement 20; • .. • Statement 30; • } public void methodA(){ } • Extract method • break up into smaller private methods within the class • Example • public void methodA(){ • Statement 1; • Statement 2; • .. • Statement 30; • } m1(); m2(); m3();

19. Long Method – (3) • Bad smell • using a temporary variable to hold the result of an expression. • Refactoring: Replace temp with query • Extract the expression into a method. if (basePrice() > 1000) { return basePrice() * 0.95; } else { return basePrice() * 0.98; } //any side effects? Temp variable expression double basePrice=basePrice(); if (basePrice> 1000) { return basePrice* 0.95; } else { return basePrice* 0.98; }

20. Long Method – (4) • Smell: a method with a long list of parameters • A group of parameters that naturally go together. • Refactoring: Introduce parameter object • Replace them with the object. DateRange DateRange DateRange DateRange start: Date end: Date Customer amountInvoicedIn ( ) amountReceivedIn ( ) amountOverdueIn ( ) Start: Date, end: Date Start: Date, end: Date Start: Date, end: Date

21. Long Method – (5) • Smell • You are getting several values from an object and passing these values as parameters in a method call. • Refactoring: Preserve whole object • Send the whole object instead.

22. Large Class – (1) • A class that is trying to do too much • Can usually be identified by looking at how many instance variables it has. • When a class has too many instance variables, duplicated code cannot be far behind. • Refactoring solution • Extract class • Extract subclass

23. Large Class – (2) • Bad smell • Have one class doing work that should be done by two. • Refactoring: Extract class • Need create a new class and move the relevant fields and methods from the old class into the new class. Customer PhoneNumber name areaCode number String: getPhoneNumber() PhoneNumber: getPhoneNumber()

24. Large Class – (3) • Smell • A class has features that are used only in some instances. • Extract subclass • Create a subclass for that subset of features. Do all the JobItem objects need to have getEmployee function? JobItem isLabor getTotalPrice() getUnitPrice() getUnitPrice() getEmployee() LaborItem

25. Primitive Obsession – (1) • Over use primitive to represent data • All properties of a class are primitive types • int, String, boolean, double, etc. • Primitive difficult to represent data • money (which combines quantity and currency) • a date range object • Refactorings • Replace data value with object • Replace type code with class

26. Primitive Obsession – (2) • Smell • You have a data item that needs additional data or behavior. • Refactoring • Turn the data item into an object. Customer Order id: String last Name:: String middleName: String firstName: String phone: PhoneNumber customer: String

27. Primitive Obsession – (3) • Smell • A class has a numeric type code that does not affect its behavior. • Refactoring: Replace type code with class • Replace the number with a new class. Person BloodType O: int A: int B:int AB:int O: BloodType A: BloodType B: BloodType AB: BloodType bloodType:int public enumBloodType { O,A,B,AB} public class BloodType{ public static final int O 1; public static final int A 2; public static final int B 3; public static final int AB 4; } public class Person{ …… intbloodType =BloodType.O; ……. }

28. Inappropriate Intimacy– (1) • Two classes are overly entertwined • Sharing of secrets between classes • Leads to data coupling • Refactorings • Hide delegate • Replace inheritance with delegation

29. Delegate Inappropriate Intimacy– (2) Client taskA() • Motivation • A client is calling a delegate class of an object. • Refactoring: Hide delegate • Create methods on the server to hide the delegate. What is problem? Change to Delegate will propagate to the cleint Server Delegate Client taskA() taskA() public void method(){ delegate.taskA(); }

30. Inappropriate Intimacy– (3) Object need to know less about other parts of the system ClientClass manager=john. getDepartment(). getManager(); Employee Department getDepartment() getManager() getManager() public class Department{ private Employee manager; …… public Department (Employee manager){ this.manager=manager; } public string getManager(){ return manager; } ….. } public getManager(){ return department.getManager(); }

31. Inappropriate Intimacy– (3) • Motivation • A subclass uses only part of a superclasses interface or does not want to inherit data. • Refactoring: Replace inheritance with delegation • Create a field for the superclass, adjust methods to delegate to the superclass, and remove the subclassing.

32. Middle Man • Smell • A method's body is just as clear as its name • Refactoring • Put the method's body into the body of its callers and remove the method intgetRating() { return (moreThanFiveLateDeliveries()) ? 2 : 1; } booleanmoreThanFiveLateDeliveries() { return _numberOfLateDeliveries > 5; } intgetRating() { return (_numberOfLateDeliveries > 5) ? 2 : 1; }

33. Why might you still not refactor your programs? • You might not understand how to refactor. • If the benefits are long-term, why exert the effort now? In the long term, you might not be with the project to reap the benefits! • Refactoring code is an overhead activity; you're paid to write new features. • Refactoring might break the existing program.

34. Summary • Refactoring is a disciplined approach to rework for better design. • Refactor when code smells. • Take advantage of IDE (Eclipse/IntelliJ/ Java Studio). • Check online resources for updated refactoring. • Know refactoring before your interview.

35. References • http://wiki.java.net/bin/view/People/SmellsToRefactorings • https://netfiles.uiuc.edu/dig/RefactoringInfo/ • http://www.refactoring.com/

36. Questions?