Software design: Lecture 45 - Sheraz Pervaiz

1

Software Design
Lecture : 45


2

Refactoring


3

Refactoring Overview
 Refactoring is a disciplined technique for restructuring an 
existing  body  of  code,  altering  its  internal  structure 
without changing its external behavior

 Its  heart  is  a  series  of  small  behavior  preserving 
transformations. 
'refactoring') 

Each 

does 

transformation 

little, 

but 

a 

(called 

sequence 

transformations can produce a significant restructuring

a 
of 


4

Smells are Problem
 Smells  (especially  code  smells)  are  warning  signs  about 
potential  problems  in  code.  Not  all  smells  indicate  a 
problem, but most are worthy of a look and a decision.
 Smells  usually  describe  localized  problems.  It  would  be 
nice  if  people  could  find  problems  easily  across  a  whole 
system.  But  humans  aren't  so  good  at  that  job;  local 
smells work with our tendency to consider only the part 
we're looking at right now


5


6

Applying Refactoring
 We try to select refactoring that improve the code in each 
trip through the cycle. Because none of the steps change 
the program's observable behavior, the program remains 
in  a  working  state.  Thus,  the  cycle  improves  code  but 
retains  behavior.  The  trickiest  part  of  the  whole  process 
is identifying the smell


7

Measured Smells
i.

They're dead easy to detect.

ii. They're objective (once you decide on a way to 
count  and  a  maximum  acceptable  score). 
They're horrible. And, they're common.
iii. We  can  think  of  these  smells  as  being  caught 
by  a  software  metric.  Each  metric  tends  to 
catch  different  aspects  of  why  code  isn't  as 
good as it could be


8

Refactoring and Design Patterns
  The  process  of  improving  the  design  of  existing 

code  ­­  with  patterns,  the  classic  solutions  to 
recurring design problems


9

Defining Anti­Patterns
Jim Coplien:

“Something that looks like a good idea, but 
which  backfires badly when applied.”


10

Anti­Pattern
 The term was coined in 1995 by Andrew Koenig,
 

    inspired by Gang of Four's book Design Patterns, which 
developed the concept of design patterns in the software 
field.

 The term was widely popularized three years later by the 
book AntiPatterns,  which  extended  the  use  of  the  term 
beyond  the  field  of  software  design  and  into 
general social interaction


11

Motivation for Anti­Patterns
 These are the application of such a pattern  that may be 
commonly 

used 

but 

is 

ineffective 

and/or 

counterproductive in practice for that particular scenario.
 The  AntiPattern  may  be  the  result  of  a  manager  or 
developer  not  knowing  any  better,  not  having  sufficient 
knowledge  or  experience  in  solving  a  particular  type  of 
problem,  or  having  applied  a  perfectly  good  pattern  in 
the wrong context.


12

Famous Known Anti­Patterns
i.

Patterns Fetish

ii. The Swiss­Army Knife
iii. The Crystal Ball
iv. The God Class
v. Abstraction inversion


13

1. Patterns Fetish or Pattern 
Craze
Unreasonable and excessive use of design
 patterns
Designer looks for places to use patterns


14

Suppose we want to print hello 
world


15


16


17

What are we doing !!!!!!

 Look at the design problem

 Select ONLY those patterns that address the 
current problem

 Favor simple solutions – Keep it Simple


18

Simple Possible Solution


19

2. Swiss Army Knife
• Occurs when …
i. You have more interfaces than classes
ii.The  number  of  interfaces  on  a  class  produce  a 
severe case of instability


20

Swiss­Army Knife
A Basic Litmus­Test
Do your classes implement more than 3 
interfaces?

21

Sample Code


22

Points to Understand
i.

More != Better

ii. Too many interfaces creates confusion
iii. Maintenance problems
iv. Each interface requires implementation of 
items on that interface
v. Do your classes actually need to share an
       interface?


23

Improvements
MaybeyourclassneedstoUSEanotherclass
Aggregation,Composition

ConsidertheFaỗadedesignpattern
Faỗadeselectsinnerobjectstodothework

24

3. The Crystal Ball
i.

Designing for the unknown or future potentials 
Little to no justification

ii. Design reaches out too far and assumes too
       much


25