Seminar Report On
Software Refactoring
Submitted by
Vinitha K V
In the partial fulfillment of requirements in degree of
Master of Technology (M-Tech) in Software Engineering
DEPARTMENT OF COMPUTER SCIENCE
COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY
KOCHI-682022
2007 Page 2

Software Refactoring
Department of Computer Science, CUSAT
2
ACKNOWLEDGEMENT
I thank GOD almighty for guiding me throughout the seminars. I would like to
thank all those who have contributed to the completion of the seminar and helped
me with valuable suggestions for improvement.
I am extremely grateful to Prof. Dr. K Paulose Jacob, Director, Department of
Computer Science, for providing me with best facilities and atmosphere for the
creative work guidance and encouragement. I would like to thank my coordinator,
Dr. Sumam Mary Idicula for all help and support extend to me. I thank all staff
members of my college and friends for extending their cooperation during my
seminars.
Above all I would like to thank my parents without whose blessings; I would not
have been able to accomplish my goal. Page 3

Software Refactoring
Department of Computer Science, CUSAT
3
ABSTRACT
Producing software is a very complex process that takes a considerable
time to evolve. Poorly designed software systems are difficult to understand and
maintain. Modifying code in one place could lead to unwanted repercussions
elsewhere due to high coupling. Adding new features can cause further quality
degradation to the code if proper design and architectural concerns were not
implemented. Development in a large enterprise system with such attributes will,
over time, lead to a myriad of concerns unless the system is periodically
overhauled or refactored in some way.
Software maintenance can take up to 50% of the overall development
costs of producing software. One of the main attributes to these high costs is
poorly designed code, which makes it difficult for developers to understand the
system even before considering implementing new code. In the context of
software engineering process, Software Refactoring has a direct influence on
reducing the cost of software maintenance through changing the internal
structure of the code to increase the design which helps the present and future
developers evolve and understand the system.
Refactoring is a disciplined technique for restructuring an existing body of
code, altering its internal structure without changing its external behavior. Its
heart is a series of small behavior preserving transformations. Each
transformation called a 'refactoring' 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.
Keywords :
Floss Refactoring, Root canal Refactoring, Code Bad Smells,
Remove Parameter, Inline Method/Class, Pull up method, push down method,
Move Field/Class, Encapsulate field, Collapse Hierarchy, Hide Delegate,
Remove Middle man, Extract function Page 4

Software Refactoring
Department of Computer Science, CUSAT
4
Index
1. Introduction¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦..¦¦1
1.1 Background¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦.....1
1.2 Emergence of Refactoring¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦.2
2. Refactoring
Approach¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦.¦¦¦¦¦¦¦..4
2.1. Refactoring
Definition¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦..4
2.2. Why do we need Refactoring ? ¦¦¦¦¦¦¦¦¦¦¦¦¦¦.¦¦¦..5
2.3 Where to Refactor ?¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦.¦¦¦..5
2.3.1 Principle of Refactoring¦¦¦¦¦¦¦¦¦¦¦¦¦¦.¦¦.....6
2.4 Types of Refactoring¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦.¦......6
2.5 Benefits of Refactoring¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦.¦¦¦.¦¦.7
2.6 Risks of Refactoring¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦8
3. Refactoring Activities¦¦¦¦¦¦¦¦¦¦¦¦.¦¦¦¦¦¦¦¦¦¦¦¦9
3.1 Bad Smells in Code¦¦¦¦¦¦¦¦¦¦¦¦¦.¦¦¦¦¦..¦¦¦¦10
3.1.1 A Few Bad Smells and Solutions.¦¦¦¦¦¦¦.¦¦¦.¦¦¦¦10
4. Refactoring Techniques¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦..¦¦¦13
4.1 A Few Refactoring Techniques¦¦¦¦¦¦¦¦¦¦¦¦¦¦..¦¦¦.13
4.2 Refactoring Examples¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦.¦¦¦¦15 Page 5

