CSC/ECE 517 Fall 2009/wiki1a 8 nd: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(33 intermediate revisions by 2 users not shown)
Line 1: Line 1:
='''Problem Statement'''=
='''Problem Statement'''=


The list of refactorings has become quite long & people don't remember long lists very well.  To promote learning the different patterns, they should be categorized in some way, or perhaps, along various dimensions. Here is an attempt to categorize the various available refactoring methods into different categories along as many different dimensions as makes sense. As a reference we have taken the list of refactorings methods available at http://www.refactoring.com/catalog/index.html.
The list of refactorings has become quite long & people don't remember long lists very well.  To promote learning the different patterns, they should be categorized in some way, or perhaps, along various dimensions.Here is an attempt to categorize the various available refactoring methods into different categories along as many different dimensions as makes sense. As a reference we have taken the list of refactorings methods available at http://www.refactoring.com/catalog/index.html.


='''Categorization of Refactoring Methods'''=
='''Categorization of Refactoring Methods'''=
=='''Categorization Framework Used'''==
=='''Categorization Framework Used'''==
When an application is developed using an object oriented programming language the code architecture is designed in the following way. First the functionality of the application is divided into major chunks & assigned to sets of packages which form the first level of hierarchy for the program.  
When an application is developed using an object oriented programming language the code architecture is designed in the following way. First the functionality of the application is divided into major chunks and assigned to sets of packages which form the first level of hierarchy for the program.  


The second level of hierarchy are the compilation units which has access to all types declared in its package and also automatically import all of the public types(in other packages/files) declared in the package. Types consist of classes & interfaces.  
The second level of hierarchy is the compilation unit which has access to all public types declared in its package and also automatically imports them. Types consist of classes and interfaces.  


The functionality implemented in a package is further broken down & implemented using classes at the third level of hierarchy. Classes are made out of items, which are basically methods & fields. Fields declare data which are associated with the class. Interfaces encode the similarities among classes.  
The functionality implemented in a package is further broken down and implemented using classes at the third level of hierarchy. Classes are made out of items, which are basically methods and fields. Fields declare data which are associated with the class.Interfaces encode the similarities among classes.  


In order to store multiple values of the same type of data, the fourth level of hierarchy i.e. a # of objects are created which act as data structures and store data associated with the class.
The fourth level of hierarchy consists of objects which act as data structures and store data associated with the class. This helps to store multiple values of the same type of data.


At the lowest level i.e the fifth is the data, which is a part of the object & also at this level is the code which processes this data, which is a part of the method.  
At the lowest level i.e the fifth is the data, which is a part of the object. At this level, the code which is a part of the method processes this data.  


This hierarchy is followed during any application development using an object oriented language & when an analyst is asked to refactor code, he/she also parses through this same hierarchy to understand the code functionality & to find spots where the code can be refactored.  
This hierarchy is followed during any application development using an object oriented language and when an analyst is asked to refactor code, he/she also parses through this same hierarchy to understand the code functionality and to find spots where the code can be refactored.  


Most of the refactoring methods belong to level 3, level 4 and level 5, hence these categories have again been divided into sub-categories, to reduce generalization & make the categorization more specific. Here is an attempt to make categorization of the refactoring methods based on the said hierarchy. Also there are a two categories whose inspiration isn't the above hierarchy.Here are the categories & sub-categories using which the refactorings methods available at http://www.refactoring.com/catalog/index.html have been categorized.
Most of the refactoring methods belong to level 3, level 4 and level 5, hence these categories have again been divided into sub-categories, to reduce generalization & make the categorization more specific. Here is an attempt to make categorization of the refactoring methods based on the said hierarchy. Also there are a few categories which aren't derived from the above hierarchy. Here are the categories and sub-categories using which the refactoring methods available at http://www.refactoring.com/catalog/index.html have been categorized.


=='''Categories'''==
=='''Categories'''==
Line 29: Line 29:
*'''Changing Class Association'''
*'''Changing Class Association'''
A refactoring method falls in this category if it tries to change the association between two classes so that features of a class may be added or removed.
A refactoring method falls in this category if it tries to change the association between two classes so that features of a class may be added or removed.
  **Change Unidirectional Association to Bidirectional
  *Change Unidirectional Association to Bidirectional
  **Change Bidirectional  Association to Unidirectional  
  *Change Bidirectional  Association to Unidirectional
 
