Software Design and

Architecture

Fakhar Lodhi
Topics Covered: 083 – 092
Refactoring – Part I
Software Design and
Architecture
Topic#083
Refactoring Introduction
What is Refactoring?
• Refactoring is the process of changing a
software system such that:
• the external behavior of the system does not
change
• the internal structure of the system is
improved
• This is sometimes called “Improving the design
after it has been written”
3
 Why is Refactoring Useful?
• The idea behind refactoring is to acknowledge that
it will be difficult to get a design right the first time
• as a program’s requirements change, the design may
need to change
• refactoring provides techniques for evolving the design
in small incremental steps

5
Refactoring Benefits
• 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.

6
Refactoring Benefits
• 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 progress
7
Software Design and
Architecture
Topic#083

END!
Software Design and
Architecture
Topic#084
Refactoring – A simple example
 A (Very) Simple Example
Consolidate Duplicate Conditional Fragments
if (isSpecialDeal()) {
if (isSpecialDeal())
total = price * 0.95;
total = price * 0.95;
send ();
else
} total = price * 0.98;
else {
total = price * 0.98; send ();
send ();
}
10
 A (Very) Simple Example
Better Still

if (isSpecialDeal()) if (isSpecialDeal())
total = price * 0.95; factor = 0.95;
else else
total = price * 0.98; factor = 0.98;

send (); total = price * factor;

send ();
11
Software Design and
Architecture
Topic#084

END!
 Software Design and
Architecture
Topic#085
Refactoring vs Rewriting and optimization
Refactoring versus Rewriting
•Code has to work mostly correctly
before you refactor.
•If the current code just does not
work, do not refactor.
•Rewrite instead!
14
Optimization versus
Refactoring
• The purpose of refactoring is
• to make software easier to understand and
modify
• Performance optimizations often involve
making code harder to understand (but
faster!)