Software Refactoring
Department of Computer Science, CUSAT
5
5. Refactoring Tool Support¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦.¦¦..¦24
5.1 Language Support¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦24
5.2 Tool Support “ Eclipse Java Refactoring¦¦¦.¦¦¦¦¦¦¦¦¦¦ 26
6. Conclusion¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦..¦¦¦.29
7. Reference¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦..¦¦¦¦¦¦¦¦¦..¦.¦¦30Page 6

Software Refactoring
Department of Computer Science, CUSAT
6
INTRODUCTION
Software Refactoring is an important part of the software development process,
especially in the maintenance phase. For many years, several studies revealed
that the cost of software maintenance is greater than the cost of development.
Refactoring can aid the developer to improve the design of the code and to make
it cleaner, without changing its behaviour.
Background
In the context of a software engineering process, maintenance is the phase that
applies changes to existing software, as the environment and requirements
evolve. There are four different types of changes applied during software
maintenance: correction, to fix defects, adaptation, to meet changing
requirements, enhancement, to add new functionality, and prevention, to improve
the flexibility of the software anticipating the other kinds of changes. The last type
of change originates what is known as preventive maintenance or software
reengineering which prevents deterioration of software over time.
Even after the software has been released, the environment is in constant
change and it urges many modifications. Over the years, different software
engineers handle modifications on the same system, modifications that should be
performed as fast as possible to keep a good standing in a competitive market.
As a result, at some point the system becomes unstable and any change can
provoke serious side effects. However, if preventive maintenance is constantly
applied in the process, every change is followed by a revision and restructuring
that leaves the software prepared and open to be further corrected, adapted or
enhanced more easily.
Preventive maintenance comprises several activities: inventory analysis,
document restructuring, reverse engineering, code restructuring, data
restructuring and forward engineering. Code and data restructuring together can Page 7

Software Refactoring
Department of Computer Science, CUSAT
7
be termed as software refactoring. It is then targeted at the activity of the
programmer of code modification, while he/she prevents the code to decay.
Code restructuring comprises the detection of duplicate code, non-reusable
code, illegible code, problems in data structures and many other problems that a
compiler cannot detect because the semantics of the program are still correct. It
has a detection phase and the corresponding correction phase. The correction
phase should not modify the behavior of the program; it should leave it more
maintainable, reusable and understandable to a new developer.
Emergence of Refactoring
Refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code, yet improves its internal
structure. That is, while improving the code, it only implies syntactic changes.
The idea of refactoring originated from restructuring object-oriented (OO)
systems. The first detailed written work about refactoring was published in a PhD
thesis written by William Opdyke in 1992. The term refactoring was coined by
William Opdyke and Ralph Johnson. Nowadays, refactoring is being used to
represent both the process and the techniques, and is applied to other than OO
languages. The emergence of refactoring in the OO field can be attributed to the
complications that programmers usually find when trying to achieve reuse. The
OO paradigm appears to be the key to reuse, but in fact a reusable OO
application is only obtained after several iterations and after gaining proficient
knowledge about the application domain.
Research on restructuring OO systems was first focused on inheritance.
However, Opdyke seems to be the first in presenting a wider catalog ofPage 8

Software Refactoring
Department of Computer Science, CUSAT
8
refactorings that not only involved moving things up or down in an inheritance
hierarchy but also renaming entities, splitting components, removing conditional
statements, etc. Opdyke describes low-level refactorings and then he composes
these to form complex refactorings. The low-level or basic refactorings in his
catalog are:
- Creating a program entity (where an entity is a class, a variable or a method)
- Deleting a program entity
- Changing a program entity
- Moving a member variable
The combination of the above refactorings leads to the following composite
refactorings:
- Refactoring to generalize: creating an abstract super class.
- Refactoring to specialize: sub classing and simplifying conditionals.
- Refactoring to capture aggregations and components.
William Griswold is another pioneer in the area of software restructuring. He has
approached restructuring from a different perspective: helping the programmer to
recognize and plan for restructuring. His research group is working on the Star
Diagram, a graphical view of a data structure and its uses in the code. The Star
Diagram has been implemented for Ada, C, C++ and Java.Page 9

