1 / 30

Lecture # 20 Improving the existing design: Refactoring

SWE 316: Software Design and Architecture. Handout. Lecture # 20 Improving the existing design: Refactoring. To be able to improve the existing design using refactoring. Most of the material and the slides of this presentation are adopted from:

dixie
Download Presentation

Lecture # 20 Improving the existing design: Refactoring

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. SWE 316: Software Design and Architecture Handout Lecture # 20Improving the existing design: Refactoring • To be able to improve the existing design using refactoring • Most of the material and the slides of this presentation are adopted from: • “Refactoring, Improving the Design of Existing Code” by Martin Fowler, Addison Wesley, 1999. • presentation by Martin Fowler. • http://www.refactoring.com

  2. 2/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References What is refactoring? • “Refactoring is the art of improving the design of existing code. Refactoring provides us with ways to recognize problematic code and gives us recipes for improving it.” [William C. Wake] • “A change to the system that leaves its behavior unchanged, but enhances some non-functional quality - simplicity, flexibility, understandability, ...” [Kent Beck]

  3. 3/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References What is refactoring? (cont...) • “The process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure” [Fowler] • Verify no change in external behavior by • Testing: in practice good tests are essential • Formal code analysis by tool

  4. 4/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References The two hats Adding Function • Add new capabilities to the system • Adds new tests • Get the test working Refactoring • Does not add any new features • Does not add tests (but may change some) • Restructure the code to remove redundancy Swap frequently between the hats, but only wear one at a time

  5. 5/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Why refactoring? (1 of 2) • To improve the software design • Makes the program easier to change • To make the software easier to understand • Write for people, not the compiler • Understand unfamiliar code • To help find bugs • Refactor while debugging to clarify the code

  6. 6/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Why refactoring? (2 of 2) • Some argue that good design does not lead to code needing refactoring but: • It is extremely difficult to get the design right the first time • Original design is often inadequate • You may not understand user requirements, if he does! • Refactoring helps you to: • Manipulate code in a safe environment • Understand existing code

  7. 7/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References When should you refactor? • To add new functionality: • Refactor existing code until you understand it • Refactor the design to make it easy to add • To find bugs: • Refactor to understand the code • For code reviews: • Immediate effect of code review

  8. 8/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Team techniques • Encourage refactoring culture • Nobody gets things right first time • Nobody can write clear code without reviews • Provide sound testing base • Tests are essential for refactoring • Build system and run tests daily • Pair programming • Two programmers working together can be quicker than working separately

  9. 9/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Creating your own refactorings • Consider a change to a program • Should it change the external behavior of the system • Break down the change into small steps • Look for points where you can compile and test • Carry out the change, note what you do • If a problem occurs, consider how to eliminate it in the future • Carry it out again, follow and refine the notes • After two or three times you have a workable refactoring

  10. List of refactorings: 10/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Typical Refactorings

  11. 11/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References A Longer List (martinfowler.com/refactoring/catalog) • Add Parameter • Change Bidirectional Association to Unidirectional • Change Reference to Value • Change Unidirectional Association to Bidirectional • Change Value to Reference • Collapse Hierarchy • Consolidate Conditional Expression • Consolidate Duplicate Conditional Fragments • Convert Dynamic to Static Construction by Gerard M. Davison • Convert Static to Dynamic Construction by Gerard M. Davison • Decompose Conditional • Duplicate Observed Data • Eliminate Inter-Entity Bean Communication (Link Only) • Encapsulate Collection • Encapsulate Downcast • Encapsulate Field • Extract Class • Extract Interface • Extract Method • Extract Package by Gerard M. Davison • Extract Subclass

  12. 12/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References A Longer List (martinfowler.com/refactoring/catalog) • Extract Superclass • Form Template Method • Hide Delegate • Hide Method • Hide presentation tier-specific details from the business tier (Link Only) • Inline Class • Inline Method • Inline Temp • Introduce A Controller (Link Only) • Introduce Assertion • Introduce Business Delegate (Link Only) • Introduce Explaining Variable • Introduce Foreign Method • Introduce Local Extension • Introduce Null Object • Introduce Parameter Object • Introduce Synchronizer Token (Link Only) • Localize Disparate Logic (Link Only) • Merge Session Beans (Link Only) • Move Business Logic to Session (Link Only) • Move Class by Gerard M. Davison • Move Field • Move Method

  13. 13/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References A Longer List (martinfowler.com/refactoring/catalog) • Parameterize Method • Preserve Whole Object • Pull Up Constructor Body • Pull Up Field • Pull Up Method • Push Down Field • Push Down Method • Reduce Scope of Variable by Mats Henricson • Refactor Architecture by Tiers (Link Only) • Remove Assignments to Parameters • Remove Control Flag • Remove Double Negative by Ashley Frieze and Martin Fowler • Remove Middle Man • Remove Parameter • Remove Setting Method • Rename Method • Replace Array with Object • Replace Assignment with Initialization by Mats Henricson • Replace Conditional with Polymorphism • Replace Conditional with Visitor by Ivan Mitrovic • Replace Constructor with Factory Method

  14. 14/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References A Longer List (martinfowler.com/refactoring/catalog) • Replace Data Value with Object • Replace Delegation with Inheritance • Replace Error Code with Exception • Replace Exception with Test • Replace Inheritance with Delegation • Replace Iteration with Recursion by Dave Whipp • Replace Magic Number with Symbolic Constant • Replace Method with Method Object • Replace Nested Conditional with Guard Clauses • Replace Parameter with Explicit Methods • Replace Parameter with Method • Replace Record with Data Class • Replace Recursion with Iteration by Ivan Mitrovic • Replace Static Variable with Parameter by Marian Vittek • Replace Subclass with Fields • Replace Temp with Query • Replace Type Code with Class

  15. 15/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References A Longer List (martinfowler.com/refactoring/catalog) • Replace Type Code with State/Strategy • Replace Type Code with Subclasses • Reverse Conditional by Bill Murphy and Martin Fowler • Self Encapsulate Field • Separate Data Access Code (Link Only) • Separate Query from Modifier • Split Loop by Martin Fowler • Split Temporary Variable • Substitute Algorithm • Use a Connection Pool (Link Only) • Wrap entities with session (Link Only)

  16. 16/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Extract Method VERY SIMPLE YET, VERY USEFUL • You have a code fragment that can be grouped together • Turn the fragment into a method whose name explains the purpose of the method. • void printOwing(double amount) { • printBanner(); • //print details • System.out.println ("name:" + _name); • System.out.println ("amount" + amount); • } • void printOwing(double amount) { • printBanner(); • printDetails(amount); • } • void printDetails (double amount) { • System.out.println ("name:" + _name); • System.out.println ("amount" + amount); • }

  17. 17/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Steps for Extract Method • Create method named after intention of code • Copy extracted code • Look for local variables and parameters • Turn into parameter • Turn into return value • Declare within method • Compile • Replace code fragment with call to new method • Compile and test

  18. A method is, or will be, using or used by more features of another class than the class it is defined on. Create a new method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether. 18/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Move Method

  19. 19/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Steps for Move method • Declare method in target class • Copy and fit code • Set up a reference from the source object to the target • Turn the original method into a delegating method • Compile and test • Find all users of the method • Adjust them to call method on target • Remove original method • Compile and test

  20. 20/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Replace Temp with Query • You are using a temporary variable to hold the result of an expression. • Extract the expression into a method. Replace all references to the temp with the expression. The new method can then be used in other methods. • double basePrice = _quantity * _itemPrice; • if (basePrice > 1000) • return basePrice * 0.95; • else • return basePrice * 0.98; • if (basePrice() > 1000) • return basePrice() * 0.95; • else • return basePrice() * 0.98; • double basePrice() { • return _quantity * _itemPrice; • }

  21. 21/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Steps for Replace temp with Query • Find temp with a single assignment • Extract Right Hand Side of assignment • Replace all references of temp with new method • Remove declaration and assignment of temp • Compile and test

  22. 1 Employee Employee Type Employee ENGINEER : int SALESMAN : int type : int Engineer Salesman 22/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Replace Type Code with State • You have a type code which affects the behavior of a class but you cannot use subclassing. • Replace the type code with a state object.

  23. 1 Employee Employee Type Employee ENGINEER : int SALESMAN : int type : int Engineer Salesman 23/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Replace Type Code with State • class Employee { • private int _type; • static final int ENGINEER = 0; • static final int SALESMAN = 1; • static final int MANAGER = 2; • Employee (int type) { • _type = type; • } • intpayAmount() { • switch (_type) { • case ENGINEER: • return _monthlySalary; • case SALESMAN: • return _monthlySalary + _commission; • case MANAGER: • return _monthlySalary + _bonus; • default: • throw new RuntimeException("Incorrect Employee"); • } • } • : • : • } • M s

  24. 24/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Steps for Replace Type Code with State • Create a new state class for the type code • Add subclasses of the state object, one for each type code. • Create an abstract query in the superclass to return the type code. Override in subclasses to return correct type code • Compile • Create field in old class for the state object. • Change the type code query to delegate to the state object. • Change the type code setting methods to assign an instance of the subclass. • Compile and test.

  25. 25/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Bad Smells • You are not limited to those refactoring techniques! • Always check for: • Bad smells within classes • Bad smells between classes

  26. 26/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Obstacles to refactoring (1 of 2) • Complexity • Changing design is hard • Understanding code is hard • Possibility to introduce errors • Run tests if possible • Build tests • Cultural Issues • “We pay you to add new features, not to improve the code!” What should I do in these cases?

  27. 27/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Obstacles to refactoring (2 of 2) • Performance issue • Refactoring may slow down the execution • Normally only 10% of your system consumes 90% of the resources so just focus on 10 %. • Refactorings help to localize the part that need change • Refactorings help to concentrate the optimizations • Development is always under time pressure • Refactoring takes time • Refactoring better after delivery

  28. 28/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Summary • “The process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure” [Fowler] • Refactor to: • Improve the software design • Make the software easier to understand • Help find bugs • A catalog of refactoring exists: Extract Method, Move Method, Replace Temp with Query, etc… • Refactoring has some obstacles

  29. 29/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Resources http://www.refactoring.com “Refactoring, Improving the Design of Existing Code” by Martin Fowler, Addison Wesley, 1999. “Refactoring to Patterns” by Joshua Kerievsky, Addison Wesley, 2004.

  30. 30/30 Introduction Why refactoring? Typical Refactorings Examples Obstacles Summary & References Resources (cont...) “Refactoring Workbook”, by William C. Wake, Addison Wesley, 2003.

More Related