15
Optimization versus Refactoring
for (i=0; i < N; i++) if (cond1) {
{ for (i=0; i < N; i++) {
//1…
// condition does not // xyz
// change inside the }
else if (cond2) {
// loop
for (i=0; i < N; i++) {
//2…
if (cond1) {//1…} // xyz
}
else if (cond2) {//2…} else if (cond2) {
else {//3…} for (i=0; i < N; i++) {
//2…
// xyz // xyz
} }
} 16
Software Design and
Architecture
Topic#085

END!
Software Design and
Architecture
Topic#086
Making Refactoring Safe
How do you make
refactoring safe?
1. use refactoring “patterns”
• Fowler’s book assigns “names” to
refactorings in the same way that the GoF’s
book assigned names to patterns

19
How do you make
refactoring safe?
2. Test constantly!
• This ties into the extreme programming paradigm,
you 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 20
Software Design and
Architecture
Topic#086

END!
Software Design and
Architecture
Topic#087
Code Smells – Bad smells in code
Refactoring: Where to Start?

•How do you identify code that needs to

be refactored?
• “Bad Smells” in Code

23
 “if it stinks, change it”
Grandma Beck, discussing child-rearing philosophy

Nothing but good design principles or lack thereof!

22 Bad smells listed in Fowler’s book

24
Categories of bad smells
•Bloaters (5)
•Object-orientation abusers (4)
•Change preventers (3)
•Dispensables (5)
•Couplers (5)
Software Design and
Architecture
Topic#087

END!
Software Design and
Architecture
Topic#088
Code Smells – Bloaters
Bloaters (5)
• Bloaters are code, methods and classes that have
increased to such enormous proportions that they
are hard to work with.

• Usually these smells do not crop up right away,

rather they accumulate over time as the program
evolves (and especially when nobody makes an
effort to eradicate them).
Bloaters (5)
•Long method
•Long class
•Primitive obsession
•Long parameter list
•Data Clumps
•Long Method
• long methods are more difficult to
understand
• performance concerns with respect to lots
of short methods are largely obsolete

30
• Large Class
• Large classes try to do too much, which
reduces cohesion
• violates SRP
• Long Parameter List
• hard to understand, can become inconsistent
• Symptom of behavioral form of god class
31
• Data Clumps
• attributes that clump together but are not part
of the same class
• Lack of cohesion – SRP

• Primitive Obsession
• characterized by a reluctance to use classes
instead of primitive data types

32
Software Design and
Architecture
Topic#088

END!
 Software Design and
Architecture
Topic#089
Code Smells – Object-orientation abusers
Object-orientation Abusers (4)
• Incomplete or incorrect application of object-
oriented programming principles

• Switch statement
• Temporary field
• Refused bequest
• Alternative classes with different interfaces
• Switch Statements
• Switch statements are often duplicated in
code; they can typically be replaced by use of
polymorphism (let OO do your selection for
you!)
• Typically a place where strategy or state pattern
should have been used
• Temporary Field
• An attribute of an object is only set in certain
circumstances; but an object should need all
of its attributes
• Refused Bequest
• A subclass ignores most of the functionality
provided by its superclass
• violates LSP

• Alternative Classes with Different Interfaces

• Symptom: Two or more methods do the same
thing but have different signature for what
they do
Software Design and
Architecture
Topic#089

END!
Software Design and
Architecture
Topic#090
Code Smells – Change Preventers
Change Preventers (3)
• These smells mean that if you need to change
something in one place in your code, you have to
make many changes in other places too.
• Program development becomes much more
complicated and expensive as a result.

• Divergent change
• Shotgun surgery
• Parallel inheritance hierarchies
• Divergent Change
• Deals with cohesion; symptom: one type of
change requires changing one subset of
methods; another type of change requires
changing another subset
• violates SRP

• Shotgun Surgery
• a change requires lots of little changes in a lot
of different classes
• Parallel Inheritance Hierarchies
• Similar to Shotgun Surgery; each time I add a
subclass to one hierarchy, I need to do it for all
related hierarchies
Software Design and
Architecture
Topic#090

END!
Software Design and
Architecture
Topic#091
Code Smells – Dispensables
Dispensables (5)
• A dispensable is something pointless and unneeded
whose absence would make the code cleaner, more
efficient and easier to understand.

• Comments
• Duplicated code
• Lazy class
• Data class
• Speculative generality
• Comments (!)
• Comments are sometimes used to hide bad code
• “…comments often are used as a deodorant” (!)
• Duplicated Code
• bad because if you modify one instance of
duplicated code but not the others, you (may)
have introduced a bug!
• Lazy Class
• Each class costs money to maintain and
understand.
• A class that no longer “pays its way”
• e.g. may be a class that was downsized by
refactoring, or represented planned
functionality that did not pan out
• Data Class
• These are classes that have fields, getting and
setting methods for the fields, and nothing else;
they are data holders, but objects should be about
data AND behavior
• Symptom of data form of god class

• Speculative Generality
• “Oh I think we need the ability to do this kind of
thing someday”
Software Design and
Architecture
Topic#091

END!
Software Design and
Architecture
Topic#092
Code Smells – Couplers
Couplers (5)
• All the smells in this group contribute to excessive
coupling between classes or show what happens if
coupling is replaced by excessive delegation.

• Feature envy
• Inappropriate intimacy
• Message chain
• Middle man
• Incomplete library class
• Feature Envy
• A method requires lots of information from
some other class (move it closer!)
• Symptom of behavioral form of god class

• Inappropriate Intimacy
• Pairs of classes that know too much about
each other’s private details
• Message Chains
• a client asks an object for another object and
then asks that object for another object etc.
Bad because client depends on the structure
of the navigation
• violates LoD
• Middle Man
• If a class is delegating more than half of its
responsibilities to another class, do you really
need it?

• Incomplete Library Class

• A framework class doesn’t do everything you
need
Software Design and
Architecture
Topic#092

END!