Code Refactoring


Published on

This is an old tutorial I used to give on code refactoring, with thanks to Martin Fowler...

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Code Refactoring

  1. 1. Code Refactoring Charlie Berg [email_address]
  2. 2. What Is Refactoring <ul><li>Martin Fowler says that refactoring is the </li></ul><ul><li>&quot; ... process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. &quot; </li></ul><ul><ul><li>Just cleaning up code. </li></ul></ul><ul><li>At first, code is pretty good but as requirements change or new features are added, the code structure tends to atrophy. Refactoring is the process of fixing a bad or chaotic design. </li></ul><ul><li>Amounts to moving methods around, creating new methods, adding or deleting classes, .. . </li></ul>
  3. 3. Why Refactor? <ul><li>Fowler says he will refactor existing code just to understand it better and sometimes it helps to find bugs. </li></ul><ul><li>Improve code structure and design </li></ul><ul><ul><li>More maintainable </li></ul></ul><ul><ul><li>Easier to understand </li></ul></ul><ul><ul><li>Easier to modify </li></ul></ul><ul><ul><li>Easier to add new features </li></ul></ul>
  4. 4. Why Refactor? <ul><li>Improving design includes removing duplicate code. </li></ul><ul><ul><li>Removes bloat </li></ul></ul><ul><ul><li>Only want one place to change functionality not multiple. </li></ul></ul><ul><li>Cumulative effect can radically improve design rather than normal slide into decay. </li></ul><ul><li>In summary, refactoring helps you develop better code, faster! </li></ul>
  5. 5. When to Refactor? <ul><li>Refactor when: </li></ul><ul><ul><li>You add new features and the code is brittle or hard to understand. Refactoring makes this feature and future features easier to build. </li></ul></ul><ul><ul><li>You fix bugs. </li></ul></ul><ul><ul><li>During code review. </li></ul></ul><ul><li>Alternate code development and refactoring. </li></ul><ul><li>Only refactor when refactoring--do not add features during refactoring. </li></ul>
  6. 6. When Not to Refactor <ul><li>Sometimes you should throw things out and start again. </li></ul><ul><li>Sometimes you are too close to a deadline. </li></ul>
  7. 7. Costs of Not Refactoring <ul><li>Bad code usually takes more code to do the same thing often because of duplication: </li></ul>
  8. 8. Refactor Opportunities <ul><li>Duplicated Code: </li></ul><ul><ul><li>Extract out the common bits into their own method ( extract method ) if code is in same class if two classes duplicate code, consider extract class to create a new class to hold the shared functionality. </li></ul></ul><ul><li>Long Methods </li></ul><ul><ul><li>Extract method </li></ul></ul><ul><li>Large Class </li></ul><ul><ul><li>Class trying to do too much often shows up as too many instance variables. </li></ul></ul>
  9. 9. Refactor Opportunities <ul><li>Long Parameter List </li></ul><ul><ul><li>Replace parameter with method (receiver explicitly asks sender for data via sender getter method) Example: day month, year, hour minute second ==> date </li></ul></ul><ul><li>Divergent Change </li></ul><ul><ul><li>If you have a fixed class that does distinctly different things consider separating out the varying code into varying classes (extract class) that either subclassor are contained by the non-varying class. </li></ul></ul>
  10. 10. Refactor Opportunities <ul><li>Shotgun Surgery </li></ul><ul><ul><li>The smell: a change in one class repeatedly requires little changes in a bunch of other classes. Use move method and move field to get all the bits into one class since they are obviously highly dependent. </li></ul></ul><ul><li>Feature Envy </li></ul><ul><ul><li>Method in one class uses lots of pieces from another class. move method to move it to the other class. </li></ul></ul>
  11. 11. Refactor Opportunities <ul><li>Data Clumps </li></ul><ul><ul><li>Data that's always hanging with each other (e.g. name street zip). </li></ul></ul><ul><ul><li>extract class for the data. Will help trim argument lists since name/street/zip now passed as one address object. </li></ul></ul><ul><li>Switch (case) statements </li></ul><ul><ul><li>Use inheritance and polymorphism instead (this is one of the more difficult refactorings) </li></ul></ul>
  12. 12. Refactor Opportunities <ul><li>Lazy Class </li></ul><ul><ul><li>Class doesn't seem to be doing anything. Get rid of it! </li></ul></ul><ul><ul><li>collapse heirarchy if subclasses are nearly vacuous. </li></ul></ul><ul><ul><li>inline class (stick the class' methods and fields in the class that was using it and delete original class). </li></ul></ul>
  13. 13. Refactor Opportunities <ul><li>Speculative generality </li></ul><ul><ul><li>Class designed to do something in the future but never ends up doing it. Thinking too far ahead! collapse hierarchy or inline class </li></ul></ul><ul><li>Message chains </li></ul><ul><ul><li>To send a message to object D in class A have to go through B to get C and C to get D. Use hide delagate to hide C and D in B, and add a method to B that does what A wanted to do with D. </li></ul></ul>
  14. 14. Refactor Opportunities <ul><li>Inappropriate Intimacy </li></ul><ul><ul><li>Directly getting in and munging with the internals of another class. Use move methods, inline methods , to consolidate the intimate bits. </li></ul></ul><ul><li>Incomplete Library Class </li></ul><ul><ul><li>If method missing from library, and can't change the library, either: </li></ul></ul><ul><ul><ul><li>Make this method in object ( introduce foreign method ) if lots of changes </li></ul></ul></ul><ul><ul><ul><li>Make your own extension/subclass ( introduce local extension ) </li></ul></ul></ul>
  15. 15. Refactor Opportunities <ul><li>Data Class </li></ul><ul><ul><li>In data-centric design, there are some data classes which are pretty much structs: no interesting methods. </li></ul></ul><ul><ul><li>Don't directly get and set fields (make them private)‏ </li></ul></ul><ul><ul><li>Don't have setter for things outsiders shouldn't change </li></ul></ul><ul><ul><li>Look who uses the data and how they use it and move code to the data class via a combinationof extract method and move method </li></ul></ul><ul><li>Comments </li></ul><ul><ul><li>Comments in the middleof methods are deodorant. Refactor so each comment block is its own method. extract method . </li></ul></ul>
  16. 16. Summary <ul><li>Extract method, hide delegate, move methods (bolded above) found in... </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li>Great refactoring site!!! </li></ul></ul><ul><li>Martin Fowler: </li></ul><ul><ul><li>&quot;Any fool can write code that a computer can understand. Good programmers write code that humans can understand.&quot; </li></ul></ul>