EMOOSE 2001-2002 Object-Oriented Software E volution

1. EMOOSE 2001-2002Object-Oriented Software Evolution Advanced Issues in Refactoring Dr. Tom Mens tom.mens@vub.ac.be Programming Technology Lab http://prog.vub.ac.be Vrije Universiteit Brussel Pleinlaan 2 - 1050 Brussel Belgium

2. Advanced Issues in Refactoring • Categories of refactorings revisited • Detecting refactorings • Refactoring conflicts • UML refactoring • Refactoring tool support

3. Advanced Issues in Refactoring Part1 Categories of refactorings

4. Categories of refactorings according to [Fowler 1999] • small refactorings • (de)composing methods [9 refactorings] • moving features between objects [8 refactorings] • organising data [16 refactorings] • simplifying conditional expressions [8 refactorings] • dealing with generalisation [12 refactorings] • simplifying method calls [15 refactorings] • big refactorings • Tease apart inheritance • Extract hierarchy • Convert procedural design to objects • Separate domain from presentation

5. Categories of refactorings1. Small Refactorings a) (de)composing methods [9 refactorings] • Extract Method (see LAN CR3-step 2: isDestFor) • Inline Method • Inline Temp • Replace Temp With Query • Introduce Explaining Variable • Split Temporary Variable • Remove Assignments to Parameter • Replace Method With Method Object • Substitute Algorithm

6. Categories of refactorings1a (de)composing methods • Extract Method what: when you have a fragment of code that can be grouped together, turn it into a method with a name that explains the purpose of the method why: improves clarity, removes redundancy example: public void accept(Packet p) { if ((p.getAddressee() == this) && (this.isASCII(p.getContents())))this.print(p); else super.accept(p); } Mind local vars!!! public void accept(Packet p) { if this.isDestFor(p) this.print(p); else super.accept(p); } public boolean isDestFor(Packet p) { return ((p.getAddressee() == this) && (this.isASCII(p.getContents()))); }

7. Categories of refactorings1a (de)composing methods • Inline Method (opposite of Extract Method) what: when a method’s body is just as clear as its name, put the method’s body into the body of its caller and remove the method why: to remove too much indirection and delegation example: int getRating(){ return (moreThanFiveLateDeliveries()); } boolean more Than FiveLateDeliveries(){ return _numberOfLateDeliveries > 5; } int getRating(){ return (_numberOfLateDeliveries > 5); }

8. Order price() Order price() PriceCalculator primaryBasePrice secondaryBasePrice compute Categories of refactorings1a (de)composing methods • Replace Method With Method Object what: when you have local variables but cannot use extract method, turn the method into its own object, with the local variables as its fields why: extracting pieces out of large methods makes things more comprehensible example: 1 return new PriceCalculator(this). compute() double primaryBasePrice; double secondaryBasePrice; // long computation

9. Categories of refactorings1. Small Refactorings b) moving features between objects [8 refactorings] • Move Method • Move Field • Extract Class • Inline Class • Hide Delegate • Remove Middle Man • Introduce Foreign Method • Introduce Local Extension

10. Class 1 aMethod() Class 2 Class 1 Class 2 aMethod() Categories of refactorings1b moving features between objects • Move Method/Field what: when a method (resp. field) is used by or uses more features of another class than its own, create a similar method (resp. field) in the other class; remove or delegate original method (resp. field) and redirect all references to it why: essence of refactoring example:

11. Person name officeAreaCode officeNumber homeAreaCode homeNumber getOfficePhone getHomPhone Person name getOfficePhone getHomePhone PhoneNumber areaCode number getPhoneNumber Categories of refactorings1b moving features between objects • Extract Class what: when you have a class doing work that should be done by two, create a new class and move the relevant fields and methods to the new class why: large classes are hard to understand example: 1 phone 1

12. PhoneNumber areaCode number getPhoneNumber Person name getPhoneNumber Person name officeAreaCode officeNumber getPhoneNumber Categories of refactorings1b moving features between objects • Inline Class what: when you have a class that does not do very much, move all its features into another class and delete it why: to remove useless classes (as a result of other refactorings) example: officePhone 1 1

13. Person getDepartment() Department getManager() Person getManager() Department getManager() Categories of refactorings1b moving features between objects • Hide Delegate what: when you have a client calling a delegate class of an object, create methods on the server to hide the delegate why: increase encapsulation example: Client Class Client Class

14. Person getManager() Person getDepartment() Department getManager() Categories of refactorings1b moving features between objects • Remove Middle Man what: when a class is doing too much simple delegation, get the client to call the delegate directly why: to remove too much indirection (as a result of other refactorings) example: Client Class Client Class Department

15. Categories of refactorings1. Small Refactorings c) organising data [16 refactorings] • encapsulate field (see LAN CR1) • replace data value with object (see LAN CR4-step 1) • change value to reference • change reference to value • replace array with object • duplicate observed data • change unidirectional association to bidirectional • change bidirectional association to unidirectional

