Refactoring

Refactoring
Ricardo Terra
rterrabh [at] gmail.com
Ricardo Terra (rterrabh [at] gmail.com) Refactoring Janeiro, 2014 1 / 46

CV
Nome: Ricardo Terra
Email: rterrabh [at] gmail.com
www: ricardoterra.com.br
Twitter: rterrabh
Lattes: lattes.cnpq.br/ 0162081093970868
Ph.D. (UFMG/UWaterloo),
Post-Ph.D. (INRIA/Université Lille 1)
Background
Education: UFLA (since 2014), UFSJ (1 year), FUMEC (3 years), UNIPAC (1 year), FAMINAS (3 years)
Work Experience: DBA Eng. (1 year), Synos (2 years), Stefanini (1 year)

Agenda
1 Overview
2 Refactoring
3 Refactoring & Agile Methodologies
4 Final Considerations

Overview

Overview – What is it?
Process of changing a computer program’s source code
without modifying its external functional behavior
To improve some of the nonfunctional attributes:
code readability
reduced complexity to improve maintainability
better design =⇒ extensibility

Overview – What is it?
“By continuously improving the design of code, we make
it easier and easier to work with. This is in sharp contrast
to what typically happens: little refactoring and a great
deal of attention paid to expediently adding new features. If
you get into the hygienic habit of refactoring continuously,
you’ll ﬁnd that it is easier to extend and maintain code.”
— Joshua Kerievsky [Refactoring to Patterns]

Overview – History of Use
In the past, refactoring was not a common practice in
development processes
For example, CVS (created in 1984) does not version the
moving or renaming of ﬁles and directories
Nowadays, refactoring is one fundamental technique
adopted in agile methodologies1
eXtreme Programming, Scrum, etc.
1
I’ll discuss about it later...

Overview – When do I use?
Bad smells!
A structure in the code suggests, and sometimes even
scream for, opportunities for refactoring
This humorous advice rely on the experience of programmers
and on the clarity of code
Indications to possible bad smells:
Duplicated code →
Long method →
Large class →
Long parameter list →
...

Bad smells!
Duplicated code → share one same method
Long method →
Large class →
...

Bad smells!
Long method → extract one or more smaller methods
Large class →
...

Bad smells!
Large class → divide in more cohesive classes
...

Bad smells!
Large class → divide in more cohesive classes
Long parameter list → encapsulate them
...

Refactoring

Refactoring
There is a almost a hundred catalogued refactorings
each one has a name, a motivation, and a mechanics
They are usually organized into the following groups:
Composing Methods (e.g., Extract Method)
Moving Features Between Objects (e.g., Move Method)
Organizing Data (e.g., Encapsulate Field)
Simplifying Conditional Expressions (e.g., Consolidate Conditional Expression)
Making Method Calls Simpler (e.g., Rename Method)
Dealing with Generalization (e.g., Pull Up Method)
Big Refactorings (e.g., Extract Hierarchy)

Refactoring
In this section, we will explain some refactorings and show
an example of its usage
We have chosen the popular refactorings, more speciﬁcally,
refactorings that Eclipse IDE has already automated:
Extract Method
Pull Up Method
Move Method
Extract Superclass
Introduce Parameter Object

Extract Method

Refactoring #1 – Extract Method
You have a code fragment that can be grouped together
⇓
Turn the fragment into a method whose name explains the
purpose of the method

Refactoring #1 – Extract Method – Theoretical Example
1 void printOwing (double amount) {
2 printBanner ( ) ;
3
4 // print details
5 System . out . p r i n t l n ( "name: " + t h i s .name) ;
6 System . out . p r i n t l n ( "amount: " + amount ) ;
7 }

Refactoring #1 – Extract Method – Theoretical Example
2 printBanner ( ) ;
3
4 // print details
7 }
⇓
2 printBanner ( ) ;
3 printDetails (amount ) ;
4 }
5
6 void printDetails (double amount) {
9 }

Refactoring #1 – Extract Method – Motivation
It is one of the most common refactorings
Long methods or look at code that needs a comment to
understand its purpose
So, I turn that fragment of code into its own method.
Reasons to do that:
Increases the chances that other methods can use a method
when the method is ﬁne-grained
Allows the higher-level methods to read more like a series of
comments
Overriding also is easier

Refactoring #1 – Extract Method – Practice

Pull Up Method

Refactoring #2 – Pull Up Method
You have methods with identical results on subclasses
⇓
Move them to the superclass

Refactoring #2 – Pull Up Method – Theoretical Example

Refactoring #2 – Pull Up Method – Theoretical Example
⇒

Refactoring #2 – Pull Up Method – Motivation
Eliminating duplicate behavior is important
if not, the risk that a change to one not be made to other
The easiest case: methods have the same body
of course it is not always obvious as that. So, look for the
differences and test for safety
Special case: you have a subclass method that overrides a
superclass method yet does the same thing (WDF?)
The most awkward case: the method may refer to features
that are on the subclass but not on the superclass
possible solutions: generalize methods, create abstract
method on superclass, change a method’s signature...

