13-Jul-15 Refactoring II

Books Design Patterns is the classic book by 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++ 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 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

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

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

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

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

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

Using my “ Command ” pattern class Add extends Command { int evaluate( ) { int v1 = lhs.evaluate().value; int v2 = rhs.evaluate().value; value = v1 + v2; return value; } } To evaluate the entire tree, evaluate the root node 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. Command lhs:Command rhs:Command value:int evaluate():int 0..2

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

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 Compile and test

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

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’ve done this one recently, and it makes a good example

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

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 BigFish move() Fish > move() LittleFish move()

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 } My solution: 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

The Fish refactoring BigFish move() Fish > move() LittleFish move() BigFish okToMove(locn):boolean Fish move() > okToMove(locn):boolean BigFish okToMove(locn):boolean 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

To be continued...