1. Refactoring II
5-Feb-19

2. Books I
Design Patterns is the classic book by “the Gang of Four”: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Basically a catalog of program organizations
Reading it is rather like reading a dictionary
Although equally applicable to Java, the examples are in C++
Head First Design Patterns by Elizabeth Freeman
Fun, irreverent, and entertaining
IMHO the best book for developing an understanding of what design patterns are all about

3. Books II
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J. Brown, Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray
Describes bad patterns and how to fix them
More fun to read than the Gang of Four book
Refactoring: Improving the Design of Existing Code by Martin Fowler, with contributions from Kent Beck and others
Very clear, plenty of useful ideas, very readable
Much of this lecture will be based on this book

4. Design Patterns and Refactoring
Design Patterns describe good solutions to common (or at least, not extremely rare) design problems
Design Patterns are always specified in UML
Model-View-Controller is a very common Design Pattern
An Antipattern is a common, but poor, Design Pattern
Antipatterns can be refactored into better designs
Refactoring is rearranging existing code while maintaining the same functionality
Refactoring is usually done in terms of applying some Design Pattern

5. UML review I Key: Example: Name of the class Variables [optional]
Card
cardId:int
-copy:boolean=false
«constructor» Card(int id)
+isKind(desiredKind:int)
+isSharable():boolean
+toString():String
Example:
Name of the class
Variables [optional]
Methods
Key:
+ means public visibility
# means protected visibility
- means private visibility
<blank> means default (package) visibility
static variables are underlined

6. UML review II A B A B C D Factory Product creates 1..4
Class B extends class A A B
Class B implements interface A C D
1..4
Class C contains 1 to 4 objects of class D
Factory
Product
creates
Other kinds of relations

7. Bad smells Where did this term come from?
“If it stinks, change it.” Grandma Beck, discussing child-rearing philosophy
The basic idea is that there are things in code that cause problems
Duplicated code
Long methods
Etc.
A common reason for refactoring is that you need to add features that don’t fit well with the existing design
Any time you change working code, you run the risk of breaking it
A good test suite makes refactoring much easier and safer

8. An example Some time ago I was working on code to evaluate expressions
Expressions can be parsed into a tree structure + 2 * 5 x
Tree for * x
Now what?
You could walk the tree and, at each node, use a switch statement to do the right thing
Adding a new operator requires modifying existing code
I “discovered” a better solution
Command
lhs:Command
rhs:Command value:int
evaluate():int
0..2

9. Using my “Command” pattern
class Add implements Command { int evaluate( ) { int v1 = lhs.evaluate().value; int v2 = rhs.evaluate().value; value = v1 + v2; return value; } }
Command
lhs:Command
rhs:Command value:int
evaluate():int
0..2
To evaluate the entire tree, evaluate the root node
To add an operator, add another class that extends Command
This is just a rough description; there are a lot of other details to consider
Some operands are unary
You have to look up the values of variables
Etc.

10. Duplicated code I
If the same code fragment occurs in more than one place within a single class, you can use Extract Method
Turn the fragment into a method whose name explains the purpose of the method
Any local variables that the method requires can be passed as parameters (if there aren’t too many of them!)
If the method changes a local variable, see whether it makes sense to return that as the value of the method (possibly changing the name of the method to indicate this)
If the method changes two or more variables, you need other refactorings to fix this problem

11. Duplicated code II
If the same code fragment occurs in sibling classes, you can use Extract Method in both classes, then use Pull Up Method
Use ExtractMethod in each class
Be sure the code is identical
If necessary, adjust the method signatures to be identical
Copy the extracted method to the common superclass
Delete one subclass method
Compile and test
Delete the other subclass method

12. Duplicated code III
If the same code fragment occurs in unrelated classes, you can use Extract Method in one class, then:
Use this class as a component in the other class, or
Invoke the method from the other class, or
Move the method to a third class and refer to it from both of the original classes
In any case, you need to decide where the method makes most sense, and put it there
Eclipse has an Extract method... command that does most of this work for you

13. Duplicated code IV
If almost the same code fragment occurs in sibling classes, use Extract Method to separate the similar bits from the different bits, and use Form Template Method
I’ll give an example in a moment

14. The Template Method
Template Methods lead to an inverted control structure
A superclass calls methods in its subclass
Template methods are so fundamental that they can be found in almost every abstract class
Template Method uses inheritance
A similar pattern, Strategy Pattern, uses delegation rather than inheritance

15. Big fish and little fish
The scenario: “big fish” and “little fish” move around in an “ocean”
Fish move about randomly
A big fish can move to where a little fish is (and eat it)
A little fish will not move to where a big fish is
Here’s the initial code (before refactoring):
BigFish
move()
<<abstract>>Fish
<<abstract>>move()
LittleFish

16. The move() method General outline of the method:
public void move() { choose a random direction; // same for both find the location in that direction; // same for both check if it’s ok to move there; // different if it’s ok, make the move; // same for both }
To do the Form Template Method:
Extract the check on whether it’s ok to move
In the Fish class, put the actual (template) move() method
Create an abstract okToMove() method in the Fish class
Implement okToMove() in each subclass

17. The Fish refactoring
BigFish
move()
<<abstract>>Fish
<<abstract>>move()
LittleFish
Note how this works: When a BigFish tries to move, it uses the move() method in Fish
But the move() method in Fish uses the okToMove(locn) method in BigFish
And similarly for LittleFish
BigFish
okToMove(locn):boolean
<<abstract>>Fish
move()
<<abstract>>okToMove(locn):boolean

18. The resultant code In Fish: In BigFish and in LittleFish:
public void move() { choose a random direction; // same for both find the location in that direction; // same for both check if it’s ok to move there; // same for both if it’s ok, make the move; // same for both }
abstract boolean okToMove(locn);
In BigFish and in LittleFish:
boolean okToMove(locn) { code for this kind of fish }

19. To be continued...