1. Refactoring

2. Refactoring is a step in the software design process

3. Refactoring – Defined (What) Code refactoring is the process of changing a computer program's internal structure without modifying its external functional behavior. (Why) The purpose of refactoring is to make existing code easier to understand, modify and extend. The term ‘refactoring’ is both a noun and a verb. There are catalogs of refactorings (noun) that simplify the process of refactoring (verb) code. Refactoring reduces technical debt (the “principle” part).

4. Example... if (i != min) { int temp = num[i]; num[i] = num[min]; num[min] = temp; }... if (i != min) { swap(ref num[i], ref num[min]); }... void swap(ref int a, ref int b) { int temp = a; a = b; b = temp; } Extract Method Program behavior doesn’t change but the resulting code is easier to read and understand.

5. When to Refactor During new development. Writing well-designed code in one pass is not easy. Solution: divide and conquer; write code in two steps. Step 1: make it work. Step 2: make it better; refactor the code until the design is satisfactory. This is standard practice in test-driven development (TDD). During maintenance. Making changes to existing code can be risky. Minimize the risk by making changes in two steps. Step 1: refactor the code to a state that will more easily accept the planned changes. Step 2: make the changes. In between maintenance changes. Routine changes to software gradually increase software complexity (aka entropy or technical debt) unless extra effort is devoted to maintaining or reducing complexity. (This tendency is Layman’s second law of software maintenance.) When turnaround time for a change is short, there isn’t always time to maintain or reduce system complexity with each change. Refactoring between code changes reverses the adverse effects of quick fixes and makes future maintenance easier.

6. Systematic Refactoring is more than just “cleaning up code” Refactoring is more than just “cleaning up code” the same way an accounting audit is more than just “looking over the books”. The term refactoring is sometimes used to refer to any change that improves code. Here the term is being used to refer to systematic code changes that address reoccurring or identifiable problems. Both the problem and the systematic change have well-known names. There are catalogs of refactorings that provide routine solutions to reoccurring problems found in existing code just as there are catalogs of design patterns that provide routine solutions to reoccurring problems faced during design. Like catalogs of design patterns, catalogs of refactoring also provide a vocabulary for discussing possible code changes.

7. Refactoring makes software development more routine Catalogs of refactorings serve as another handbook for software engineers. They offer routine solutions to reoccurring problems found in code. Use of these handbooks makes software development and maintenance more routine, systematic and predictable. Documented refactorings reduces the portion of the development process that still depends on inspiration and creativity.

8. Routine Design

9. Is your code ready to be refactored? Step 0: make sure you have object-oriented code. Most refactorings assume OO code. A more serious condition—one that should be addressed before you refactor—is not having object-oriented code to start with. Code is object-oriented when you have classes that encapsulate data and these classes have methods that act on the data. The objects created from these classes correspond to significant abstractions in the problem and/or solution domain.

10. Refactorings are Transformations Refactorings are transformations on code A B They transform existing code that is poorly structured and difficult to understand and maintain into code with improved structure that is easier to understand and maintain. Refactorings have names like: Rename method Extract superclass Separate Query from Modifier

11. Example Transformation/Refactoring Move Method

12. Knowing when to apply a refactoring If you have a clear understanding of the transformation a refactoring performs, you might be able to use your intuition to recognize when it applies. For example, if you find a cryptic method name in your code, rename method seems like an obvious choice. There are many instances when a refactoring can be applied. (For example, you can rename any method.) How do you know when a particular refactoring should be applied?

13. Knowing when to apply a refactoring [Cont] Could just leave it up to your intuition to recognize when a refactoring is needed. However, if you are just starting out, your intuition might not be developed. What is needed are guidelines for when to apply a refactoring that are a little more tangible than “this code just doesn’t feel right”.

14. Code Smells Code smells or pathologies are symptoms in code that suggest a deeper problem. Most code smells are paired with one or more corresponding refactorings for dealing with the problem. The presence of symptoms doesn't always imply a change is needed. Design often involves tradeoffs among competing priorities. The code might be the way it is for a reason. Code smells and their corresponding refactorings are rules of thumb not absolutes.

15. Candidate Refacotorings Associated with Certain Code Smells

16. More Code Smells Too many parameters Inappropriate intimacy – “a class that has dependencies on implementation details of another class.” Contrived complexity – forcing the use of a really cool design pattern when a simpler design would have sufficed. Excessively long identifiers Excessively short identifiers Excessive use of literals – consider replacing with named constants. Type Embedded in Name – “Avoid placing types in method names; it's not only redundant, but it forces you to change the name if the type changes.”

