Lecture Slides on Evolving Software | CMSC 433, Study notes of Programming Languages

Download Lecture Slides on Evolving Software | CMSC 433 and more Study notes Programming Languages in PDF only on Docsity! 1 CMSC 433 Programming Language Technologies and Paradigms Fall 2003 Refactoring October 16, 2003 2 Evolving Software Problem The requirements of real software often change in ways that cannot be handled by the current design Moreover, trying to anticipate changes in the initial implementation can be difficult and costly Solution Redesign as requirements change Refactor code to accommodate new design 3 Why not redesign/refactor? Conventional wisdom would discourage modifying a design You might break something in the code You have to update the documentation Both expensive But, there are longer term concerns: sticking with an inappropriate design Makes the code harder to change Makes the code harder to understand and maintain Very expensive in the long run 4 Refactoring Philosophy Make all changes small and methodical Follow mechanical patterns (which could be automated in some cases) called refactorings, which are semantics-preserving Retest the system after each change By rerunning all of your unit tests If something breaks, it s easy to know what you changed to cause the failure. 5 Principles of Refactoring In general, each refactoring aims to decompose large objects into smaller ones distribute responsibility Like design patterns Adds composition and delegation (read: indirection) In some sense, refactorings are ways of applying design patterns to existing code 6 Two Hats Refactoring Hat You are updating the design of your code, but not changing what it does. You can thus rerun existing tests to make sure the change works. Bug- fixing/Feature- adding Hat You are modifying the functionality of the code. May switch hats frequently But know when you are using which hat, to be sure that you are reaching your end goal. 7 Some Refactorings Rename Method Give a method a more meaningful name; update callers Extract Method Pull out code in one method into a separate method Replace Temp with Query Remove code that assigns a method call to a temporary, and replace references to that temporary with the call Move Method Move method from one class to another 8 Some Refactorings Extract Class Break a class that does many things into smaller classes Inline Class A class isn t doing very much, so inline its features into its users (reverse of Extract Class) Replace Type Code with State/Strategy Basically replace state constants with typesafe Enum Replace Conditional With Polymorphism Don t switch on a type code, rather do the work in the type object, and use delegation (second half of State) 9 Refactoring with Tools Many refactorings can be performed automatically This reduces the possibility of making a silly mistake Eclipse provides support for refactoring in Java http://www.eclipse.org 10 Spying Code to Refactor: Bad Smells What code needs to be refactored? Bad code exhibits certain characteristics that can be addressed with refactoring; these are called smells. Different smells suggest different refactorings 11 Feature Envy A method seems more interested in a class other than the one it is actually in e.g., invoking lots of get methods Can use Move Method and Extract Method Did this by moving extracting getCharge() out of Customer.statement(), moving it into Rental 12 Long Method A method is too long. Long methods are harder to understand than lots of short ones. Can decompose with Extract Method Pulled getCharge() out of statement() Also Replace Temp with Query Replaced thisAmount with calls to getCharge() And others