Refactoring, Part 1Kenneth M. AndersonUniversity of Colorado, BoulderCSCI 4448/5448 — Lecture 26 — 11/19/09© University of Colorado, 2009Credit where Credit is Due• Some of the material for this lecture is taken from “Refactoring: Improving the Design of Existing Code” by Martin Fowler; as such, some material is copyright © Addison Wesley, 19992Goals for this lecture• Introduce the concept of Refactoring and cover a few examples• In lecture 27, we will present a tutorial that will introduce a few additional refactoring techniques3What is Refactoring• Refactoring is the process of changing a software system such that• the external behavior of the system does not change• e.g. functional requirements are maintained• but the internal structure of the system is improved• This is sometimes called• “Improving the design after it has been written”4(Very) Simple Example• Consolidate 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();5(Another) Simple Example• Replace Magic Number with Symbolic Constantdouble potentiaEnergy(double mass, double height) {return mass * 9.81 * height;}• becomes thisdouble potentiaEnergy(double mass, double height) {return mass * GRAVITATIONAL_CONSTANT * height;}static final double GRAVITATIONAL_CONSTANT = 9.81;6In this way, refactoring formalizes good programming practicesRefactoring is thus Dangerous!• Manager’s point-of-view• If 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 concern•Refactoring needs to be systematic, incremental, and safe7Refactoring 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 change• refactoring provides techniques for evolving the design in small incremental steps• Benefits• Often code size is reduced after a refactoring• Confusing structures are transformed into simpler structures• which are easier to maintain and understand8A “cookbook” can be useful• Refactoring: Improving the Design of Existing Code• by Martin Fowler (and Kent Beck, John Brant, William Opdyke, and Don Roberts)• Similar to the Gang of Four’s Design Patterns• Provides “refactoring patterns”9Principles in Refactoring• Fowler’s definition• Refactoring (noun)• a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior• Refactoring (verb)• to restructure software by applying a series of refactorings without changing its observable behavior10Principles, continued• The purpose of refactoring is• to make software easier to understand and modify• contrast this with performance optimization• again functionality is not changed, only internal structure;• however performance optimizations often involve making code harder to understand (but faster!)11Principles, continued• When you systematically apply refactoring, you wear two hats• adding function•functionality is added to the system without spending any time cleaning the code• refactoring•no functionality is added, but the code is cleaned up, made easier to understand and modify, and sometimes is reduced in size12Principles, continued• How 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 patterns• Second, test constantly!• This ties into the agile design paradigm•you write tests before you write code• after you refactor, you run the tests and check that they all pass•if a test fails, the refactoring broke something but you know about it right away and can fix the problem before you move on13Why should you refactor?• Refactoring improves the design of software• without refactoring, a design will “decay” as people make changes to a software system• Refactoring makes software easier to understand• because structure is improved, duplicated code is eliminated, etc.• Refactoring helps you find bugs• Refactoring promotes a deep understanding of the code at hand, and this understanding aids the programmer in finding bugs and anticipating potential bugs• Refactoring helps you program faster• because a good design enables progress14When should you refactor?• The Rule of Three• Three “strikes” and you refactor• refers to duplication of code• Refactor when you add functionality• do it before you add the new function to make it easier to add the function• or do it after to clean up the code after the function is added• Refactor when you need to fix a bug• Refactor as you do a code review15Problems with Refactoring• Databases• Business applications are often tightly coupled to underlying databases• code is easy to change; databases are not• Changing Interfaces (!!)•Some refactorings require that interfaces be changed• if you own all the calling code, no problem• if not, the interface is “published” and can’t change•Major design changes cannot be accomplished via refactoring• This is why agile design says that software devs. need courage!16Refactoring: 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 Code• A very valuable chapter in Fowler’s book• It presents examples of “bad smells” and then suggests refactoring techniques to apply17Bad Smells in Code•Duplicated Code• bad because if you modify one instance of duplicated code but not the others, you (may) have introduced a bug!•Long Method• long methods are more difficult to understand• performance concerns with respect to lots of short methods are largely obsolete18Bad Smells in Code•Large Class• Large classes try to do too much, which reduces cohesion•Long Parameter List• hard to understand, can become inconsistent if the same parameter chain is being passed from method to method•Divergent Change• symptom: one type of change requires changing one subset of methods; another type of