Software Refactoring
Department of Computer Science, CUSAT
9
REFACTORING APPROACH
Refactoring Definition
One definition of the word factor means to influence something. To refactor
means to re-influence something that already exists. There is however a more
precise meaning in the computer science context. In order to successfully
refactor a program, one needs to change (and thus re-influence) the program in
such a way as to improve the design and simultaneously preserve its behavior.
Refactoring is relatively a new area of research and so is not well defined. There
are a vast number of definitions for refactoring, some of them are mentioned
below.
[Fowler1999] A change made to the internal structure of software to make it
easier to understand and cheaper to modify without changing its observable
behaviour.
[Roberts1998] A behavior-preserving source-to-source program transformation
[Beck1999] A change to the system that leaves its behavior unchanged, but
enhances some non-functional quality - simplicity, flexibility, understandability.
Refactoring (noun): a change made to the internal structure of software to make
it easier to understand and cheaper to modify without changing its observable
behavior. Refactoring (verb): to restructure software by applying a series of
Refactoring without changing its observable behavior. To refactor programming
code is to rewrite the code, to "clean it up" .Refactoring is the moving of units of
functionality from one place to another in the program. Refactoring has a primary
objective of getting each piece of functionality to exist in exactly one place. It is
the process of taking an object design and rearranging it in various ways to make
the design more flexible and/or reusable. Page 10

Software Refactoring
Department of Computer Science, CUSAT
10
Why Do We Need Refactoring?
Continuous design allows one to add more flexibility into the design, by adding to
an initially simple design as the need arises, instead of having a big upfront
design. Thus the design will evolve as the code grows. There is a shift from
building software towards growing it. The process of refactoring can be used to
contribute to these evolving states of the code.
Refactoring improves the design of software
Without refactoring the design of the program will decay. Poorly designed
code usually takes more to do the same things, often because the does the same
thing in different places
Refactoring makes the code easier to understand
In most software development environments, somebody else will
eventually have to read the code so it becomes easy for others to comprehend.
Refactoring helps to find bugs
It helps in finding the Bugs present in the program.
Refactoring helps to program faster
It helps us to do the coding/programming faster as we have better
understanding of the situation.
Where to refactor?
Refactoring can be used in different contexts. For example: to improve the
design and code quality of existing systems; to help evolve the design of systems
dynamically through incremental development with practices such as test driven
development and agile methodologies, thereby negating the need for a big Page 11

Software Refactoring
Department of Computer Science, CUSAT
11
upfront design; to understand how existing code works; to manage change in a
software organization; to perform refactoring at an architectural level; and to
refactor code, with design patterns as targets of the refactoring
Principle of Refactoring
The Rules of Three:
It was formulated by Don Roberts
¢
Refactor when a function is added
Sometimes the existing design does not allow to easily add the feature.
If refactoring is performed while adding a function then code is easier
to understand.
¢
Refactor when a bug is being fixed
If a bug is reported itâ„¢s a sign that the code needs refactoring because
the code was not clear enough to see the bug in the first place.
¢
Refactor when code is reviewed
Code reviews help to spread knowledge through the development
team. This works best with small review groups.
Types of Refactoring
Floss Refactoring
Floss refactoring is interleaved with normal programming. Programmers refactor
constantly to maintain healthy software. Continuous design and continuous
refactoring are key practices for agile programmers. This minimizes the
investment in excess framework and support code. Page 12

