Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Code Refactoring

917 views

Published on

This presentation on Code Refactoring is part of a larger course LINGI2252 on Software Maintenance and Evolution, given at UCL university in Belgium.

Published in: Education

Code Refactoring

  1. 1. CODE REFACTORING LINGI2252 – PROF. KIM MENS * Slides mostly based on Martin Fowler’s book:
 Refactoring: Improving the Design of Existing Code. ©Addison Wesley, 2000 * (These slides are part of the course LINGI2252 “Software Maintenance and Evolution”, given by Prof. Kim Mens at UCL, Belgium)
  2. 2. Refactoring:
 Improving the Design of Existing Code One of the best references on software refactoring,
 with illustrative examples in Java: Refactoring: Improving the Design of Existing Code.
 Martin Fowler. Addison Wesley, 2000. ISBN: 0201485672 See also www.refactoring.com Overview of this presentation A. Refactoring basics B. Categories of refactoring C. Words of warning 2
  3. 3. A. REFACTORING BASICS LINGI2252 – PROF. KIM MENS * Based on Chapter 2 of Martin Fowler’s book:
 Refactoring: Improving the Design of Existing Code. ©Addison Wesley, 2000 *
  4. 4. What is refactoring? A refactoring is a software transformation that preserves the external behaviour of the software; improves the internal structure of the software. It is a disciplined way to clean up code that minimises the chances of introducing bugs. 4
  5. 5. Definition of Refactoring [Fowler2000] [noun] “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour” [verb] “to restructure software by applying a series of refactorings without changing its observable behaviour” typically with the purpose of making the software easier to understand and modify 5
  6. 6. 6 Why should you refactor?
  7. 7. Why should you refactor? To improve the design of software To counter code decay (software ageing) refactoring helps code to remain in shape To increase software comprehensibility To find bugs and write more robust code To increase productivity (program faster) on a long term basis, not on a short term basis 7
  8. 8. Why should you refactor? To reduce costs of software maintenance To reduce testing automatic refactorings are guaranteed to be behaviour preserving To prepare for / facilitate future customisations To turn an OO application into a framework To introduce design patterns in a behaviourally preserving way 8
  9. 9. When should you refactor? Whenever you see the need for it Do it all the time in little bursts Not on a pre-set periodical basis Apply the rule of three 1 st time : implement from scratch 2 nd time : implement something similar by code duplication 3 rd time : do not implement similar things again, but refactor 9
  10. 10. When should you refactor? Refactor when adding new features or functions Especially if feature is difficult to integrate with the existing code Refactor during bug fixing If a bug is very hard to trace, refactor first to make the code more understandable, so that you can understand better where the bug is located Refactor during code reviews 10
  11. 11. When should you refactor? Refactoring also fits naturally in the agile methods philosophy Is needed to address the principle "Maintain simplicity" Wherever possible, actively work to eliminate complexity from the system By refactoring the code 11
  12. 12. What do you tell the manager? When (s)he’s technically aware (s)he’ll understand why refactoring is important. When (s)he’s interested in quality, (s)he’ll understand that refactoring will improve software quality. When (s)he’s only interested in the schedule, don’t tell that you’re doing refactoring, just do it anyway. In the end refactoring will make you more productive. 12
  13. 13. When shouldn’t you refactor? When the existing code is such a mess that although you could refactor it, it would be easier to rewrite everything from scratch instead. When you are too close to a deadline. The productivity gain would appear after the deadline and thus be too late. However, when you are not close to a deadline you should never put off refactoring because you don’t have the time. Not having enough time usually is a sign that refactoring is needed. 13
  14. 14. B. CATEGORIES OF REFACTORINGS LINGI2252 – PROF. KIM MENS * Based on Martin Fowler’s book:
 Refactoring: Improving the Design of Existing Code. ©Addison Wesley, 2000 *
  15. 15. Categories of refactorings Small refactorings (de)composing methods moving features between objects organizing data simplifying conditional expressions dealing with generalisation simplifying method calls Big refactorings Tease apart inheritance Extract hierarchy Convert procedural design to objects Separate domain from presentation 15
  16. 16. Small refactorings (de)composing methods [9 refactorings] moving features between objects [8 refactorings] organizing data [16 refactorings] simplifying conditional expressions [8 refactorings] dealing with generalisation [12 refactorings] simplifying method calls [15 refactorings] 16
  17. 17. Small Refactorings :
 (de)composing methods 1. Extract Method 2. Inline Method 3. Inline Temp 4. Replace Temp With Query 5. Introduce Explaining Variable 6. Split Temporary Variable 7. Remove Assignments to Parameter 8. Replace Method With Method Object 9. Substitute Algorithm 17 = we will zoom in on these = home reading Legend:
  18. 18. (De)composing methods:
 1. Extract Method 18 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); } 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()))); } Beware of local variables !
  19. 19. (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 moreThanFiveLateDeliveries(){ return _numberOfLateDeliveries > 5; } (De)composing methods :
 2. Inline Method 19 int getRating(){ return (_numberOfLateDeliveries > 5); }
  20. 20. (De)composing methods :
 3. Inline Temp 20 What? When you have a temp that is assigned once with a simple expression, and the temp is getting in the way of refactorings,
 replace all references to that temp with the expression.
 Why? (Part of Replace Temp with Query refactoring) 
 Example: return (anOrder. basePrice() > 100) double basePrice = anOrder.basePrice(); return (basePrice > 100)
  21. 21. (De)composing methods :
 4. Replace Temp with Query 21 What? When you use a temporary variable to hold the result of an expression, extract the expression into a method and replace all
 references to the temp with a method call Why? Cleaner code Example: double basePrice = _quantity * _itemPrice; if (basePrice > 1000) return basePrice * 0.95; else return basePrice * 0.98; if (basePrice() > 1000) return basePrice() * 0.95; else return basePrice() * 0.98; … double basePrice(){ return _quantity * _itemPrice; }
  22. 22. (De)composing methods :
 5. Introduce Explaining Variable 22 What? When you have a complex expression, put the result of the
 (parts of the) expression in a temporary variable with a name that explains the purpose Why? Breaking down complex expressions for clarity Example: if ( (platform.toUpperCase().indexOf(“MAC”) > -1) && (browser.toUpperCase().indexOf(“IE”) > -1) && wasInitialized() && resize > 0 ) { //ACTION } final boolean isMacOs = platform.toUpperCase().indexOf(“MAC”) > -1; final boolean isIEBrowser = browser.toUpperCase().indexOf(“IE”) > -1; final boolean wasResized = resize > 0; if (isMacOs && isIEBrowser && wasInitialized() && wasResized){ //ACTION }
  23. 23. (De)composing methods :
 6. Split Temporary Variable 23 What? When you assign a temporary variable more than once, but it is not a loop variable nor a collecting temporary variable, make a separate temporary variable for each assignment Why? Using temps more than once is confusing Example: double temp = 2 * (_height + _width); System.out.println (temp); temp = _height * _width; System.out.println (temp); final double perimeter = 2 * (_height + _width); System.out.println (perimeter); final double area = _height * _width; System.out.println (area);
  24. 24. (De)composing methods :
 7. Remove Assignments To Parameter 24 What? When the code assigns to a parameter, use a temporary variable instead Why? Lack of clarity and confusion between “pass by value” and “pass by reference” 
 Example: int discount (int inputVal, int quantity, int yearToDate){ if (inputVal > 50) inputVal -= 2; ... MORE CODE HERE ... int discount (int inputVal, int quantity, int yearToDate){ int result = inputVal; if (inputVal > 50) result -= 2; ... MORE CODE HERE ...
  25. 25. (De)composing methods :
 8. Replace Method with Method Object 25 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: Order price() PriceCalculator primaryBasePrice secondaryBasePrice compute() return new PriceCalculator(this). compute() 1 Order price() double primaryBasePrice; double secondaryBasePrice; // long computation
  26. 26. (De)composing methods :
 9. Substitute Algorithm 26 What? When you want to replace an algorithm with a clearer alternative, replace the body of the method with the new algorithm Why? To replace complicated algorithms with clearer ones Example: String foundPerson(String[] people){ for (int i = 0; i < people.length; i++){ if (people[i]. equals (“John”) ) { return “John”; } if (people[i]. equals (“Jack”) ) { return “Jack”; } } } String foundPerson(String[] people){ List candidates = Array.asList(new String[] {“John”, “Jack”}) for (int i = 0; i < people.length; i++) if (candidates[i]. contains (people[i])) return people[i]; }
  27. 27. Small refactorings (de)composing methods [9 refactorings] moving features between objects [8 refactorings] organizing data [16 refactorings] simplifying conditional expressions [8 refactorings] dealing with generalisation [12 refactorings] simplifying method calls [15 refactorings] 27
  28. 28. Small Refactorings :
 moving features between objects 1. Move Method 2. Move Field 3. Extract Class 4. Inline Class 5. Hide Delegate 6. Remove Middle Man 7. Introduce Foreign Method 8. Introduce Local Extension = we will zoom in on these = home reading Legend: 28
  29. 29. Moving features between objects :
 1,2. Move Method / Field 29 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: Class 1 aMethod() Class 2 Class 1 Class 2 aMethod()
  30. 30. Moving features between objects :
 3. Extract Class 30 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: PhoneNumber areaCode number getPhoneNumber 1 Person name officeAreaCode officeNumber homeAreaCode homeNumber getOfficePhone getHomPhone Person name getOfficePhone getHomePhone phone
  31. 31. Moving features between objects :
 4. Inline Class 31 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: PhoneNumber areaCode number getPhoneNumber() 1 Person name getPhoneNumber() office- phone 1 Person name officeAreaCode officeNumber getPhoneNumber()
  32. 32. Moving features between objects :
 5. Hide Delegate 32 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: Person getDepartment() Department getManager() Person getManager() Client Class Client Class Department getManager()
  33. 33. Moving features between objects :
 6. Remove Middle Man 33 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: Person getManager() Department Person getDepartment() Department getManager() Client ClassClient Class
  34. 34. What? When a server class needs an additional method, but you cannot modify the class, create a method in the client class with an instance of the server class as its first argument Why? To introduce one additional service Example: Date newStart = new Date (previousEnd.getYear(), previousEnd.getMonth(), previousEnd.getDate() + 1); Date newStart = nextDay(previousEnd); private static Date nextDay(Date arg) { return new Date (arg.getYear(), arg.getMonth(), arg.getDate() + 1); } Moving features between objects :
 7. Introduce Foreign Method 34
  35. 35. What? When a server class needs several additional methods but you cannot
 modify the class, create a new class containing the extra methods; make the extension class a subclass or wrapper Why? To introduce several additional services Example: Client Class nextDayDate(Date): Date MfDate nextDay(): Date Date Moving features between objects :
 8. Introduce Local Extension 35
  36. 36. Small refactorings (de)composing methods [9 refactorings] moving features between objects [8 refactorings] organizing data [16 refactorings] simplifying conditional expressions [8 refactorings] dealing with generalisation [12 refactorings] simplifying method calls [15 refactorings] 36
  37. 37. Small Refactorings :
 organizing data 1. Encapsulate field 2. Replace data value with object 3. Change value to reference 4. Change reference to value 5. Replace array with object 6. Duplicate observed data 7. Change unidirectional association to bidirectional 8. Change bidirectional association to unidirectional 9. Replace magic number with symbolic constant 10. Encapsulate collection 11. Replace record with data class 12. Replace subclass with fields 13-16. Replace type code with class / subclass / state / strategy 37
  38. 38. 38 Organizing Data :
 1. Encapsulate Field private String name;
 public String getName() {
 return this.name; }
 public void setName(String s) {
 this.name = s; } public String name; What? There is a public field. Make it private and provide accessors. Why? Encapsulating state increases modularity, and facilitates code reuse
 and maintenance. When the state of an object is represented as a collection of private
 variables, the internal representation can be changed without modifying the external interface Example:
  39. 39. 39 private Document doc;
 public String getContents() {
 return this.doc.getContents(); }
 public void setContents(String s) {
 this.doc.setContents(s); } public class Document {
 private String contents; public String getContents() { return this.contents; } public void setContents(String s) {
 this.contents = s; }
 } private String contents; public String getContents() { return this.contents; } public void setContents(String s) { this.contents = s; } Organizing Data :
 2. Replace Data Value with Object
  40. 40. 40 Organizing Data :
 13. Replace Type Code with Subclass What? An immutable type code affects the behaviour of a class Example: Employee const Engineer=0 const Salesman=1 const Manager=2 type:Int Employee Engineer Salesman Manager
  41. 41. 41 When? If subclassing cannot be used, e.g. because of dynamic type changes during object lifetime (e.g. promotion of employees)
 Example: Employee const Engineer=0 const Salesman=1 const Manager=2 type:Int Employee EmployeeType Engineer Salesman Manager Organizing Data :
 15,16. Replace Type Code with State/Strategy Makes use of state pattern or strategy design pattern
  42. 42. 42 Organizing Data :
 12. 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 sex: [M, F] Person Male Female Similar to replace inheritance with aggregation
  43. 43. Small refactorings (de)composing methods [9 refactorings] moving features between objects [8 refactorings] organizing data [16 refactorings] simplifying conditional expressions [8 refactorings] dealing with generalisation [12 refactorings] simplifying method calls [15 refactorings] 43
  44. 44. Small Refactorings :
 simplifying conditional expressions 1. Decompose conditional 2. Consolidate conditional expression 3. Consolidate duplicate conditional fragments 4. Remove control flag 5. Replace nested conditional with guard clauses 6. Replace conditional with polymorphism 7. Introduce null objects 8. Introduce assertion 44
  45. 45. Small refactorings (de)composing methods [9 refactorings] moving features between objects [8 refactorings] organizing data [16 refactorings] simplifying conditional expressions [8 refactorings] dealing with generalisation [12 refactorings] simplifying method calls [15 refactorings] 45
  46. 46. Small Refactorings :
 dealing with generalisation 1. Push down method / field 2. Pull up method / field / constructor body 3. Extract subclass / superclass / interface 4. Collapse hierarchy 5. Form template method 6. Replace inheritance with delegation (and vice versa) 46
  47. 47. Dealing with Generalisation:
 1. Push Down Method When behaviour on a superclass is relevant only for some of its subclasses, move it to those subclasses Engineer Employee getQuota Salesman 47 Salesman getQuota Employee Engineer
  48. 48. ASCIIPrinter PSPrinter Printserver accept ASCIIPrinter accept PSPrinter accept Printserver Dealing with Generalisation:
 2. Pull Up Method Simple 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 If the method that is being pulled up already exists in the superclass as an abstract method, make it concrete with the common behaviour 48
  49. 49. When you have 2 classes with similar features PrintServer FileServer FileserverPrintserver Outputserver Dealing with Generalisation:
 3. Extract Superclass 49
  50. 50. Small refactorings (de)composing methods [9 refactorings] moving features between objects [8 refactorings] organizing data [16 refactorings] simplifying conditional expressions [8 refactorings] dealing with generalisation [12 refactorings] simplifying method calls [15 refactorings] 50
  51. 51. Small Refactorings :
 simplifying method calls 1. Rename method 2. Add parameter 3. Remove parameter 4. Separate query from modifier 5. Parameterize method 6. Replace parameter with method 7. Replace parameter with explicit methods 8. Preserve whole object 9. Introduce parameter object 10. Remove setting method 11. Hide method 12. Replace constructor with factory method 13. Encapsulate downcast 14. Replace error code with exception 15. Replace exception with test 51
  52. 52. Simplifying method calls :
 9. Introduce Parameter Object Group parameters that belong together in a separate object Customer amountInvoicedIn(from:Date,to:Date) amountReceivedIn(from:Date,to:Date) amountOverdueIn(from:Date,to:Date) Customer amountInvoicedIn(r:DateRange) amountReceivedIn(r:DateRange) amountOverdueIn(r:DateRange) DataRange from : Date to : Date 52
  53. 53. Simplifying method calls:
 14. 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; } 53
  54. 54. Categories of refactorings (according to [Fowler2000]) Small refactorings (de)composing methods [9] moving features between objects [8] organizing data [16] simplifying conditional expressions [8] dealing with generalisation [12] simplifying method calls [15] Big refactorings Tease apart inheritance Extract hierarchy Convert procedural design to objects Separate domain from presentation 54
  55. 55. 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 55
  56. 56. Big Refactorings 1. Tease apart inheritance 2. Extract hierarchy 3. Convert procedural design to objects 4. Separate domain from presentation
  57. 57. Big refactorings:
 1. 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 57
  58. 58. Big refactorings:
 1. Tease apart inheritance 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. 58
  59. 59. Big refactorings:
 1. Tease apart inheritance 59 Window FullXWin FullMSWin IconXWin Full Iconised IconMSWin WindowImpl FullXWin Window IconisedMSWin 1
  60. 60. Big refactorings:
 1. Tease apart inheritance Related design patterns Bridge decouples an abstraction from its implementation so that the two can vary independently Strategy / Visitor / Iterator / State 60
  61. 61. Big refactorings:
 2. 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. 61
  62. 62. Big refactorings:
 2. Extract hierarchy 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 62
  63. 63. Calculating electricity bills. Lots of conditional logic needed to cover many different cases: different charges for summer/winter different tax rates different billing plans for personal / business / government / … reduced rates for persons with
 disabilities or social security Customer Billing Scheme Big refactorings:
 2. Extract hierarchy (example) 63
  64. 64. Big refactorings:
 3. Convert procedural 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. Smaller refactorings used extract method, move method, … 64
  65. 65. Big refactorings:
 4. 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. Smaller refactorings used extract method, move method/field, duplicate observed data, … 65
  66. 66. C. REFACTORING TOOLS LINGI2252 – PROF. KIM MENS *
  67. 67. CODE REFACTORING – REFACTORING TOOLS AUTOMATED CODE REFACTORING TOOLS Available for all major programming languages
 (and OO programming languages in particular) Java : IntelliJ IDEA, Eclipse, NetBeans, JDeveloper, … JavaScript : WebStorm, Eclipse, … C++ : VisualStudio, Eclipse, … ObjectiveC and SWIFT : XCode .NET : VisualStudio Smalltalk, PHP, Ruby, Python, C#, Delphi, … 67
  68. 68. CODE REFACTORING – REFACTORING TOOLS LIMITATIONS OF MOST REFACTORING TOOLS Only support for primitive refactorings class refactorings add (sub)class to hierarchy, rename class, remove class method refactorings add to class, rename, remove, push down, pull up, add parameter, move to component, extract code variable refactorings add to class, rename, remove, push down, pull up, create accessors, abstract variable Often no support for higher-level refactorings 68
  69. 69. CODE REFACTORING – REFACTORING TOOLS REFACTORING IN ECLIPSE The refactoring tool in Eclipse supports a number of transformations described in Martin Fowler's book Refactoring can be accessed via the Refactor menu. Refactoring commands are also available from the context menus in many views or appear as quick assists.
  70. 70. CODE REFACTORING – REFACTORING TOOLS SUPPORTED REFACTORING ACTIONS IN ECLIPSE (2016) Rename, Move, Change Method Signature Extract Method, Extract Local Variable, Extract Constant Inline, Move Type to New File, Use Supertype Where Possible Convert Anonymous Class to Nested, Convert Local Variable to Field Extract Superclass, Extract Interface, Extract Class Push Down, Pull Up, Encapsulate Field Introduce Parameter Object, Introduce Indirection Introduce Factory, Introduce Parameter Generalize Declared Type , Infer Generic Type Arguments (and more)
  71. 71. CODE REFACTORING – REFACTORING TOOLS 71
  72. 72. CODE REFACTORING – REFACTORING TOOLS 72
  73. 73. CODE REFACTORING – REFACTORING TOOLS 73
  74. 74. D. WORDS OF WARNING LINGI2252 – PROF. KIM MENS *
  75. 75. CODE REFACTORING – WORDS OF WARNING A WORD OF WARNING (1) Know what you are doing If not applied well, refactoring may decrease quality rather than improve it 75
  76. 76. CODE REFACTORING – WORDS OF WARNING A WORD OF WARNING (1) “Bad smells” are symptoms that something is wrong Refactoring are supposed to remove “bad smells” PhoneNumber areaCode number getPhoneNumber 1 Person name officeAreaCode officeNumber homeAreaCode homeNumber getOfficePhone getHomPhone Person name getOfficePhone getHomePhone phone 1 EXTRACT
 CLASS SMELLS LIKE A TOO “LARGE CLASS” SMELLS BETTER NOW… 76
  77. 77. CODE REFACTORING – WORDS OF WARNING A WORD OF WARNING (1) Refactoring should not introduce new smells HumanBeing Person name getOfficePhone getHomePhone EXTRACT
 SUPERCLASS Person name getOfficePhone getHomePhone SMELLS LIKE A TOO ABSTRACT CLASS 77
  78. 78. CODE REFACTORING – WORDS OF WARNING NEXT SESSION: INTRODUCTION TO “BAD SMELLS” Bad code smells indicate that your code is ripe for refactoring Refactoring is about how to change code Bad smells are about when to modify it 78
  79. 79. CODE REFACTORING – WORDS OF WARNING A WORD OF WARNING (2) Independently applied refactorings can introduce subtle merge conflicts 79 Bank Account Loan handles Company Agency Account Loan handles Bank Company represents Bank Account Loan handles Company Safe EXTRACT
 CLASS CREATE SUBCLASS REFACTORING CONFLICT : In the new version, Safe should not be handled by Bank, but by Agency
  80. 80. CODE REFACTORING POSSIBLE QUESTIONS ▸ Give a definition of refactoring in your own words
 and illustrate it with a concrete example of a refactoring. ▸ Explain why you should refactor. ▸ Explain when (= at what moment) refactoring should (or should not) be performed. ▸ Like refactoring, performance optimisation does not usually change the behaviour of code (other than its speed); it only alters the internal structure. So how does it differ from refactoring? ▸ Explain and illustrate one of the following refactorings in detail: ▸ Extract Method, Move Method, Extract Class, Replace Type Code with Subclass, Replace Subclass with Fields, Pull Up Method, Introduce Parameter Object ▸ Give a concrete example of how a refactoring could accidentally reduce quality. ▸ Give a concrete example of how to independently applied refactorings could accidentally introduce a subtle merge conflict.

×