*Extract Interface
*'''Change of Class Structure'''
 


*'''Change of Class Structure''' A refactoring method falls in this category when it tries to change the hierarchy that the classes share amongst them.
**Splitting of Class
**Splitting of Class
*Duplicate Observed Data
*Extract Class
*Extract SubClass
*Extract SuperClass
*Separate Data Access Code
*Localize Disparate Logic
**Merging of  Class
**Merging of  Class
*Collapse Hierarchy
*Replace Subclass with Fields
*Inline Class


*'''Inter-Class Movement of Items'''
A refactoring method falls in this category when it tries to move functionality/detail between classes. This may involve movement of constructors, fields or methods between classes.
*Pull up Constructor Body
*Pull up Field
*Pull up Method
*Push Down Field
*Push Down Method
*Move Field
*Move Method
*'''Moving Additional Functionality to Client Class'''
A refactoring method falls in this category when functionality needs to be added to a server class which cannot be altered. The refactoring method achieves it by adding sever class extensions to the client method.
*Introduce Local Extension 
*Introduce Foreign Method


*'''Addition to a Class''' *What about the ulta of this?
*'''Replacement of Class Instantiation with Constructors'''
A refactoring method falls in this category when it tries to add functionality/detail to a class. This may involve adding constructors, feilds or methods to a class.
**Pull up Constructor Body
**Pull up Field
**Pull up Method
**Push Down Field
**Push Down Method
 
*'''Replacement of Class Instanciation with Constructors'''
A refactoring method falls in this category when it tries to convert loading of some of the classes from dynamic to static or vice-versa.  
A refactoring method falls in this category when it tries to convert loading of some of the classes from dynamic to static or vice-versa.  


  **Convert Static to Dynamic Construction
  *Convert Static to Dynamic Construction
  **Convert Dynamic to Static Construction
  *Convert Dynamic to Static Construction


===Refactoring the Method===
===Refactoring the Method===
Line 57: Line 72:
*'''Meaningful and Detailed Method Calls'''
*'''Meaningful and Detailed Method Calls'''
A refactoring method will fall under this category if it modifies a method call to pass more data to the method or tries to make the method call more understandable.
A refactoring method will fall under this category if it modifies a method call to pass more data to the method or tries to make the method call more understandable.
  **Add Parameter
  *Add Parameter
  **Preserve Whole Object
  *Preserve Whole Object
  **Rename Method
  *Rename Method


*'''Change of Structure of the Method Code'''
*'''Change of Structure of the Method Code'''
A refactoring method will fall under this category if it deliberately changes the internal flow of the code without affecting the output. These methods need not result in the optimization of the code or simplification.
A refactoring method will fall under this category if it deliberately changes the internal flow of the code without affecting the output. These methods need not result in the optimization of the code or simplification.
  **Consolidate Conditional Expression
  *Consolidate Conditional Expression
  **Encapsulation Collection
  *Encapsulation Collection
  **Extract Method
  *Extract Method
  **Inline Method
  *Inline Method
  **Form Template Method
  *Form Template Method
  **Replace Nested Conditional with Guard Clauses
  *Replace Nested Conditional with Guard Clauses
  **Replace Parameter with Method
  *Replace Parameter with Method


*'''Change Method Call Hierarchy/Sequence'''
*'''Change Method Call Hierarchy/Sequence'''
A refactoring method will fall in this category when it tries to change the method call flow in any way.  
A refactoring method will fall in this category when it tries to change the method call flow in any way.  
  **Remove Middle man
  *Remove Middle man
  **Replace Delegation with Inheritance
  *Replace Delegation with Inheritance
  **Replace Inheritance with Delegation
  *Replace Inheritance with Delegation


*'''Improve Method Readability'''
*'''Improve Method Readability'''
A refactoring method will fall under this category when it increases the readability of the code for a new person reading the code or for debugging purpose if ever needed.
A refactoring method will fall under this category when it increases the readability of the code for a new person reading the code or for debugging purpose if ever needed.
  **Introduce Explaining Variable
  *Introduce Explaining Variable
  **Replace Magic No with Symbolic Constant  
  *Replace Magic No with Symbolic Constant
  **Split Temporary Variable
  *Replace Recursion with Iteration
*Split Temporary Variable