Software Refactoring
Department of Computer Science, CUSAT
12
Root Canal Refactoring
In root canal refactoring programming and refactoring are distinct activities.
Programmers refactor in clumps to fix unhealthy software.
Benefits of Refactoring
Refactoring is useful to any program that has at least one of the following
shortcomings:
Programs that are hard to read are hard to modify.
Programs that have duplicate logic are hard to modify
Programs that require additional behavior that requires you to change
running code are hard to modify.
Programs with complex conditional logic are hard to modify
Refactoring helps to achieve:
1. Better perceptive of the system:
Refactoring produces shorter simpler methods. It's less work to understand
the smaller amount of code that needs to be changed to implement any given
function.
2. Fine-grained encapsulation, for easier debugging and code reuse:
Improves time to market through reuse because existing applications are
made reusable by employing refactoring where needed.
3. Generalization of existing code, to make it easier to apply existing code to
a broader range of problems
4 Reduced costs and risks of development as compared to a complete
application rewrite effort. Adding new features no longer corrupts the system's
structure. Optimizing the maintenance process to minimize the visible
changes to the source code must, as with any optimization, compromise
something else: In programming, what get compromised are the readability, Page 13

Software Refactoring
Department of Computer Science, CUSAT
13
maintainability, and logical structure of the system being maintained. So, over
time, a system maintained without refactoring will become unmaintainable,
and must be scrapped and rewritten from scratch. Refactoring avoids the
costs of working with unmaintainable code, and the eventual cost of replacing
the system.
Refactoring Risks
Introducing a failure with refactoring can have serious consequences. When
done on a system that is already in production, the consequences of introducing
bugs without catching them are very severe. Managers and developers hesitate
because donËœt want to spend additional time. It is difficult to forecast how local
improvement changes the global architecture (process should favor strategic
architecture design and tactical architecture design).
¢ Databases
Most business applications are tightly coupled to the database schema
that supports them. We have to isolate changes to either the database
or object model by creating a layer between the models. Such a layer
adds complexity buts enhance flexibility.
¢ Changing interfaces
“ Don't publish interfaces prematurely -- modify your code ownership
policies to smooth refactoring
¢ Design changes that are difficult to refactor
¢ Cultural issues
Sometimes refactoring may lead to serious errors in the code. Instead of
adding new features it will accumulate negative lines of codes. Page 14

Software Refactoring
Department of Computer Science, CUSAT
14
REFACTORING ACTIVITIES
The refactoring process consists of a number of different activities, each of which
can be automated to a certain extent:
(1) Identify where the software should be refactored;
(2) Determine which refactorings should be applied to the identified places;
(3) Guarantee that the applied refactoring preserves behavior;
(4) Apply the refactoring;
(5) Assess the effect of refactoring on software quality characteristics;
(6) Maintain consistency between refactored program code and other software
artifacts (or vice versa).
The steps taken when applying the refactoring should be small enough to
oversee the consequences they have and reproduceable to allow others to
understand them. Generalized refactoring steps in a way, are more a rule that
can be applied to any structure.
Refactoring as proposed by Fowler not only covers the mechanics of
restructuring, but also addresses the following issues:
¢ Refactoring emphasizes that, in absence of more formal guarantees, testing
should be used to ensure that each restructuring is behavior preserving. A rich
test suite should be built, which must be run before and after each test is applied.
¢ Refactorings are described in a catalog, using a template reminiscent of design
patterns.
¢ Refactorings are applied in small steps, one by one, running the test suite after
every step to make it into commercial development tools. Page 15