17. Some Code Smells Overlap with Design Principles

18. Appropriateness of a refactoring depends on context Refactorings don’t automatically take your code to a better state. Just because there is a refactoring A  B and you find state A in your program, there is no guarantee that state B is better for your program than state A. When to apply a refactoring depends on context. Here’s proof. There are pairs of refactorings that are opposites. –Extract Method  Inline Method –Extract Class  Inline Class –Collapse Hierarchy  Extract Subclass –Hide Delegate  Remove Middle Man

19. Duplicated Code Duplicated code is a specific case of the don’t repeat yourself principle (DRY). Duplicate code is when the same code or nearly the same code appears in more than once place. Duplicate code is undesirable because: –It takes more effort to make a change to the code. The change has to be made in all locations. Easy to make a mistake and allow code to become inconsistent. Candidate refactorings: –Extract Method – when duplicate code is in the same class, use extract method to get the code in one place and then replace chunks of duplicated code with a call to this new method. –Pull Up Field – when subclasses have duplicate fields use pull up field to move the field declaration to a superclass. There may also be an opportunity to move behavior in subclasses to a superclass as well. –Form Template Method – When the same sequence of steps are repeated in subclasses but with unique behavior for some or all steps, the Template Method design pattern can be used to define the skeleton of the algorithm in a superclass with the behavior of the steps deferred to polymorphic methods in subclasses. (This is a good example of refactoring to patterns. Patterns are often targets of refactoring.) –Extract Class. Used when duplicate code is in two or more unrelated classes. (Before applying extract class, consider whether or not it would be better to make the duplicate code a method of one class that the others call.)]

20. Long Method Methods that are too long are difficult to understand and reuse. The general rule-of-thumb is a method should fit on one page. This makes it easier to comprehend. It’s not so much the number of lines in a method that make it too long, it’s the variety of activity that takes place during the method. (Single Responsibility Principle) When Extract Method is used to divide a long method, a good method name can add significant semantic value. Candidate Refactorings: –Extract Method. If many local variables result in long parameter lists on extracted objects, consider using Introduce Parameter Object to minimize the number of parameters passed to extracted methods.

21. Large Class Similar to long methods, large classes are classes with too much code. Often it’s not the number of lines of code that is the problem, but rather how the code is used. A class is too large if: –It deals with more than one abstraction and/or these abstractions are unrelated. (A direct violation of the single responsibility principle.) –The volume of code makes it difficult to understand. Candidate Refactorings: –Extract Class. When class cohesion begins to break down and the features of a class no longer pertain to a single responsibility, consider moving some of the features to a second class. –Extract Subclass. When features of a class only apply to certain instances of a class, consider moving some of these conditional features to a subclass.

22. Divergent Change The divergent change code smell is what you notice when inspecting a class that doesn’t follow the Single Responsibility Principle (SRP) of design. Divergent change is when a class changes in different ways for different reasons. Consider the most likely reasons for making changes to the software you are writing. What modules are affected by each of the reasons for change? Is there any one module that is changed for more than one reason? If so, consider using Extract Class to split this class into two classes based on the reasons for change. Example: class that calculates and prints values for a report. It will change when calculations change or format of report changes.

23. Shotgun Surgery Shotgun surgery is the opposite of divergent change. Instead of having one class with multiple reasons to change you have one reason for a change affecting multiple classes. Candidate Refactorings: –Move Method - –Move Field - –Inline Class -

24. Divergent Change: a module has more than one reason to change. Shotgun Surgery: a single reason to change affects more than one module.

25. Feature Envy A tall tale sign of feature envy is a method that relies more on data from another class than its own class in order to fulfill its responsibility. Characteristic of good OOD is keeping data and the methods that operate on this data in close proximity. Candidate Refactorings: –Use Move Method to move the method to the class that has the preponderance of data it needs to fulfill its responsibility. –When it is a section of a method that seems envious, consider Extract Method to isolate the code followed by Move Method to place it closer to the data it needs.

26. Lazy Class A lazy class is one that doesn't do much. Perhaps you had grand plans for it when first created, but now it contains just a few fields and mostly getter and setter methods. Candidate Refactorings: –Collapse Hierarchy – –Inline Class –

27. Data Class Classes with mostly getting and setting methods. To promote a data class to a genuine class, find the methods that use the data in the data class and consider moving them to the data class. Candidate Refactorings: –Move Method – –If the method that uses the data can’t be moved as is, consider applying Extract Method to isolate the logic that is using the data and then Move Method on the newly isolated logic.