*'''Method Code Refactoring based on Method Arguments'''
*'''Method Code Refactoring based on Method Arguments'''
A refactoring method will fall under this category when it makes the behavior of the executed method code, change depending on the argument passed, or when it frees the method code of this feature.  
A refactoring method will fall under this category when it makes the behavior of the executed method code, change depending on the argument passed, or when it frees the method code of this feature.  
  **Replace Conditional with Polymorphism
  *Parameterize Method
  **Replace Conditional with Visitor
*Replace Conditional with Polymorphism
  **Replace Parameter with Explicit Methods
  *Replace Conditional with Visitor
  *Replace Parameter with Explicit Methods


===Refactoring the Object===
===Refactoring the Object===
Line 93: Line 110:
*'''Replacements with Objects'''
*'''Replacements with Objects'''
A refactory method will fall under this category when the code is changed such that its execution is more centered around the object. And different parameters like array, data values are replaced by objects.
A refactory method will fall under this category when the code is changed such that its execution is more centered around the object. And different parameters like array, data values are replaced by objects.
  **Introduce Null Object
  *Introduce Null Object
  **Introduce Parameter Object
  *Introduce Parameter Object
  **Replace Array with Object
  *Replace Array with Object
  **Replace Data Value with Object
  *Replace Data Value with Object
  **Replace Method with Method Object
  *Replace Method with Method Object
  **Replace Record with Data Class
  *Replace Record with Data Class


*'''Object Initialization'''
*'''Object Initialization'''
A refactory method will fall under this category when it tries to alter the constructor used for the initialization of the object.
A refactory method will fall under this category when it tries to alter the constructor used for the initialization of the object.
  **Replace Constructor with Factory Method
  *Replace Constructor with Factory Method
  **Remove Setting Method
  *Remove Setting Method


*'''Accessing the Object/Data'''
*'''Accessing the Object/Data'''
A refactory method will fall under this category Accessing the object / Data if the method changes the way an object or data is accessed.
A refactory method will fall under this category if the method changes the way an object or data is accessed.
  **Change Reference to Value
  *Change Reference to Value
  **Change Value to Reference
  *Change Value to Reference
  **Refactor Architecture by Tiers
  *Refactor Architecture by Tiers
  **Self Encapsulate Field
  *Self Encapsulate Field


===Refactoring the Code===
===Refactoring the Code===
Line 116: Line 133:
*'''Code Optimization'''
*'''Code Optimization'''
A refactoring method will fall under this category when the method brings about change in the code such a way that its execution is optimized.
A refactoring method will fall under this category when the method brings about change in the code such a way that its execution is optimized.
  **Consolidate Duplicate Conditional Fragments
  *Consolidate Duplicate Conditional Fragments
  **Inline Temp
  *Eliminate Inter-Entity Bean Communication
  **Remove Control Flag
*Inline Temp
  **Replace Iteration with Recursion
  *Remove Control Flag
  **Replace Temp with Query
  *Replace Iteration with Recursion
  *Replace Temp with Query
*Use a Connection Pool


*'''Code Reliability Improvement'''
*'''Code Reliability Improvement'''
A refactoring method will fall under this category if it helps to make the code less prone to errors & adhere more to its intended functionality.
A refactoring method will fall under this category if it helps to make the code less prone to errors and adhere more to its intended functionality.
  **Introduce Assertion
  *Introduce Assertion
  **Reduce Scope of Variable
  *Introduce A Controller
  **Remove Assignments to Parameters
*Introduce Synchronizer Token
*Reduce Scope of Variable
  *Remove Assignments to Parameters


*'''Code Simplification'''
*'''Code Simplification'''
A refactoring method will fall under this category when it causes simplification of the code making it more readable & understandable, it may or may not optimize the execution.  
A refactoring method will fall under this category when it causes simplification of the code making it more readable and understandable, it may or may not optimize the execution.  
  **Encapsulate Downcast
  *Encapsulate Downcast
  **Remove Double Negative
  *Remove Double Negative
  **Replace Assignment with Initialization
  *Replace Assignment with Initialization
  **Reverse Conditional
  *Reverse Conditional
  **Separate Query from Modifier
  *Separate Query from Modifier
  **Split Loop
  *Split Loop
  **Substitute Algorithm
  *Substitute Algorithm
  **Decompose Conditional
  *Decompose Conditional