Software Refactoring
Department of Computer Science, CUSAT
15
Bad Smells in Code
Code smell is any symptom that indicating something wrong. It generally
indicates that the code should be refactored or the overall design should be
reexamined. The term appears to have been coined by Kent Beck .Usage of the
term increased after it was featured in Refactoring. Bad code exhibits certain
characteristics that can be rectified using Refactoring. These are called Bad
Smells
A Few Bad Smells and Solutions
Duplicated Code
If the same code structure appears in more than one place, then the
program need to be refactored
Solution: perform EXTRACT METHOD and invoke the code from both places.
Lazy Class
A class that is not carrying its weight should be eliminated.
Solution: If the subclasses are not doing enough try to use Collapse Hierarchy
and nearly useless components should be subjected to Inline Class
Long Method
The longer a procedure is the more difficult it is to understand.
Solution: perform EXTRACT METHOD
Divergent Change
Divergent change occurs when one class is commonly changed in different
ways for different reasons. If for example you have to change 4 different
methods every time the database changes you might have a situation where
two objects are better than one.
Solution: To clean this up identify everything that changes for a particular
cause and use Extract Class to put them all together Page 16

Software Refactoring
Department of Computer Science, CUSAT
16
Large class
When a class is trying to do too much, it often shows up as too many instance
variables.
Solution: Perform EXTRACT CLASS
Shotgun Surgery
This situation occurs when every time a change is made, a lot of little
changes have to be made to different classes. When the changes are all over
the place, they are hard to find and itâ„¢s easy to miss an important change.
Solution: Use Move Method and Move Field to put all the changes in a single
class. If no current class looks like a good candidate then create one. Or
perform MOVE METHOD/FIELD or INLINE Class to bring a whole bunch of
behavior together.
Feature Envy
A classic smell is a method that seems more interested in a class other in the
one that it is in. The method clearly wants to be elsewhere.
Solution : Use Move Method to get it there. Sometimes only part of the
method suffers from envy so in that case use Extract Method on the jealous
bit and Move Method to get it home.
Switch Statements
Once a switch statement is seen consider polymorphism.
Solution: Use Extract Method to extract the switch statement and then Move
Method to get it into the class where the polymorphism is needed Page 17

Software Refactoring
Department of Computer Science, CUSAT
17
Middle Man
One the major features of Objects is encapsulation. Encapsulation often
comes with delegation. Delegation is often useful, but sometimes it can go too
far. If a class is acting as a delegate, but is performing no useful extra work, it
may be possible to remove it from the hierarchy.
Solution: If half the methods are delegated to another class it might be time to
use Remove Middle Man. If only a few methods are not doing much, use
Inline Method to inline them into the caller.
Message Chains
Message chains occur when a client asks one object for another object, which
is then asked for another object, which is then asked for another, and so on.
This ties the code to a particular class structure
Solution: Use Hide Delegate at various points in the chain
Data Clumps
The same cluster data items are seen in lots of places. For example, fields in
a couple of classes, or parameters in many method signatures.
Solution: The first step is to look for where the clumps appear as fields and
use Extract Class to turn the clumps into an object Page 18

Software Refactoring
Department of Computer Science, CUSAT
18
REFACTORING TECHNIQUES
A Few Refactoring Techniques
Add Parameter
Rename Method
Remove Parameter
Move Field
Extract method
Extract class
Extract Interface
Hide delegate
Pull up Method
Push down Method
Push down Field
Inline class
Inline Method
Encapsulate field
Collapse hierarchy
Add a parameter to a function: add a new argument to the definition of a
function. This refactoring is rather complex because every call to the function has
to be changed adding the actual parameter or expression with the help of the
user.
Rename variable: change the name of a variable throughout and only in its
scope. No other variable with the new name may exist in the same scope. The
scope may be local to a function (including parameters) or composite statement,
global to a function or global to a file. If the new name conflicts with the name of
another variable defined in an outer scope, the user is inquired to continue. Page 19

