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

From Expertiza_Wiki
Jump to navigation Jump to search
Line 20: Line 20:
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. Most of the refactoring methods belong to level 3, level 4 and level 5. 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.
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. Most of the refactoring methods belong to level 3, level 4 and level 5. 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.


==Refactoring Methods==
==Categories==
===Package===
===Package===
sasasas
sasasas

Revision as of 05:03, 5 September 2009

Problem Statement

The list of refactorings has become quite long. But 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. As a reference we have taken the list of refactorings available here and categorized them along as many different dimensions as makes sense.


Here are the categories & sub-categories using which the refactorings available here have been categorized.

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 & 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 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.

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.

At the lowest level 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. The creation of objects of a class, storage of data into the object fields & calling of methods for processing of the object data is controlled from the main function.

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. Most of the refactoring methods belong to level 3, level 4 and level 5. 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.

Categories

Package

sasasas

  • Extract Package
  • Move Class

Class

  • Changing Class Association
    • Change Unidirectional Association to Bidirectional
    • Change Unidirectional Association to Bidirectional
  • Change of Class Structure
    • Collapse Hierarchy
    • Duplicate Observed Data
    • Extract Class
    • Extract SubClass
    • Extract SuperClass
    • Inline Class
    • Replace Subclass with Fields
    • Separate Data Access Code
  • Addition to a Class
    • Pull up Constructor Body
    • Pull up Field
    • Pull up Method
    • Push Down Field
    • Push Down Method

Method

  • Meaningful and Detailed Method Calls
    • Add Parameter
    • Rename Method
    • Preserve Whole Object
  • Change of Structure of the Method Code
    • Extract Method
    • Inline Method
    • Consolidate Conditional Expression
    • Encapsulation Collection
    • Form Template Method
    • Replace Nested Conditional with Guard Clauses
    • Replace Parameter with Method
  • Change Method Call Hierarchy
    • Remove Middle man
    • Replace Delegation with Inheritance
    • Replace Inheritance with Delegation
  • Improve Method Readability
    • Introduce Explaining Variable
    • Replace Magic No with Symbolic Constant
    • Split Temporary Variable
  • Method Code Refactoring based on Method Arguments
    • Replace Conditional with Polymorphism
    • Replace Conditional with Visitor
    • Replace Parameter with Explicit Methods

Object

  • Replacements with Objects
    • Introduce Null Object
    • Replace Array with Object
    • Introduce Parameter Object
    • Replace Data Value with Object
    • Replace Method with Method Object
  • Object Initialization
    • Replace Constructor with Factory Method
  • Accessing the Object/Data
    • Change Reference to Value
    • Change Value to Reference
    • Refactor Architecture by Tiers
    • Self Encapsulate Field

Code

  • Code Optimization
    • Replace Temp with Query
    • Consolidate Duplicate Conditional Fragments
    • Decompose Conditional
    • Inline Temp
    • Introduce Assertion
    • Replace Iteration with Recursion
    • Remove Control Flag
  • Redundant Code Elimination
    • Parametrize Method
    • Remove Parameter
  • Method Code Simplification
    • Remove Double Negative
    • Replace Assignment with Initialization
    • Encapsulate Downcast
    • Reduce Scope of Variable
    • Reverse Conditional
    • Separate Query from Modifier
    • Split Loop
    • Substitute Algorithm
  • Removal of "Type Code"
    • Replace Type Code with Class
    • Replace Type Code with State/Strategy
    • Replace Type Code with Subclasses

Refactoring for Privacy

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

Dealing with Exceptions

  • Remove Error Code with Exception
  • Replace Exception with Test

References