28. Speculative Generality Abstraction in program design can be a good thing. It is the primary means of managing complexity and can enable reuse. However, like all good things in life it can be pursued to excess. For example, you defined an abstract class with visions of having lots of code written to the interface of the abstract class working with a number of subclasses. However, so far you have just one subclass and prospects for others is increasingly unlikely. Candidate Refactorings: –Collapse Hierarchy – –Inline Class –

29. Middle Man Delegation is one way of achieving information hiding. For example, a grocery store is a delegate for farmers and ranchers. It acts as a middle man between consumers and producers. Buying produce from the grocery store simplifies your life and insulates you from the complexity of dealing directly with producers. However, if you find yourself going to the same store just for milk, eggs and butter, maybe it’s more efficient to just skip the middle man and go straight to the dairy farmer (or farmer’s market) for your produce. Candidate Refactorings: –Remove Middle Man – –Inline Method –

30. Remove Middle Man

32. Hide Delegate

33. Comments Comments are great you should use them regularly; however, if you have to comment code to make it understandable, consider refactoring to make the code more understandable. For example, you might use Extract Method in order to create a descriptive name for a chunk of code. Another example: you might use Replace Magic Number with Symbolic Constant to make code more readable. Good variable and method names make comments a part of the code.

34. Refused Bequest A class that violate the principle of substitution is refusing the bequest of its superclass. Consider: Replace Inheritance with Delegation

35. Extract Interface Refactoring can also help you conform to principles of good design. Example: Interface Segregation Principle If a clients of a class are interested in only a subset of methods on a class, consider using Extract Interface to create a more narrow interface for the client.

36. Refactoring – How to Each refactoring provides a systematic procedure for making a particular code change. For each refactoring there are step-by-step instructions for making the (function-preserving) code change. Small steps reduce the changes of making an error. They also make it easy to catch any errors that are made. During refactoring you shouldn’t: –Add new functionality –Change existing functionality –Fix defects

37. Many programming devolvement environments (IDE’s) offer automated support for refactoring Eclipse (right) Visual Studio (below)

38. Systematic Refactorings Rename Method – Shakespeare clearly wasn’t a programmer. Ask any good programmer, “What’s in a name?” and the answer you are likely to get is: “A lot!” Good names convey meaning in a way that is inextricably tied to the code. Move Method and Move Field – Moving methods and fields from one class to another can reduce coupling and/or increase cohesion. Encapsulate Field – Make a public field private and add accessors. With C# you can convert the field to a property. Reduce Scope of Variable – Extract method – Turn a sequence of statements into a method with a descriptive name. Inline method – (Opposite of extract method.) Hide delegate – Add methods to hide a delegate. Replace conditional with polymorphism (complex)

39. More Systematic Refactorings Introduce Assertion – Add an assertion to make an assumption in your code explicit. Extract Superclass – When you have two or more classes with similar features (e.g. SceneItem) Extract Subclass – A class has features that are only used by some instances. Pull Up Field – Move a field from a subclass to a superclass. Pull Up Method – Move a method from a subclass to a superclass. Push Down Field – Move a field from a superclass to a subclass. Push Down Method – Move a method from a superclass to a subclass.

40. Extract Method Extract method is not only for removing duplicate code. It can also be used to improve readability and understandability. Extract method is also useful when a method gets too long to easily read and understand. Adding descriptive method names introduces self- documentation. Added bonus: fine-grain methods are easier to test and reuse.

41. Extract Method Example // Returns true if there is a collision. public bool pixelPerfectCollision(Sprite s) { return ( boundsOverlap(s)&& opaquePixelsOverlap(s) ); } // Returns true if there is a collision. public bool pixelPerfectCollision(Sprite s) { // Check to see if area of s overlaps with // with self... if (!objectsOverlap) { return false; } else { // Check to see if non-opaque pixels in // both objects overlap... }

42. Reduce Scope of Variable

43. Encapsulate Field

44. Replace Inheritance with Delegation

45. Inline Class

46. Extract Class

47. Replace Magic Number with Symbolic Constant Functional: // Calculate the length of the outer crust of each // piece of pizza given the diameter of the pizza // and number of desired pieces. public float lengthOfOuterCrust(float diameter, int numberOfPieces) { return (3.1415 * diameter) / numberOfPieces; } Better: public static final float PI = 3.1415; public float lengthOfOuterCrust(float diameter, int numberOfPieces) { float circumference = PI * diameter; return circumference / numberOfPieces; }

48. Remove Middle Man