Main Pagehttp:/pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2009/wiki2 7 cn: Difference between revisions
No edit summary |
|||
Line 2: | Line 2: | ||
Different languages have different mechanisms for "code reuse". Assembly and low level languages have macros, C/C++ has includes, Ruby has mixins and modules, Java has packages, and there are many other concepts around reuse and extension. Here is a page that describes the various mechanisms, groups the mechanisms into logical categories, and discusses the advantages and disadvantages of the various schemes, in terms of simplicity, performance, reliability, or other factors. | Different languages have different mechanisms for "code reuse". Assembly and low level languages have macros, C/C++ has includes, Ruby has mixins and modules, Java has packages, and there are many other concepts around reuse and extension. Here is a page that describes the various mechanisms, groups the mechanisms into logical categories, and discusses the advantages and disadvantages of the various schemes, in terms of simplicity, performance, reliability, or other factors. | ||
='''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. |
Revision as of 22:46, 7 October 2009
Problem Statement
Different languages have different mechanisms for "code reuse". Assembly and low level languages have macros, C/C++ has includes, Ruby has mixins and modules, Java has packages, and there are many other concepts around reuse and extension. Here is a page that describes the various mechanisms, groups the mechanisms into logical categories, and discusses the advantages and disadvantages of the various schemes, in terms of simplicity, performance, reliability, or other factors.
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.