Software Refactoring
Department of Computer Science, CUSAT
19
Rename function: change the name of a function in its definition and every call
to the function in the file where it is defined and the files that include that one.
Complex refactorings: the refactorings that follow are composed of other
refactorings. Their complexity is higher because they need to maintain more
preconditions.
Extract function: Method extraction is a complex refactoring. It has to transform
statements of source code and preserve semantics. Extract function is a kind of
refactoring in which a complicated expression or statement list is replaced with a
function call. When a function gets too long or complicated, a good practice is to
divide it into smaller fragments, turn each fragment into a function and replace
the long function for a shorter one with function calls. The code extracted is
scanned and for each reference to local variables in the source fragments, turn
each fragment into a function and replace the long function for a shorter one with
function calls. The code extracted is scanned and for each reference to local
variables in the source function, a parameter is added to the extracted function.
This refactoring is common also to replace direct variable access by calls to
accessor functions.
Inline function: Replace the selected function call with the body of the called
function. Every formal parameter and local declarations inside the called function
are added as declarations inside the calling function, changing names if
necessary to avoid collisions. Then, an assignment statement is added to the
beginning of the inlined code for each formal parameter, assigning the actual
parameter expression.
If the called function returns a value, the code is inlined before the expression
that calls the function, and every return statement in the body of the function is
transformed into an assignment to a new variable. The expression that contained
the call now uses the new variable. Page 20

Software Refactoring
Department of Computer Science, CUSAT
20
Refactoring Examples
Add Parameter
A method needs more information from its caller.
Add a parameter for an object that can pass on this information.
Rename Method
The name of a method does not reveal its purpose.
Change the name of the method. Page 21

Software Refactoring
Department of Computer Science, CUSAT
21
Remove Parameter
A parameter is no longer used by the method body.
Remove it.
Move Field
A field is, or will be, used by another class more than the class on which it is
defined.
Create a new field in the target class, and change all its users. Page 22

Software Refactoring
Department of Computer Science, CUSAT
22
Extract Method
A fragment of code that can be grouped together, turn it into a method with a
name that explains the purpose of the method.
void printFormatted(string text)
{
System.out.println (žCopyright © 1006, Siemens AG);
System.out.println (žAuthor: Michael Stal);
printRest(text);
}
void printFormatted(string text) {
printHeader();
printRest(text);
}
printHeader()
{
System.out.println(žCopyright © 1006, Siemens AG);
System.out.println(žAuthor: Michael Stal);}
Extract Class
One class doing work that should be done by two.
Create a new class and move the relevant fields and methods from the old
class into the new class. Page 23

Software Refactoring
Department of Computer Science, CUSAT
23
Extract Interface
Several clients use the same subset of a class's interface, or two classes have
part of their interfaces in common.
Extract the subset into an interface. Page 24

Software Refactoring
Department of Computer Science, CUSAT
24
Hide Delegate
A client is calling a delegate class of an object.
Create methods on the server to hide the delegate.
Pull Up Method
You have methods with identical results on subclasses.
Move them to the super class. Page 25

Software Refactoring
Department of Computer Science, CUSAT
25
Push Down Field
A field is used only by some subclasses.
Move the field to those subclasses.
Push Down Method
Behavior on a super class is relevant only for some of its subclasses.
Move it to those subclasses. Page 26

Software Refactoring
Department of Computer Science, CUSAT
26
Inline Method
A method's body is just as clear as its name.
Put the method's body into the body of its callers and remove the method.
int getRating() {
return (moreThanFiveLateDeliveries()) ? 2 : 1;
}
boolean moreThanFiveLateDeliveries() {
return _numberOfLateDeliveries > 5;
}
int getRating() {
return (_numberOfLateDeliveries > 5) ? 2 : 1;
}
Inline Class
A class isn't doing very much.
Move all its features into another class and delete it. Page 27

Software Refactoring
Department of Computer Science, CUSAT
27
Encapsulate Field
There is a public field.
Make it private and provide accessors.
public String _name
private String _name;
public String getName()
{
return _name;
}
public void setName(String arg)
{
_name = arg;
}Page 28

Software Refactoring
Department of Computer Science, CUSAT
28
Collapse Hierarchy
A super class and subclass are not very different.
Merge them together.
Remove Middle Man
A class is doing too much simple delegation.
Get the client to call the delegate directly. Page 29

