1. Principles and examples
Refactoring
Principles and examples

2. The goals of a module Functionality
The reason for the module's existance
Changeability
Most modules change during their lifetime
If it is hard to change, it is broken and should be fixed
Communicatability
Modules are read by developers
If a developer cannot understand what is happening without serious analysis and pondering, the module is broken and should be fixed

3. Definitions of refactoring
Altering the internal structure without affecting the external behavior
Robert C. Martin
A change made to the internal structure of sofware to make it easier to understand and chepaer to modify without changing its observable behavior
Martin Fowler
To restructure software by applying a series of refactorings without changing its observable form

4. Why refactor? Refactoring improves the design of software
Designs decay over changes
Code loses its structure
Negative spiral
Reducing the amount of code
Less code is always better
Refactoring makes software easier to understand
Other people can easier understand well-structured code
You, yourself can easier understand well-structured code
Refactoring helps you find bugs
Understanding code makes it easier to see problems and errors
“I'm not a great programmer, I'm just a good programmer with great habits”
Kent Beck
Refactoring helps you program faster
Good design makes it easier to develop faster

5. When refactor? Refactor when you add function Refactor first
Add new functionality then (in a “green” mode)‏
Refactor when you fix a bug
Obviously the code wasn't good enough to see the bug in the first place
Refactor when doing code reviews
It might be clear to you, but not to others
Pair programming is code review

6. Bad smells in code Duplicated code Long method Large class
Long parameter list
Divergent change
Shotgun surgery
Feature envy
Data clumps
Primitive obsession
Switch statements
Parallel inheritance structures
Lazy class
Speculative generality
Temporary field
Message chains
Middle man
Inappropriate intimacy
Alternative classes with different interfaces
Incomplete library class
Data class
Refused bequest
Comments

7. Bad smells and how to sniff them out
Duplicated code
Same code more than once
Long method
Too many LOC
Large class
Too many instance variables
Long parameter list
Usually bad in an OO environment
Divergent change
Many changes affect same class
Shotgun surgery
One change alters many classes
Feature envy
A method often accesses another class's data
Data clumps
Data that always is used in clumps shuold be together
Primitive obsession
Too much use of built-in types
Switch statements
In OO, inheritance is preferred
Parallel inheritance structures ??

8. Bad smells and how to sniff them out (cont'd)‏
Lazy class
Classes that don't do much
Speculative generality
Hooks for possible future additions
Temporary field
Instance variables that are only used occasionally
Message chains
t.get().get().get().get()‏
Middle man
Delegating to much
Inappropriate intimacy
Classes peek and poke at private parts
Alternative classes with different interfaces
Methods do the same, but have different names
Incomplete library class
You only use parts of a library
Data class
Data + get + set only
Refused bequest
Subclasses only uses parts of what is inherited
Comments
Might be there because the code is impossible to understand without them

9. Refactorings Patterns for refactoring code Name Summary Motivation
Mechanics
Examples

10. Composing methods Extract method Block of code --> method
Inline method
Method --> block of code
Inline temp
Remove temp variable
Replace temp with query method
Removing temp variables, making their computation a method
Replace method with method object
Complicated method --> object with several methods
Introduce explaining variable
Complex expressions are easier to understand with some variables with good names
Split temporary variable
Don't use same variable for different semantics

11. Composing methods (cont'd)‏
Remove assignments to parameters
Instead of changing a parameters value, copy it and change
Substitute algorithm
Bad algorithm --> good algorithm

12. Moving features between objects
Move methods
a.method() --> b.method()‏
Move field
a.aField --> b.aField
Extract class
One class with two responsibilities --> two classes with one resp. each
Inline class
Two classes with one resp. each --> One class with two responsibilities
Hide delegate
a.getB().getC() --> a.getC()‏
Remove middle man
a.getC() --> a.getB.getC()‏

13. Organizing data Self encapsluate field
Getters for private data in own class
Replace data with object
Dumb data --> articluate object
Change value to reference
Factory method
Change reference to value
opposite
Replace array with object
a[0]=”name”, a[1]=”address” --> o.name(“name”), o.address(“address”)‏
Replace magic number with symbolic constant
> Gravitation =9.81
Encapsulate field
public int x --> private int x, getx, setx

14. Making method calls simpler
Rename method
Unreadable --> readable
Add parameter
method() --> method(param)‏
Remove parameter
method(param) --> method()
Separate query from modifier
Procedure vs function
Parametereize method
multiplyByTen, multiplyByFive --> multiply(factor)‏
Preserve whole object
f(o.getX()), g(o.getY()) --> fg(o)‏

15. Making method calls simpler (cont'd)‏
Introduce parameter object
printdate(year, month, day) --> printdate(dateobject)‏
Replace parameter with method
o.doStuff(thing, getSomething()) --> o.doStuff(thing)‏
Replace parameter with explicit methods
setvalue(whatToSet, value) --> setvalue1, setvalue2
Remove setting method
o.initializeX() --> done in constructor
Hide method
Make methods not used by others private
Encapsulate downcast
a = (realType) b.getStuff() --> a = b.getrealStuff()‏
Replace exception with test
Test before is better than test after

16. Dealing with generalization
Pull up field
Subclasses have same field --> superclass has it instead
Pull up method
dito
Push down field
Some subclasses uses a field i superclass --> put them there
Push down method
Dito
Extract superclass
Two classes have something in common --> put in superclass and subclass both from it
Extract interface
Parts of classes common --> make it an interface
Collapse hierarchy
Subclass and superclass are similar --> make them one

17. Dealing with generalization
Replace inheritance with delegation
Only parts of superclass is used --> delegate instead
Replace delegation with inheritance
To many delegation methods to same object --> super/subclass