• high-level design (architecture, modules)
• low-level design (interfaces, algorithms)

• Stepwise Refinement; “Top Down” vs. “Bottom Up”
• Abstractions used in design are often different from those used in requirements
• Typically result in procedural solutions that share data structures; the shared data structures is how modules “communicate”

• World consists of objects; Thus, systems should consist of objects that “model” their real-world counterparts
• Objects appear in all phases (requirements; design; implementation)
• Typically result in “federations” of objects that work together to achieve system functionality; data and algorithms “live” in objects; communication (data sharing) occurs via “message passing”

• also depends on talent (great designers à la Brooks)

• Useful because its focus is on source code not a specific design notation (so you do not need to learn a new notation to learn this technique)

• the external behavior of the system does not change…
  • e.g. functional requirements are maintained
• but the internal structure of the system is improved…

if (isSpecialDeal()) {
    total = price * 0.95;
    send()
} else {
    total = price * 0.98;
    send()
}

• In a small project, probably not much
• But as a project evolves, duplicated code can cause all sorts of problems
  • often associated with “cut and paste” bugs
    • you may copy this code to a context where a call to send() is not appropriate
    • or you may decide to change one branch and forget the other (especially if the code in each branch is long and you can’t keep both branches on the screen at once)

if (isSpecialDeal()) {
    total = price * 0.95;
} else {
    total = price * 0.98;
}
send();

• Answer: to improve the “state of practice” in the software development industry
• As we add standardized vocabulary which all professional developers are required to know; we improve the professionalism of the entire field
• Refactoring vocabulary is especially important since its improving developer’s “design skills”

• and as a program’s requirements change, the design may need to change
• thus, refactoring provides techniques for evolving the design in small incremental steps

• Often code size is reduced after a refactoring
• Confusing structures are transformed into simpler structures and, thus, these new structures are easier to maintain and understand

• 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 behavior

• Fowler’s book is a “refactoring cookbook” providing systematic steps for performing various type of refactoring

• write tests before you write code
• after you refactor code, you run the tests and make sure they all still pass
• if a test fails, the refactoring broke something, but you know about it right away and can fix the problem before you move on

• without refactoring, a design will “decay” as people make changes to a software system

• because structure is improved, duplicated code is eliminated, etc.

• Refactoring promotes a deep understanding of the code at hand, and this understanding aids the programmer in finding bugs and anticipating potential bugs

• because a good design enables progress

• 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 apply

• bad because if you modify one instance of duplicated code but not the others, you (may) have introduced a bug!

• long methods are more difficult to understand and maintain
• performance concerns with respect to lots of short methods are largely obsolete
  • Martin’s Rule of Performance: Assume costs [of lots of short functions] are negligible and wait to be proven wrong!

• a change requires lots of little changes in a lot of different objects

• A method requires lots of information from some other object (move it closer!)

• attributes that are used together but are not part of the same object

• Extract Method
• Replace Temp with Query
• Move 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);
}

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;
}