Refactoring #2 – Pull Up Method – Practice

Move Method

Refactoring #3 – Move Method
A method is, or will be, using or used by more features of another
class than the class on which it is deﬁned
(Feature Envy)
⇓
Create a new method with similar body in the class it uses most.
Either turn the old method into a simple delegation, or remove it

Refactoring #3 – Move Method – Theoretical Example

Refactoring #3 – Move Method – Theoretical Example
⇒

Refactoring #3 – Move Method – Motivation
Moving methods is the bread and butter of refactoring
classes with too much behavior
classes are collaborating too much (too highly coupled)
By moving methods around:
make classes simpler
high cohesion (classes end up being a more crisp implementation of a set of responsibilities)

Refactoring #3 – Move Method – Practice

Extract Superclass

Refactoring #4 – Extract Superclass
You have two classes with similar features
⇓
Create a superclass and move the common features to the
superclass

Refactoring #4 – Extract Superclass – Theoretical Example

Refactoring #4 – Extract Superclass – Theoretical Example
⇓

Refactoring #4 – Extract Superclass – Motivation
Duplicate code is one of the principal bad things in systems
Duplicate code:
two classes that do similar things in the same way or
two classes that do similar things in different ways
A well-known solution: inheritance (everything)
However, you often do not notice the commonalities until you
have created some classes
In this case, you need to create the inheritance structure later

Refactoring #4 – Extract Superclass – Practice

Introduce Parameter Object

Refactoring #5 – Introduce Parameter Object
You have a group of parameters that naturally go together
⇓
Replace them with an object

Refactoring #5 – Introduce Parameter Object – Theoretical
Example

Refactoring #5 – Introduce Parameter Object – Theoretical
Example
⇓

Refactoring #5 – Introduce Parameter Object – Motivation
Often you see a particular group of parameters that tend to
be passed together
It is worthwhile to turn these parameters into objects just to
group the data together
It is useful because it reduces the size of the parameter lists,
and long parameter list are hard to understand
Deeper, when you do this refactoring, you can see common
manipulations of the parameter values
By moving this behavior into the new object, you can remove
a lot of duplicated code

Refactoring #5 – Introduce Parameter Object – Practice
rename as well?

Refactoring & Agile Methodologies

Refactoring & Agile Methodologies – XP
eXtreme Programming (XP)
XP prescribes several engineering practices:
TDD (automated testing), Pair programming, Simple design,
and Refactoring (mercilessly)

Refactoring & Agile Methodologies – XP
eXtreme Programming (XP) — Collective Code Ownership

Refactoring & Agile Methodologies – Scrum
Scrum
Scrum, on the other hand, does not prescribe engineering
practices
But, it does not mean you can’t use TDD, PP, Refactoring, etc.
I.M.H.O, Scrum solely does not make their usage mandatory

Final Considerations

Final Considerations – Why should I refactor?
Improves the design of software
Loss of the structure (mostly by changes) has a cumulative effect
Regular refactorings helps code retain its shape
Makes software easier to understand
when you refactor, your code is more readable
Helps you find bugs
when you refactor, you understand what the code does, and
put that understanding right back into the code
Helps you program faster (does it sound counterintuitive?)
without a good design, you spend time finding and fixing
bugs instead of adding new functions

Final Considerations – Refactoring vs Performance Optimization
Like refactoring, performance optimization does not change
the behavior of a component (other that its speed)
Indeed, it only alters the internal structure
However, the purpose is different
Refactoring: software easier to understand and modify
Performance Optimization: often makes code harder to
understand and modify
but you get the performance you need

Final Considerations – When should I refactor?
“Refactoring is something you do all the time in little bursts. You
don’t decide to refactor, you refactor because you want to do
something else, and refactoring helps you do that other thing.”
— Martin Fowler [Refactoring: Improving the Design of Existing Code]

References
William Opdyke. Refactoring object-oriented frameworks.
Ph.D. thesis, University of Illinois at Urbana-Champaign, 1992.
Martin Fowler et al. Refactoring: Improving the Design of
Existing Code. Addison Wesley, 1999.
Joshua Kerievsky. Refactoring to Patterns. Addison Wesley,
2004.
Ken Schwaber and Jeff Sutherland. The Scrum Guide. 2011.
Available at: http://www.scrum.org.
Don Wells. Extreme Programming: A gentle introduction.
2011. Available at: http://www.extremeprogramming.org.

Thanks a lot!!!
This presentation and the Eclipse Java project are publicly available at:
www.ricardoterra.com.br/public

Refactoring

More Related Content

What's hot (20)

Viewers also liked (11)

Similar to Refactoring (20)

More from Ricardo Terra (20)

Recently uploaded (20)

Refactoring