CSC/ECE 517 Fall 2011/ch5 5d he: Difference between revisions
No edit summary |
|||
Line 5: | Line 5: | ||
==Introduction== | ==Introduction== | ||
Refactoring is a technique for restructuring an existing code, altering its internal structure without changing its external behavior. Its done as a series of small transformations. Each transformation does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.<ref name="refone"> Refactoring Home Page http://refactoring.com/ </ref> As people make changes to the code to realize their short term goals without fully understanding the design of code, the code loses its structure. The refactoring work is done to remove bits that aren’t really in the right place. Loss of the structure of code has a cumulative effect. The harder it is to see the design in the code, the harder it is to preserve it, and the more rapidly it decays. Regular refactoring helps code retain its shape. <ref name="reftwo"> Why should you Refactor http://sourcemaking.com/refactoring/why-should-you-refactor </ref> | Refactoring is a technique for restructuring an existing code, altering its internal structure without changing its external behavior. Its done as a series of small transformations. Each transformation does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.<ref name="refone"> Refactoring Home Page http://refactoring.com/ </ref> As people make changes to the code to realize their short term goals without fully understanding the design of code, the code loses its structure. The refactoring work is done to remove bits that aren’t really in the right place. Loss of the structure of code has a cumulative effect. The harder it is to see the design in the code, the harder it is to preserve it, and the more rapidly it decays. Regular refactoring helps code retain its shape. <ref name="reftwo"> Why should you Refactor http://sourcemaking.com/refactoring/why-should-you-refactor </ref> | ||
==Common Refactoring Techniques== | |||
===Extraction Refactoring=== | |||
There are several refactoring techniques related to extraction: Extract method, Extract local variables, extract constants. The first method "Extract method will create a new method from code you've selected. Extract Local Variable refactoring takes an expression that is being used repeatedly and assigns it to a local variable. Extract constant refactoring is to select a static, constant expression, which the refactoring will convert to a static final constant. This is useful for removing hard-coded numbers and strings from your code | |||
===Inline Refactoring=== | |||
This type refactoring is the reverse of local variable extraction, in which we remove a local variable and use the value of the variable(typically an expression) in the place where the variable is used. This can be marginally more efficient than using a temporary variable and, by making the code terser, makes it either easier to read or more cryptic, depending on your point of view | |||
===Encapsulating Fields=== | |||
Generally its not a good practice to expose the class attributes through public interface. Thus, Encapsulating such fields will make such fields as private or protected as appropriate and generate getters and setters for the associated field. | |||
===Changing Method Signature=== | |||
Here we change the change the parameters, visibility, and return type of a method. | |||
==References== | ==References== | ||
<references/> | <references/> |
Revision as of 17:15, 30 October 2011
Automatic Refactoring
Introduction
Refactoring is a technique for restructuring an existing code, altering its internal structure without changing its external behavior. Its done as a series of small transformations. Each transformation does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.<ref name="refone"> Refactoring Home Page http://refactoring.com/ </ref> As people make changes to the code to realize their short term goals without fully understanding the design of code, the code loses its structure. The refactoring work is done to remove bits that aren’t really in the right place. Loss of the structure of code has a cumulative effect. The harder it is to see the design in the code, the harder it is to preserve it, and the more rapidly it decays. Regular refactoring helps code retain its shape. <ref name="reftwo"> Why should you Refactor http://sourcemaking.com/refactoring/why-should-you-refactor </ref>
Common Refactoring Techniques
Extraction Refactoring
There are several refactoring techniques related to extraction: Extract method, Extract local variables, extract constants. The first method "Extract method will create a new method from code you've selected. Extract Local Variable refactoring takes an expression that is being used repeatedly and assigns it to a local variable. Extract constant refactoring is to select a static, constant expression, which the refactoring will convert to a static final constant. This is useful for removing hard-coded numbers and strings from your code
Inline Refactoring
This type refactoring is the reverse of local variable extraction, in which we remove a local variable and use the value of the variable(typically an expression) in the place where the variable is used. This can be marginally more efficient than using a temporary variable and, by making the code terser, makes it either easier to read or more cryptic, depending on your point of view
Encapsulating Fields
Generally its not a good practice to expose the class attributes through public interface. Thus, Encapsulating such fields will make such fields as private or protected as appropriate and generate getters and setters for the associated field.
Changing Method Signature
Here we change the change the parameters, visibility, and return type of a method.
References
<references/>