1 / 36

About Me – Frank Xu

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

yitta
Download Presentation

About Me – Frank Xu

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related