*'''Redundant Code Elimination'''
*'''Redundant Code Elimination'''
A refactoring method will fall under this category if it helps to eliminate the unnecessary code
A refactoring method will fall under this category if it helps to eliminate the unnecessary code
and makes the code cleaner.
and makes the code cleaner.
  **Parametrize Method
  *Parametrize Method
  **Remove Parameter
  *Remove Parameter


*'''Removal of "Type Code"'''
*'''Removal of "Type Code"'''
A refactory method will fall under the category Removal of  "Type Code" if the method helps to remove the type code.
A refactory method will fall under the category Removal of  "Type Code" if the method helps to remove the type code.
  **Replace Type Code with Class
  *Replace Type Code with Class
  **Replace Type Code with State/Strategy
  *Replace Type Code with State/Strategy
  **Replace Type Code with Subclasses
  *Replace Type Code with Subclasses


===Refactoring for Privacy===
===Refactoring for Privacy===

Latest revision as of 14:39, 11 September 2009

Problem Statement

The list of refactorings has become quite long & people don't remember long lists very well. To promote learning the different patterns, they should be categorized in some way, or perhaps, along various dimensions.Here is an attempt to categorize the various available refactoring methods into different categories along as many different dimensions as makes sense. As a reference we have taken the list of refactorings methods available at http://www.refactoring.com/catalog/index.html.

Categorization of Refactoring Methods

Categorization Framework Used

When an application is developed using an object oriented programming language the code architecture is designed in the following way. First the functionality of the application is divided into major chunks and assigned to sets of packages which form the first level of hierarchy for the program.

The second level of hierarchy is the compilation unit which has access to all public types declared in its package and also automatically imports them. Types consist of classes and interfaces.

The functionality implemented in a package is further broken down and implemented using classes at the third level of hierarchy. Classes are made out of items, which are basically methods and fields. Fields declare data which are associated with the class.Interfaces encode the similarities among classes.

The fourth level of hierarchy consists of objects which act as data structures and store data associated with the class. This helps to store multiple values of the same type of data.

At the lowest level i.e the fifth is the data, which is a part of the object. At this level, the code which is a part of the method processes this data.

This hierarchy is followed during any application development using an object oriented language and when an analyst is asked to refactor code, he/she also parses through this same hierarchy to understand the code functionality and to find spots where the code can be refactored.

Most of the refactoring methods belong to level 3, level 4 and level 5, hence these categories have again been divided into sub-categories, to reduce generalization & make the categorization more specific. Here is an attempt to make categorization of the refactoring methods based on the said hierarchy. Also there are a few categories which aren't derived from the above hierarchy. Here are the categories and sub-categories using which the refactoring methods available at http://www.refactoring.com/catalog/index.html have been categorized.

Categories

Refactoring the Package

A refactoring method will fall under this category if the changes made affect the package structure or add to the functionality to the package. The refactoring method generally may involve breaking a package to smaller packages to divide the functionality or moving classes to a more relevant package. 

*Extract Package
*Move Class

Refactoring the Class

  • Changing Class Association

A refactoring method falls in this category if it tries to change the association between two classes so that features of a class may be added or removed. 

*Change Unidirectional Association to Bidirectional
*Change Bidirectional  Association to Unidirectional
*Extract Interface
  • Change of Class Structure A refactoring method falls in this category when it tries to change the hierarchy that the classes share amongst them.
    • Splitting of Class
*Duplicate Observed Data
*Extract Class
*Extract SubClass
*Extract SuperClass
*Separate Data Access Code
*Localize Disparate Logic
    • Merging of Class
*Collapse Hierarchy
*Replace Subclass with Fields
*Inline Class
  • Inter-Class Movement of Items

A refactoring method falls in this category when it tries to move functionality/detail between classes. This may involve movement of constructors, fields or methods between classes. 

*Pull up Constructor Body
*Pull up Field
*Pull up Method
*Push Down Field 
*Push Down Method
*Move Field
*Move Method
  • Moving Additional Functionality to Client Class

A refactoring method falls in this category when functionality needs to be added to a server class which cannot be altered. The refactoring method achieves it by adding sever class extensions to the client method. 

*Introduce Local Extension  
*Introduce Foreign Method
  • Replacement of Class Instantiation with Constructors

A refactoring method falls in this category when it tries to convert loading of some of the classes from dynamic to static or vice-versa. 

