Refactoring Compl. Bad smells in your software Code duplication Long operations, big classes Operations with lots of parameters Divergent or shotgun fixes

Refactoring

Compl

“Bad smells” in your software

• Code duplication• Long operations, big classes• Operations with lots of parameters• Divergent or shotgun fixes during maintenance• Feature envy • You use “switch” (*)• “fake attributes” in your class• comments inside an operation (Eh? I’m sorry!?)

2

Suboptimaal software

• Complexity & flexibility of your software components are not optimal.

maintenance cost bugs fix, adapting features, adding features

Don’t underestimate maintenance.

3

• Mitigated by: invest in a good design, employ design patterns• Still, under pressure (deadline!) the temptation to do dirty solving is big...• Let’s take a look at “refactoring”

Refactoring

4

Refactoring is a transformation on the source code of a software to make it easier to understand and to maintain.

The transformation must preserve the software’s observable behavior.

So, performance is not a consideration in refactoring. This is not to say that performance is unimportant. But “refactoring” is limited to achieve the above mentioned goals.

Fowler, 2000. With contrib. from e.g. Erich Gamma (GOF) & Kent Beck (JUnit)

Belong to basic vocab of sw. engineers.

How to do it?

• Formal theory of refactoring? sadly none practical enough.• So, we do it in a series of small steps, like ...• Rely on testing (!)• Intergrate it structurally into your maintenance workflow

5

Keep in mind that the goal of refactoring is not a cosmetic make-over, though some of the steps may look cosmetics. The goal is: mitigating your long term maintenance.

I will mark the refactoring names like this: Extract Method

Example

6

Film- title- priceCode : int

RentInfo- numOfDays

*

film

Customer- name- CustPoints+ rent(film)+ back(film)+ mkInvoice()

*

We’ll keep getter and setter implicit.

RentInfo- numOfDays

**

rentInfosfilm

1

Three price categories, encoded as constants:CHILDREN = 0STANDARD = 1 NEW = 2

C: CustomerF1 : Film

F2 : Film

3d : RentInfo

7d : RentInfo

7