16. Categories of refactorings1. Small Refactorings c) organising data ctd. [16 refactorings] • replace magic number with symbolic constant • encapsulate collection • replace record with data class • replace type code with class/subclass/state/strategy • replace subclass with fields

17. Categories of refactorings1c organising data • Encapsulate field what: why: example: public String name; private String name;public String getName() { return this.name; }public void setName(String s) { this.name = s; }

18. Categories of refactorings1c organising data • Replace data value with object what: why: example: private String contents; public String getContents() { return this.contents; } public void setContents(String s) { this.contents = s; } private Document doc;public String getContents() { return this.doc.contents; }public void setContents(String s) { this.doc.contents = s; } public class Document { ... public String contents;}

19. Employee const Engineer=0 const Salesman=1 const Manager=2 type:Int Categories of refactorings1c organising data • Replace type code with subclasses what: an immutable type code affects the behaviour of a class example: Employee Engineer Salesman Manager

20. Employee const Engineer=0 const Salesman=1 const Manager=2 type:Int Categories of refactorings1c organising data • Replace type code with state/strategy • if subclassing cannot be used, e.g. because of dynamic type changes during object lifetime (e.g. promotion of employees) example: Employee EmployeeType Engineer Salesman Manager Makes use of state pattern or strategy pattern

21. Person sex: [M, F] Categories of refactorings1c organising data • Replace subclass with fields what: subclasses vary only in methods that return constant data solution: change methods to superclass fields and eliminate subclasses example: Person Male Female similar to replace inheritance with aggregation

22. Categories of refactorings1. Small Refactorings d) simplifying conditional expressions [8 refactorings] • decompose conditional • consolidate conditional expression • consolidate duplicate conditional fragments • remove control flag • replace nested conditional with guard clauses • replace conditional with polymorphism • introduce null objects • introduce assertion

23. Categories of refactorings1. Small Refactorings e) dealing with generalisation [12 refactorings] • push down method / field (see LAN CR2-step 2) • pull up method / field / constructor body (see LAN CR3-step 3) • extract subclass / superclass / interface • collapse hierarchy • form template method • replace inheritance with delegation (and vice versa) • see earlier example of matrices

24. Printserver print ASCIIPrinter print PSPrinter print Categories of refactorings1e dealing with generalization • Push Down Method Printserver ASCIIPrinter PSPrinter

25. Categories of refactorings1e dealing with generalization • Pull Up Method • simplest variant • look for methods with same name in subclasses that do not appear in superclass • more complex variant • do not look at the name but at the behaviour of the method • e.g. if a method in each sibling class makes a send to the same method • if the method that is being pulled up already exists in the superclass as an abstract method, make it concrete with the common behaviour

26. Printserver accept ASCIIPrinter accept PSPrinter accept Categories of refactorings1e dealing with generalization • Pull Up Method Printserver ASCIIPrinter PSPrinter

27. PrintServer Outputserver FileServer Printserver Fileserver Categories of refactorings1e dealing with generalization • Extract Superclass • when you have 2 classes with similar features

28. Categories of refactorings1. Small Refactorings f) simplifying method calls [15 refactorings] • rename method • add parameter • remove parameter • separate query from modifier • parameterize method • replace parameter with method • replace parameter with explicit methods • preserve whole object

29. Categories of refactorings1. Small Refactorings f) simplifying method calls ctd. [15 refactorings] • introduce parameter object • remove setting method • hide method • replace constructor with factory method • encapsulate downcast • replace error code with exception • replace exception with test

30. Customer Customer amountInvoicedIn(from:Date,to:Date) amountReceivedIn(from:Date,to:Date) amountOverdueIn(from:Date,to:Date) amountInvoicedIn(r:DateRange) amountReceivedIn(r:DateRange) amountOverdueIn(r:DateRange) Categories of refactorings1f simplifying method calls • Introduce Parameter Object • group parameters that belong together in a separate object

31. Categories of refactorings1f simplifying method calls • Replace Error Code with Exception what: when a method returns a special code to indicate an error, throw an exception instead why: clearly separate normal processing from error processing example: int withdraw(int amount) { if (amount > balance) return -1 else {balance -= amount; return 0} } void withdraw(int amount) throws BalanceException { if (amount > balance) throw new BalanceException(); balance -= amount; }

32. Categories of refactorings2. Big Refactorings • require a large amount of time (> 1 month) • require a degree of agreement among the development team • no instant satisfaction, no visible progress • different kinds • tease apart inheritance • extract hierarchy • convert procedural design into objects • separate domain from presentation • …

33. Categories of refactorings2a tease apart inheritance • Problem • a tangled inheritance hierarchy that is doing 2 jobs at once • Solution • create 2 separate hierarchies and use delegation to invoke one from the other • Approach • identify the different jobs done by the hierarchy • extract least important job into a separate hierarchy • use extract class to create common parent of new hierarchy • create appropriate subclasses • use move method to move part of the behaviour from the old hierarchy to the new one • eliminate unnecessary (empty) subclasses in original hierarchy • apply further refactorings (e.g. pull up method/field)