*Convert Static to Dynamic Construction
*Convert Dynamic to Static Construction

Refactoring the Method

  • Meaningful and Detailed Method Calls

A refactoring method will fall under this category if it modifies a method call to pass more data to the method or tries to make the method call more understandable. 

*Add Parameter
*Preserve Whole Object
*Rename Method
  • Change of Structure of the Method Code

A refactoring method will fall under this category if it deliberately changes the internal flow of the code without affecting the output. These methods need not result in the optimization of the code or simplification. 

*Consolidate Conditional Expression
*Encapsulation Collection
*Extract Method
*Inline Method
*Form Template Method
*Replace Nested Conditional with Guard Clauses
*Replace Parameter with Method
  • Change Method Call Hierarchy/Sequence

A refactoring method will fall in this category when it tries to change the method call flow in any way. 

*Remove Middle man
*Replace Delegation with Inheritance
*Replace Inheritance with Delegation
  • Improve Method Readability

A refactoring method will fall under this category when it increases the readability of the code for a new person reading the code or for debugging purpose if ever needed. 

*Introduce Explaining Variable
*Replace Magic No with Symbolic Constant
*Replace Recursion with Iteration 
*Split Temporary Variable
  • Method Code Refactoring based on Method Arguments

A refactoring method will fall under this category when it makes the behavior of the executed method code, change depending on the argument passed, or when it frees the method code of this feature. 

*Parameterize Method
*Replace Conditional with Polymorphism
*Replace Conditional with Visitor
*Replace Parameter with Explicit Methods

Refactoring the Object

  • Replacements with Objects

A refactory method will fall under this category when the code is changed such that its execution is more centered around the object. And different parameters like array, data values are replaced by objects. 

*Introduce Null Object
*Introduce Parameter Object
*Replace Array with Object
*Replace Data Value with Object
*Replace Method with Method Object
*Replace Record with Data Class
  • Object Initialization

A refactory method will fall under this category when it tries to alter the constructor used for the initialization of the object. 

*Replace Constructor with Factory Method
*Remove Setting Method
  • Accessing the Object/Data

A refactory method will fall under this category if the method changes the way an object or data is accessed. 

*Change Reference to Value
*Change Value to Reference
*Refactor Architecture by Tiers
*Self Encapsulate Field

Refactoring the Code

  • Code Optimization

A refactoring method will fall under this category when the method brings about change in the code such a way that its execution is optimized. 

*Consolidate Duplicate Conditional Fragments
*Eliminate Inter-Entity Bean Communication
*Inline Temp
*Remove Control Flag
*Replace Iteration with Recursion
*Replace Temp with Query
*Use a Connection Pool
  • Code Reliability Improvement

A refactoring method will fall under this category if it helps to make the code less prone to errors and adhere more to its intended functionality. 

*Introduce Assertion
*Introduce A Controller
*Introduce Synchronizer Token
*Reduce Scope of Variable
*Remove Assignments to Parameters
  • Code Simplification

A refactoring method will fall under this category when it causes simplification of the code making it more readable and understandable, it may or may not optimize the execution. 

*Encapsulate Downcast
*Remove Double Negative
*Replace Assignment with Initialization
*Reverse Conditional
*Separate Query from Modifier
*Split Loop
*Substitute Algorithm
*Decompose Conditional
  • Redundant Code Elimination

A refactoring method will fall under this category if it helps to eliminate the unnecessary code and makes the code cleaner. 

*Parametrize Method
*Remove Parameter
  • Removal of "Type Code"

A refactory method will fall under the category Removal of "Type Code" if the method helps to remove the type code. 

*Replace Type Code with Class
*Replace Type Code with State/Strategy
*Replace Type Code with Subclasses

Refactoring for Privacy

A refactoring method will fall under this category if it helps in data protection and privacy. 

*Encapsulate Field
*Hide Delegate
*Hide Method
*Hide Presentation Tier-Specific Details from the Business tier
*Introduce Business Delegate
*Wrap Entities with Session

Dealing with Exceptions

A refactoring method will fall under this category if it optimizes the way the code handles an exception situation. 

*Remove Error Code with Exception
*Replace Exception with Test

References

http://www.refactoring.com
Refactoring: Improving the Design of Existing Code by Martin Fowler.

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_8_nd&oldid=19044"