mkInvoice () { totPrice = 0 pts = 0 println(“Invoice for” + name) for (RentInfo v : rentInfos) { // calculate price for a single film v_price = 0 switch (v.getFilm().getPriceCode()) { case Film.STANDARD : v_price = 3 euro * v.numOfdays ; break case Film.NEW : v_price = 5 euro * v.numOfdays ; break case Film.CHILDREN : v_price = 2 euro * v.numOfdays } totPrice += v_price // calculate earned points pts++ if (v.getFilm().getPriceCode()==Film.NEW) pts++ println(“Film ” + v.getName() + “, price = ” + v_price) } println(“Tot price = ” + totPrice) println(“Points earned = ” + pts)}

Bad smells?Let’s rework this, but in small steps refactoring.

8

Extract method

mkInvoice () { totPrice = 0 pts = 0 println(“Invoice for” + name) for (RentInfo v : rentInfos) { // calculate price for a single film v_price = 0 switch (v.getFilm().getPriceCode()) { case Film.STANDARD : v_price = ... ; break case Film.NEW : v_price = ... ; break case Film.CHILDREN : v_price = ... } totPrice += v_price // calculate earned points pts++ if (v.getFilm().getPriceCode()==Film.NEW) pts++ println(“Film ” + v.getName() + “, price = ” + v_price) } println(“Tot price = ” + totPrice) println(“Points earned = ” + pts)}

promote a fraction of code to a method.(comments often give hint)

9

Extract method

mkInvoice () { totPrice = 0 pts = 0 println(“Invoice for” + name) for (RentInfo v : rentInfos) { // calculate price for a single film v_price = 0 switch (v.getFilm().getPriceCode()) { case Film.STANDARD : v_price = ... ; break case Film.NEW : v_price = ... ; break case Film.CHILDREN : v_price = ... } totPrice += v_price // calculate earned points pts++ if (v.getFilm().getPriceCode()==Film.NEW) pts++ println(“Film ” + v.getName() + “, price = ” + v_price) } println(“Tot price = ” + totPrice) println(“Points earned = ” + pts)}

calculatePrice(v) { v_price = 0 switch (v.getFilm().getPriceCode()) { case Film.STANDARD : v_price = ... ; break case Film.NEW : v_price = ... ; break case Film.CHILDREN : v_price = ... } return v_price}

v_price = calculatePrice(v)

10

Extract methodmkInvoice () { totPrice = 0 pts = 0 println(“Invoice for” + name) for (RentInfo v : rentInfos) { // calculate price for a single film .... totPrice += v_price // calculate earned points pts++ if (v.getFilm().getPriceCode()==Film.NEW) pts++ println(“Film ” + v.getName() + “, price = ” + v_price) } println(“Tot price = ” + totPrice) println(“Points earned = ” + pts)}

??

Take sufficient context along

caculateEarnedPoints(v,pts) { pts++ if (v.getFilm().getPriceCode()==Film.NEW) pts++ return pts}

pts = calculateEarnedPoints(v,pts)

11

After extraction

mkInvoice () { totPrice = 0 pts = 0 println(“Invoice for” + name) for (RentInfo v : rentInfos) { v_price = calculatePrice(v) totPrice += v_price pts = calculateEarnedPoints(v,pts) println(“Film ” + v.getName() + “, price = ” + v_price) } println(“Tot price = ” + totPrice) println(“Points earned = ” + pts)}

these were comments! Now self-documenting.

This is easier to understand now, no?

12

Don’t we all love temporary variables?

int p = calculatePrice(v)totPrice += pprintln(“Film ” + v.getName() + “, price = ” + p)

Conceptually, v_price is just use to hold the result of calculatePrice. They are synonymous; but we have introduced it to get a bit of performance. But it does complicate your code! (your mind have to keep track of one more item in your program)

totPrice += calculatePrice(v)println(“Film ” + v.getName() + “, price = ” + calculatePrice(v))

Remove temp

How about performance? • Balancing between maintenance and performance.• 90% of the time, your software is doing just 10% of your code.• User profiler to locate this 10%, and target your performance optimization on this 10%.

13

“Features envy”

calculatePrice(v) { v_price = 0 switch (v.getFilm().getPriceCode()) { case Film.STANDARD : v_price = 3 euro * v.numOfdays ; break case Film.NEW : v_price = 5 euro * v.numOfdays ; break case Film.CHILDREN : v_price = 2 euro * v.numOfdays } return v_price}

Customer is doing too much work on data obtained from Film. Shouldn’t Film does this work instead?? risk of shot-gun fixes in the future “Move method”

CustomercalculatePrice(v)

FilmcalculatePrice(v)

14

Why is this switch bad?

calculatePrice(v) { v_price = 0 switch (v.getFilm().getPriceCode()) { case Film.STANDARD : v_price = ... ; break case Film.NEW : v_price = ... ; break case Film.CHILDREN : v_price = ... } return v_price}

FilmcalculatePrice()v

Adding a new kind of film forces you to change calculatePrice divergent fix.


StandardFilm

NewFilm

ChildrenFilm

Solving it with inheritence.

Unfortunaly in this example, “film-type” should be able to change dynamically! So you need a different solution.

15

Replace type-code with strategy + polymorphism

calculatePrice() { v_price = 0 switch (v.getFilm().getPriceCode()) { case Film.STANDARD : v_price = ... ; break case Film.NEW : v_price = ... ; break case Film.CHILDREN : v_price = ... } return v_price}


FilmPriceStrategycalculatePrice(v)

StandardPrice

NewPrice

ChildrenPrice

1

calculatePrice(v) { return priceStrg.calculatePrice(v)}

priceStrg

You can change the strategy dynamically: film.priceStrg = new NewPrice() film.priceStrg = new StandardPrice()

Fowler’s refactoring set

• Streamlining methodes (9)• Moving features (8)• Organizing data (16)• Simplifying conditional statements (8)• Simplifying method calls (15)• Generalization (12)

16

Streamlining methods

• extract method– inverse: inline method but you’ll risk code duplication.

To limit: apply if the body is just as clear as the method’s name, and is not called in too many other methods.

• eliminate and introduce temp– temp is a form of indirection – furthermore makes method extraction more difficult as

you have to move its context as well

17

Fowler: long methods are often the sources of problems (he prefers more methods; but short)

Temp

• introduce explaining variable and eliminate temp

• replace temp with query

• you can’t elimimate all temps loop counter, accumulation var.

18

double sellPrice= product.getPrice() * 1.5p = sellPrice > 10.0

p = product.getPrice() * 1.5 > 10.0

expression is too complex

p = sellPrice() > 10.0

You have too many parameters …

• Introduce parameter object

19

price(date , age, isMember, discountCard, isOpenDay)

price(personProfile, dateProfile)personProfileageisMemberdiscountCard

dateProfiledateisOpenday

Moving Features

• Main tool: move method/field (you have seen this)• spliting and combining classes• introducing and eliminating delegation

20

Distribute the work (which class does what). A class that does too much is difficult to understand.

Split and combine

• Extract class: a class C does too much. Identify a part of C that can be group to its own class.

• inverse: inline class.

21

Personnameagestreethousenrpostcode…printAddress()

Personnameage...

AddressstreethousenrpostcodeprintAddress()

1

1

Delegate

• Hide delegate

• remove middle man

22

Person

Address PostcodegetCity()

address.getPostcode().getCity()

Person

AddressgetCity()

PostcodegetCity()

address. getCity()

getCity() { return postcode.getCity() }

If Address is doing too mush delegation work instead of real work, then reverse: let the client access the delagate directly.

A client (Person) of Address is calling Address’ delegate Hide this delegate.

1

1

1

1

Streamlining conditionals

• Main tool : extract method on conditionals– decompose conditional, consolidate conditional,

• Simplification on the structure– remove control flag– replace conditional with polymorphism (you have seen this)– replace nested conditional with guard clauses

23

Complex domain logics translate to complex conditional statements, which are often difficult to understand (hence error prone).

Extract method on conditions

24

if (date.before(SUMMER_BEGIN) || date.after(SUMMER_END) ) price = 0.8 * price + ... // some complicated expr

if (notSummer(date ) ) price = 0.8 * price ...

A complicate conditional:

Decompose conditional

if (notSummer(date ) ) price = summerPrice(...)

Extract method on conditions

25

price(person) { if (isFree(person)) return 0 ; return stdPrice(person)}

price(person) { if (person.age ≤ 10) if (person.isMember) if (person.isBirthday()) return 0 ; return stdPrice(person)}

Consolidate conditional expression

giveCandy(person) { if (person.age ≤ 10) return candy if (person.isMember) return candy if (person.isBirthday()) return candy return null}

Series of “if” encoding “or” Cascade of “if” encoding “and”

giveCandy(person) { if (candyEligible(person)) return candy ; return null}

Simplifying cond. structure

26

found = false product = nullfor (iter = V.iterator() ; iter.hasNext() && !found ; ) { product = iter.next() found = product.price() <= 10.0}return product

remove control flag

control variable

for (Product p : V) { product = p if (product.prijs() <= 10.0) break}return product

if (product.prijs() <= 10.0) break


27

giveMilk(person) { if (person is alergic) m = null else { m = new Milk() ; m.warmup() } return m}

giveCandy(person) { if (person.age < 12) c = new MagicCandy() else c = new StdCandy() c.wrap() return c}

“If” implementing two paths of your “normal flow” :

An “alternate flow” seeks to break off the computation early, due to some “exceptional” condition. “If” implementing an “alternate flow” :


28

giveMilk(person) { if (person is alergic) m = null else { m = new Milk() ; m.warmup() } return m}

An “alternate flow” break off the computation early, due to some “exceptional” condition. “If” implementing an “alternate flow” :

Here programmer also tried to make the program to have a single entry and exit point. That seems to be a good idea, no?

Fowler: favor whichever is more readable.

giveMilk(person) { if (person is alergic) return null m = new Milk() ; m.warmup() return m}

Replace (nested) conditionals with “guard clauses”

Generalization

• Moving features within a hierarchy• Spliting and combining hierarchy• Replacing inheritence with delegation, or the other way

around

29

Inheritence is importtant in OO; optimize your inheritence structure.

Pull up / pull down

30

Productname

Applediscount()

Coffeediscount()

Productname

discount()

Apple Coffee

pull up

Productnamedrink()

Apple Coffee

Productname

Apple Coffeedrink()

pull down

GreenApple

VeryGreenApple

GreenApplecollapse

hierarchy

Extract sub/super class

31

Productname

discount()

But discount is only relevant for a subset of the instances of Product.

Productname

DiscountedProductdiscount()

extract subclass

Productprice

getIcon ()setIcon(i)

resetIcon()

Personname

getIcon ()setIcon(i)

resetIcon()

Productprice

Personname

ItemWithIcongetIcon ()setIcon(i)

resetIcon()extract superclass

The classes have a common subset of features

(Q: and what if we don’t have multiple inheritance?)

Extract interface

32

Productname

getPrice()getTax()

getDiscount()…

WebShop Invoice

we have multiple client-classes that use the same subset of Product’s features

Productname

…

<<interface>>SellableProduct

getPrice()getTax()

getDiscount()

extract interface

<<use>> <<use>>

WebShop Invoice

Replace delegation with inheritence, or back

33

Productnameprice


resetIcon()…

Productnameprice


resetIcon()

1

0..1

If Product turns out to use only very few features of ItemWithIcon

If Product turns out to delegate too much work to ItemWithIcon

Replace delegation with Inheritence

Replace Inheritence with delegation

Tools

• Refactoring can’t be fully automated– some refactoring steps are difficult to automate

• some extent supported by IDEs, – Eclipse, Netbeans, IntelliJ– no correctness theory that is also practical enough you

will have to rely on testing

34

Documents

Refactoring Compl. Bad smells in your software Code duplication Long operations, big classes Operations with lots of parameters Divergent or shotgun fixes