Software Refactoring
Department of Computer Science, CUSAT
29
REFACTORING TOOL SUPPORT
Language Support
Support for restructuring has been provided in a variety of different programming
languages and language paradigms: imperative or procedural languages
(Fortran, Cobol, C); functional languages (Scheme, Lisp, Haskel); logic
languages (e.g., Prolog); class-based object-oriented languages (Smalltalk, Java,
C++); prototype-based object oriented languages (e.g., Self ); aspect-oriented
languages (e.g., AspectJ).
Tool Support
Refactoring tools are difficult to construct. They need to be correct but also highly
usable, where "usable" in this context includes interactive, fast, user-friendly,
integrated, and exploratory. After some experience on constructing refactoring
tools is gained, the task of expanding to new programming languages may
hopefully become easier.
Refactoring was first put into practice in the Refactoring Browser for Smalltalk,
and since then, refactoring tools have become popular in other environments,
most notably Java. There are various IDEs which provide automated refactoring
for Java code. Interestingly, most of the refactoring toolkits for Java are actually
products which plug-in to one or more existing IDEs. Some of the commonly
used
refactoring
tools
are
Smalltalk(Smalltalk
Refactoring
Browser),Java(IntelliJ,Eclipse,JFactor),.NET(C#Reafctory,ReSharper),C/C++(Sli
ckEdit,Xrefactory) Page 30

Software Refactoring
Department of Computer Science, CUSAT
30
Eclipse was among the first IDEs to help bring refactoring to the
mainstream developer. Eclipse version 1.0 included several highly useful Java
refactorings, which are nowadays staple tools in most Java developers' toolbox.
These included Rename, Move, and Extract Method. Eclipse 2.0 added a lot of
statement-level refactorings such as Extract and Inline Local Variable, Change
Method Signature, and Encapsulate Field. Some refactorings, such as Rename,
offer great leverage because of the potential scale of the changes they perform
automatically. Others, like Extract Method, are more local in scope, but relieve
the developer from performing the analysis required to ensure that program
behavior is unaffected. In both cases, the developer benefits from reduction of a
complex and numerous changes to a single operation. This helps to maintain his
focus on the big picture. Moreover, the ability to roll back the changes with a
single gesture enables exploration of structural possibilities more easily, and
without fear of irreparable damage to the code base. Page 31

Software Refactoring
Department of Computer Science, CUSAT
31
Eclipse - Java refactoring Page 32

Software Refactoring
Department of Computer Science, CUSAT
32
Preview of Self Encapsulate Field
In the dialog, enter names for the getter and setter methods -- getName() and
setName(). There is provision to choose whether methods that are in the same
class as the field will continue to access the field directly or whether these
references will be changed to use the access methods like all other classes. Page 33

Software Refactoring
Department of Computer Science, CUSAT
33
After Self Encapsulation of field name in the class Node it is made private and
access is given through the getter function. The setter and getter functions will
appear after the specified method in the refactored code. Page 34

Software Refactoring
Department of Computer Science, CUSAT
34
CONCLUSION
Software Refactoring is an important area of research that promises substantial
benefits to software maintenance. Refactoring is a process that improves the
quality and allows developers to repair code that is becoming hard to maintain,
without throwing away the existing source code and starting again. We can return
with a well structured and well designed code after proper application of
refactoring techniques. Refactoring naturally fits in an agile software
development process. It forms even one of the cornerstones of the eXtreme
Programming process; together with unit testing. The research in software
engineering continues to be very active.Page 35

Software Refactoring
Department of Computer Science, CUSAT
35
REFERENCES
Java Refactorings in Eclipse
http://eclipse.org
Martin Fowler, žRefactoring Home Page
http://refactoring.com
FOWLER, MARTIN: A list of refactoring tools for several languages,
http://refactoringtools.html
Discussion site on code smells
http://c2cgi/wiki?CodeSmell