Lecture 18: RefactoringKenneth M. AndersonObject-Oriented Analysis and DesignCSCI 4448/6448 - Spring Semester, 20051March 10, 2005 © University of Colorado, Boulder, 20052Credit where Credit is DueSome of the material for this lecture and lecture 19 is taken from “Refactoring: Improving the Design of Existing Code” by Martin Fowler; as such, some material is copyright © Addison Wesley, 1999March 10, 2005 © University of Colorado, Boulder, 20053Goals for this lectureIntroduce the concept of Refactoring and cover a few examplesIn lecture 19, we will present a tutorial that will introduce a few additional refactoring techniquesMarch 10, 2005 © University of Colorado, Boulder, 20054What is RefactoringRefactoring is the process of changing a software system such thatthe external behavior of the system does not changee.g. functional requirements are maintainedbut the internal structure of the system is improvedThis is sometimes called“Improving the design after it has been written”March 10, 2005 © University of Colorado, Boulder, 20055(Very) Simple ExampleConsolidate Duplicate Conditional Fragments (page 243); Thisif (isSpecialDeal()) {total = price * 0.95;send()} else {total = price * 0.98;send()}becomes thisif (isSpecialDeal()) {total = price * 0.95;} else {total = price * 0.98;}send();March 10, 2005 © University of Colorado, Boulder, 20056Refactoring is thus Dangerous!Manager’s point-of-viewIf my programmers spend time “cleaning up the code” then that’s less time implementing required functionality (and my schedule is slipping as it is!)To address this concernRefactoring needs to be systematic, incremental, and safeMarch 10, 2005 © University of Colorado, Boulder, 20057Refactoring is Useful Too The idea behind refactoring is to acknowledge that it will be difficult to get a design right the first time and, as a program’s requirements change, the design may need to changerefactoring provides techniques for evolving the design in small incremental stepsBenefitsOften code size is reduced after a refactoringConfusing structures are transformed into simpler structureswhich are easier to maintain and understandMarch 10, 2005 © University of Colorado, Boulder, 20058A “cookbook” can be useful“New” BookRefactoring: Improving the Design of Existing Codeby Martin Fowler (and Kent Beck, John Brant, William Opdyke, and Don Roberts)Similar to the Gang of Four’s Design PatternsProvides “refactoring patterns”March 10, 2005 © University of Colorado, Boulder, 20059Principles in RefactoringFowler’s definitionRefactoring (noun)a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviorRefactoring (verb)to restructure software by applying a series of refactorings without changing its observable behaviorMarch 10, 2005 © University of Colorado, Boulder, 200510Principles, continuedThe purpose of refactoring isto make software easier to understand and modifycontrast this with performance optimizationagain functionality is not changed, only internal structure; however performance optimizations often involve making code harder to understand (but faster!)March 10, 2005 © University of Colorado, Boulder, 200511Principles, continuedWhen you systematically apply refactoring, you wear two hatsadding functionfunctionality is added to the system without spending any time cleaning the coderefactoringno functionality is added, but the code is cleaned up, made easier to understand and modify, and sometimes is reduced in sizeMarch 10, 2005 © University of Colorado, Boulder, 200512Principles, continuedHow do you make refactoring safe?First, use refactoring “patterns”Fowler’s book assigns “names” to refactorings in the same way that the GoF’s book assigned names to patternsSecond, test constantly!This ties into the extreme programming paradigm, you write tests before you write code, after you refactor code, you run the tests and make sure they all still passif a test fails, the refactoring broke something, but you know about it right away and can fix the problem before you move onMarch 10, 2005 © University of Colorado, Boulder, 200513Why should you refactor?Refactoring improves the design of softwarewithout refactoring, a design will “decay” as people make changes to a software systemRefactoring makes software easier to understandbecause structure is improved, duplicated code is eliminated, etc.Refactoring helps you find bugsRefactoring promotes a deep understanding of the code at hand, and this understanding aids the programmer in finding bugs and anticipating potential bugsRefactoring helps you program fasterbecause a good design enables progressMarch 10, 2005 © University of Colorado, Boulder, 200514When should you refactor?The Rule of ThreeThree “strikes” and you refactorrefers to duplication of codeRefactor when you add functionalitydo it before you add the new function to make it easier to add the functionor do it after to clean up the code after the function is addedRefactor when you need to fix a bugRefactor as you do a code reviewMarch 10, 2005 © University of Colorado, Boulder, 200515Problems with RefactoringDatabasesBusiness applications are often tightly coupled to underlying databasescode is easy to change; databases are notChanging Interfaces (!!)Some refactorings require that interfaces be changedif you own all the calling code, no problemif not, the interface is “published” and can’t changeMajor design changes cannot be accomplished via refactoringThis is why extreme programming says that software engineers need to have “courage”!March 10, 2005 © University of Colorado, Boulder, 200516Refactoring: Where to Start?How do you identify code that needs to be refactored?Fowler uses an olfactory analogy (attributed to Kent Beck)Look for “Bad Smells” in CodeA very valuable chapter in Fowler’s bookIt presents examples of “bad smells” and then suggests refactoring techniques to applyMarch 10, 2005 © University of Colorado, Boulder, 200517Bad Smells in CodeDuplicated Codebad because if you modify one instance of duplicated code but not the others, you (may) have introduced a bug!Long Methodlong methods are more difficult to understandperformance concerns with respect to lots of short methods are largely obsoleteMarch 10, 2005 © University of Colorado, Boulder, 200518Bad Smells in CodeLarge ClassLarge classes try to do too much, which
View Full Document
Unlocking...