CSC/ECE 517 Fall 2009/wiki1a 8 rr: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 5: | Line 5: | ||
==Categories of Code refactoring== | ==Categories of Code refactoring== | ||
===1. Improve readability and code reuse=== | |||
One of the major motivation for code refactoring is readability. | One of the major motivation for code refactoring is readability. | ||
====Improve names==== | |||
*Renaming methods/variables etc to more meaningful names is a good practice. The method name should tell the reader what exactly the method does. Or a variable name should give a clear picture of what the variable stores. | |||
display() => displayStudentNames | display() => displayStudentNames | ||
*Extract a sub package depending on their gross dependencies or usages. This is to make the code more flexible. | |||
interface org.davison.data.DataProvider | |||
class org.davison.data.DataFactory | |||
// Database classes | |||
class org.davison.data.JDBCProvider | |||
class org.davison.data.JDBCHelper | |||
''Could be modified to'' | |||
interface org.davison.data.DataProvider | |||
class org.davison.data.DataFactory | |||
// Database classes | |||
class org.davison.data.jdbc.JDBCProvider | |||
class org.davison.data.jdbc.JDBCHelper | |||
====Change location of code==== | |||
*Always try to keep the class in relevant package. If it does not fit into any existing package then create a new package. This starts to make sense when this part of the code gets re-used in other parts of the project. This applies to class/method/field | |||
class org.davison.ui.TextThing | |||
class org.davison.ui.TextProcessor | |||
class org.davison.log.Logger | |||
depends on | |||
class org.davison.ui.StringUtil | |||
''Could be modified to'' | |||
class org.davison.ui.TextThing | |||
class org.davison.ui.TextProcessor | |||
class org.davison.log.Logger | |||
depends on | |||
class org.davison.util.StringUtil | |||
*Pull up or Push down (method/fields) | |||
:Pull the method/fields up to the superclass as shown in this [http://www.refactoring.com/catalog/pullUpField.html example] or push the method/fields to the subclass when needed as shown in this [http://www.refactoring.com/catalog/pushDownField.html example]. | |||
*Some other methods include | |||
**Add parameter - The main motivation here is when the method needs more information by the caller. Also Remove parameter can be used to remove parameters which the function no longer wants. | |||
** Introduce explaining variable - This can be explained with the below example | |||
if ( (platform.toUpperCase().indexOf("MAC") > -1) && | |||
(browser.toUpperCase().indexOf("IE") > -1) && | |||
wasInitialized() && resize > 0 ) | |||
{ | |||
// do something | |||
} | |||
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) | |||
{ | |||
// do something | |||
} | |||
**Introduce Assertation | |||
===2. Code management and restructuring=== | |||
===3. Allow abstraction=== | |||
===4. Change of logic=== | |||
===5. Merging/Reduction of code=== | |||
Revision as of 06:51, 8 September 2009
Categorization of code refactoring
What is Code Refactoring?
Code Refactoring is a technique of reorganization code to change its structure but at the same time preserving the basic functionality of the code. There are many kinds of code refactoring. This wiki tries to categorize these types of refactoring so that it's easy for people to learn these patterns and remember them.
Categories of Code refactoring
1. Improve readability and code reuse
One of the major motivation for code refactoring is readability.
Improve names
- Renaming methods/variables etc to more meaningful names is a good practice. The method name should tell the reader what exactly the method does. Or a variable name should give a clear picture of what the variable stores.
display() => displayStudentNames
- Extract a sub package depending on their gross dependencies or usages. This is to make the code more flexible.
interface org.davison.data.DataProvider class org.davison.data.DataFactory // Database classes class org.davison.data.JDBCProvider class org.davison.data.JDBCHelper
Could be modified to
interface org.davison.data.DataProvider class org.davison.data.DataFactory // Database classes class org.davison.data.jdbc.JDBCProvider class org.davison.data.jdbc.JDBCHelper
Change location of code
- Always try to keep the class in relevant package. If it does not fit into any existing package then create a new package. This starts to make sense when this part of the code gets re-used in other parts of the project. This applies to class/method/field
class org.davison.ui.TextThing class org.davison.ui.TextProcessor class org.davison.log.Logger depends on class org.davison.ui.StringUtil
Could be modified to
class org.davison.ui.TextThing class org.davison.ui.TextProcessor class org.davison.log.Logger depends on class org.davison.util.StringUtil
- Pull up or Push down (method/fields)
- Pull the method/fields up to the superclass as shown in this example or push the method/fields to the subclass when needed as shown in this example.
- Some other methods include
- Add parameter - The main motivation here is when the method needs more information by the caller. Also Remove parameter can be used to remove parameters which the function no longer wants.
- Introduce explaining variable - This can be explained with the below example
if ( (platform.toUpperCase().indexOf("MAC") > -1) && (browser.toUpperCase().indexOf("IE") > -1) && wasInitialized() && resize > 0 ) { // do something }
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) { // do something }
- Introduce Assertation
2. Code management and restructuring
3. Allow abstraction
4. Change of logic
5. Merging/Reduction of code
Conclusion
References
External references
- Martin Fowler's homepage about refactoring
- Smells to Refactorings Quick Reference Guide
- Refactoring: Improving the Design of Existing Code by Martin Fowler available at Google Books