1. Introduction to Refactoring Jim Cooper Falafel Software

2. Refactoring Refactoring. Improving the Design of Existing Code Martin Fowler 2000, Addison-Wesley ISBN 0-201-48567-2 We will use that terminology, guidelines and naming

3. What is Refactoring? “Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improves its internal structure.” Term applies both to the process and the individual techniques

4. What is Refactoring? - 2 Each refactoring is a series of steps Each step is simple and small Minimises introduction of new bugs Unit tests used to verify changes Behavioural changes to a program are not refactorings

5. Why Refactor? Code is not for computers to read, it’s for us to read 90% of the lifetime of most software is in maintenance mode Source code must be easy for humans to read, understand and modify Refactoring helps make the code more usable by programmers

6. Aims of Refactoring Improved design Make code easier to understand Can use it on other people’s code Help find bugs Faster programming in the long term Formalise and name best practices Easier to talk about Reduce chaos in long-lived code

7. Opportunities for Refactoring When adding functionality Make adding new feature easier Keep refactoring separate, though When fixing a bug During a code review Pair programming Refactoring takes time Sneak it past managers

8. Refactoring Techniques Too many to look at all of them Will not discuss unit testing in detail Start with the main ones, and then browse the book looking at others No need to read the book cover to cover (it’s not that interesting)

9. Points to Note Refactoring relies heavily on having object oriented code Refactorings are usually more atomic than patterns, but some use patterns Often language dependent Refactoring book is very Java oriented We will cover converting to Delphi Not many refactorings use interfaces

10. Points to Note - 2 Many refactorings make use of other, simpler refactorings Some are opposites Use the one that makes your code easier to understand Can apply some mechanically It is possible to go too far!

11. Extract Method Probably the most used technique You should have done this many times yourself Identify code to reuse, or that is making a method too long, so we make a new method out of it Difference here is the formal definition of the process, and the guidelines for its use

12. Structure of Extract Method Name – Extract Method Summary – describes when to use You have a code fragment that can be grouped together Turn the fragment into a method whose name explains the purpose of the method

13. Structure of Extract Method - 2 Short code example Motivation Describes why the refactoring should be done, and also when it shouldn’t Mechanics Step by step instructions One or more longer examples, usually with discussion

14. Structure of Extract Method - 3 Motivation A method is too long A section of code needs a comment to explain it Short (well-named) methods easier to reuse and override Higher-level methods easier to read Good naming is key

15. Structure of Extract Method - 4 Mechanics Create a new method with a good name Copy extracted code to new method Deal with variables and parameters in the original method

16. Dealing with Variables Local variables only used in the extracted code can be copied to the new method One original variable modified Make the new method a function Several original variables modified Use var parameters Use other refactorings first

17. Dealing with Variables - 2 Replace Temp with Query Remove local variable, move expression to a method and call it each time the variable was used Split Temporary Variable Use a different local variable for each assignment

18. Structure of Extract Method - 5 Pass any original parameters used to the new method Compile Replace extracted code with method call Remove any local variables no longer used Compile and test Don’t forget to test!!

19. Extract Class Used when a class is violating the principle of separation of concerns Often the result of feature creep Can result from too many Extract Method refactorings Splits out related subset of data and methods into a new class May need to rename the old class if its duties have changed

20. Extract Class - 2 Normally need a reference to an object of the new class in the old one Leave the new class in the implementation section if only used internally Uses Move Field and Move Method refactorings to move elements of the new class across (test after each move)

21. Inline Class The opposite of Extract Class Applied when a class is doing too little Move fields and methods into a class that uses them (there won’t be many) Fowler humour : The last step of the refactoring reads “Hold a short, simple funeral service”

22. Move Method Moves a method from one class to another May change name in the new class Original class probably needs to refer to an instance of the new one If the method is declared in an ancestor or descendant class, may not be able to move it easily

23. Inline Temp Replace a local variable assigned to with a simple expression, with the expression Removing local variables can make other refactorings easier Local variable may be doing no harm, or may be there to avoid breaking the Law of Demeter Leave it there

24. Rename Method If the task of a method has changed, rename it to reflect the new duties Seems trivial, but is very important Bad naming defeats the whole purpose of encapsulation Code is confusing, in the worst case it can be completely misinterpreted

25. Replace Magic Number with Symbolic Constant Encapsulates a standard piece of programming advice Applies to strings etc, as well, of course This sort of refactoring useful when training new programmers

26. Replace Error Code with Exception If you don’t already do this, line up at the front for a slapping Code can be written assuming it works, and is therefore much easier to read Error handling code separated out

27. Encapsulate Field Needs to be modified for Delphi Replace Field with Property Replace a public field with a property Otherwise the Delphi Style Police will come and kick you around Use the Delphi naming convention Move field to private, rename with F Make a property named without the F

28. Self Encapsulate Field We might allow direct access to a field within a class, if field is private If field needs to be protected or better, or has side effects when used, then make it into a property Direct access in constructor, destructor and property accessor methods Use Replace Field with Property

29. Remove Control Flag Some people use a local variable as a control flag to break out of loops I’ve even seen goto used this way! Use Break, Continue and Exit instead

30. Replace Type Code with State/Strategy This refactoring introduces either the State or Strategy pattern Used when the class behaviour varies depending on some state value Lots of case statements are a giveaway Demo code

31. Finite State Machine This example is from ToD, with the kind permission of Julian Bucknall

32. Convert Refactorings to Delphi Use const instead of final To make an immutable class, make all the properties read only, and set their values in the constructor Query = Function Temporary variable = local variable Some refactorings cannot be applied e.g. garbage collection

33. When to Refactor – Bad Smells Kent Beck’s idea Combination of experience and intuition sometimes makes us feel code just isn’t right There are some indicators we can look for Bad Smells Have names and recommended treatments

34. Bad Smells Duplicated Code Long Method Large Class Long Parameter List Divergent Change Shotgun Surgery Feature Envy

35. Bad Smells - 2 Data Clumps Primitive Obsession Switch Statements Parallel Inheritance Hierachies Lazy Class Speculative Generality Data Class, Refused Bequest Comments

36. Problems Do not apply refactorings without thought for the consequences Threads Discipline is new, so not all problems found yet Databases Changing interfaces Designs difficult to refactor Code is beyond all help

37. Miscellaneous Still need upfront design, but can design for ease of refactoring Don’t make design too flexible Don’t make optimisation decisions before finding bottlenecks Refactor first, optimise after Tools exist for Java (some in JBuilder) and C#, but little for Delphi...

38. Refactoring in Delphi Until now! Diamondback has the following refactorings built in, with a promise of many more to follow Rename Extract Method Extract Resource String

39. Refactoring in Delphi - 2 In addition, the new refactoring engine makes possible some handy things which are not, strictly speaking, refactorings SyncEdit mode Find References Declare Variable Declare Field Import Namespace

40. Questions?

41. Thank You You can contact me further at jim@falafelsoft.com