34. Window 1 WindowImpl Window Full Iconised XWin MSWin Full Iconised FullXWin FullMSWin IconXWin IconMSWin Categories of refactorings2a tease apart inheritance • Example • Related design patterns • Bridge • decouples an abstraction from its implementation so that the two can vary independently • e.g. see above; matrices – arrays; … • Strategy / Visitor / Iterator / State

35. Categories of refactorings2b extract hierarchy • Problem • an overly-complex class that is doing too much work, at least in part through many conditional statements • Solution • turn class into a hierarchy where each subclass represents a special case • Approach • create a subclass for each special case • use one of the following refactorings to return the appropriate subclass for each variation: • replace constructor with factory method - replace type code with subclasses - replace type code with state/strategy • take methods with conditional logic and apply replace conditional with polymorphism

36. Categories of refactorings2b extract hierarchy • Example • calculating electricity bills • lots of conditional logic to cover many different cases: • different charges for summer/winter • different billing plans for personal/business/government/… • different tax rates • reduced rates for persons with disabilities or social security Customer Billing Scheme 1

37. Categories of refactorings2c convert proc. design into objects • Problem • you have code written in a procedural style • Solution • turn the data records into objects, break up the behaviour, and move the behaviour to the objects • Used refactorings • extract method • move method • …

38. Categories of refactorings2d separate domain from presentation • Goal • change a two-tier design (user interface/database) into a a three-tier one (UI/business logic/database) • Solution • separate domain logic into separate domain classes • Used small refactorings • extract method • move method/field • duplicate observed data • …

39. Advanced Issues in Refactoring Part2 Detecting refactorings

40. Detecting refactorings • [Demeyer&al2000] automatically detects refactorings by comparing subsequent versions of a software system • identifying which refactorings have been applied during evolution helps us to understand • which part of the system has evolved • how the system has evolved • why the system has evolved (to a certain extent)

41. Detecting refactorings • What characteristics can be used as symptoms of refactorings? • Decrease in Method Size • symptom for the split of a method • Change in Class Size • symptom for the redistribution of instance variables and methods within the hierarchy (i.e., optimising class hierarchy) or for a shift of functionality to sibling classes (i.e., incorporating composition) • Change in inheritance relationships of a class • symptom for the optimisation of a class hierarchy

42. Detecting refactorings • Which metricscan be used to detect these symptoms? • Method size • number of message sends in method body (Mthd-MSG) • number of statements in method body (Mthd-NOS) • lines of code in method body (Mthd-LOC) • Class size • number of methods in a class (NOM) • number of instance variables in a class (NIV) • number of class variables in a class (NCV) • Inheritance relationships • depth of inheritance tree (DIT) • number of direct children (NOC) • number of (non-overridden) inherited methods (NMI) • number of overridden methods (NMO)

43. Detecting refactorings • Which heuristics can be defined using a combination of change metrics? • Split into superclass / Merge with superclass • searches for refactorings that optimise the class hierarchy (DIT(B’) > 0)  ( (NOM(B’) < 0)  ( NIV(B’) < 0)  ( NCV(B’) < 0) ) A’ A X B split B into X and B’ B’

44. Detecting refactorings • Which heuristics can be defined using a combination of change metrics? • Split into subclass / Merge with subclass • searches for refactorings that optimise the class hierarchy (NOC(A’)  0)  ( (NOM(A’) < 0)  ( NIV(A’) < 0)  ( NCV(A’) < 0) ) A’ A X B’ C’ B C split A into X and A’

45. Detecting refactorings • Which heuristics can be defined using a combination of change metrics? • Move to other class (superclass, subclass or sibling) • searches for refactorings that move functionality from one class to another • uses NOM, NIV, NCV, DIT, NOC • Split method / Factor out common functionality • searches for refactorings that split methods into one or more methods defined on the same class • uses Mthd-MSG, Mthd-NOS, Mthd-LOC

46. Detecting refactorings • approach validated on three OO frameworks • SmallTalk VisualWorks • HotDraw • Refactoring Browser • e.g. a “move to sibling class” that introcudes layers was detected

47. Detecting refactorings Refactoring Browser Navigator circular dependency Browser Navigator ... ... Refactoring Browser Navigator layer Browser Navigator ... ...

48. Detecting refactorings • Advantages • concentrates on the relevant parts (the refactorings indicate those places where the design is expanding or consolidating) • amount of classes and methods returned is small enough to allow for further manual examination • reliable: low number of false positives, and a considerable amount of false positives is interesting anyway • unbiased: heuristics do not require human knowledge to select the interesting pieces of code • Disadvantages • Vulnerable to renaming • Imprecise when too many changes have been applied • Requires experience • Need for considerable resources

49. Advanced Issues in Refactoring Part3 Refactoring conflicts

50. Refactoring conflicts • Refactorings can lead to conflicts when upgrading an object-oriented framework Framework version 1 Framework version 2 framework upgrading (evolution or refactoring) framework extension or customisation Extended or customised framework