[ifi-stolz-refaktor.git] / thesis / master-thesis-erlenkr.tex

\documentclass[USenglish]{ifimaster}
\usepackage{import}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc,url}
\usepackage{lmodern} % using Latin Modern to be able to use bold typewriter font
\urlstyle{sf}
\usepackage{babel,textcomp,csquotes,ifimasterforside,varioref,graphicx}
\usepackage[hidelinks]{hyperref}
\usepackage[style=numeric-comp,backend=bibtex]{biblatex}
\usepackage{amsthm}
\usepackage{todonotes}
\usepackage{xspace}
\usepackage{he-she}
\usepackage{verbatim}
\usepackage{minted}
\usemintedstyle{bw}
\usepackage{perpage} %the perpage package
\MakePerPage{footnote} %the perpage package command

\theoremstyle{definition}
\newtheorem*{wordDef}{Definition}

\graphicspath{ {./figures/} }

\newcommand{\definition}[1]{\begin{wordDef}#1\end{wordDef}}
\newcommand{\see}[1]{(see section \ref{#1})}
\newcommand{\See}[1]{(See section \ref{#1}.)}
\newcommand{\explanation}[3]{\noindent\textbf{\textit{#1}}\\*\emph{When:} 
#2\\*\emph{How:} #3\\*[-7px]}

\newcommand{\type}[1]{\texttt{\textbf{#1}}}
\newcommand{\typeref}[1]{\footnote{\type{#1}}}
\newcommand{\typewithref}[2]{\type{#2}\typeref{#1.#2}}
\newcommand{\method}[1]{\type{#1}}
\newcommand{\methodref}[2]{\footnote{\type{#1}\method{\##2()}}}
\newcommand{\methodwithref}[2]{\method{#2}\footnote{\type{#1}\method{\##2()}}}
\newcommand{\var}[1]{\type{#1}}

\newcommand{\refactoring}[1]{\emph{#1}}
\newcommand{\ExtractMethod}{\refactoring{Extract Method}\xspace}
\newcommand{\MoveMethod}{\refactoring{Move Method}\xspace}

\newcommand{\citing}[1]{~\cite{#1}}

\newcommand\todoin[2][]{\todo[inline, caption={2do}, #1]{
\begin{minipage}{\textwidth-4pt}#2\end{minipage}}}

\title{Refactoring}
\subtitle{An unfinished essay}
\author{Erlend Kristiansen}

\bibliography{bibliography/master-thesis-erlenkr-bibliography}

\begin{document}
\ififorside
\frontmatter{}


\chapter*{Abstract}
\todoin{\textbf{Remove all todos (including list) before delivery/printing!!!}}
\todoin{Write abstract}

\tableofcontents{}
\listoffigures{}
\listoftables{}

\chapter*{Preface}

The discussions in this report must be seen in the context of object oriented 
programming languages, and Java in particular, since that is the language in 
which most of the examples will be given. All though the techniques discussed 
may be applicable to languages from other paradigms, they will not be the 
subject of this report.

\mainmatter

\chapter{What is Refactoring?}

This question is best answered by first defining the concept of a 
\emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects 
of programming that make people want to refactor their code.

\section{Defining refactoring}
Martin Fowler, in his masterpiece on refactoring \cite{refactoring}, defines a 
refactoring like this:

\begin{quote}
  \emph{Refactoring} (noun): a change made to the \todo{what does he mean by 
  internal?} internal structure of software to make it easier to understand and 
  cheaper to modify without changing its observable 
  behavior.~\cite[p.~53]{refactoring}
\end{quote}

\noindent This definition assign additional meaning to the word 
\emph{refactoring}, beyond the composition of the prefix \emph{re-}, usually 
meaning something like ``again'' or ``anew'', and the word \emph{factoring}, 
that can mean to isolate the \emph{factors} of something. Here a \emph{factor} 
would be close to the mathematical definition of something that divides a 
quantity, without leaving a remainder. Fowler is mixing the \emph{motivation} 
behind refactoring into his definition.  Instead it could be made clean, only 
considering the mechanical and behavioral aspects of refactoring. That is to 
factor the program again, putting it together in a different way than before, 
while preserving the behavior of the program. An alternative definition could 
then be: 

\definition{A \emph{refactoring} is a transformation
done to a program without altering its external behavior.}

From this we can conclude that a refactoring primarily changes how the 
\emph{code} of a program is perceived by the \emph{programmer}, and not the 
\emph{behavior} experienced by any user of the program. Although the logical 
meaning is preserved, such changes could potentially alter the program's 
behavior when it comes to performance gain or -penalties. So any logic depending 
on the performance of a program could make the program behave differently after 
a refactoring.

In the extreme case one could argue that such a thing as \emph{software 
obfuscation} is to refactor. If we where to define it as a refactoring, it could 
be defined as a composite refactoring \see{compositeRefactorings}, consisting 
of, for instance, a series of rename refactorings. (But it could of course be 
much more complex, and the mechanics of it would not exactly be carved in 
stone.) To perform some serious obfuscation one would also take advantage of 
techniques not found among established refactorings, such as removing 
whitespace. This might not even generate a different syntax tree for languages 
not sensitive to whitespace, placing it in the gray area of what kind of 
transformations is to be considered refactorings.

Finally, to \emph{refactor} is (quoting Martin Fowler)
\begin{quote}
  \ldots to restructure software by applying a series of refactorings without 
  changing its observable behavior.~\cite[p.~54]{refactoring}
\end{quote}

\section{The etymology of 'refactoring'}
It is a little difficult to pinpoint the exact origin of the word 
``refactoring'', as it seems to have evolved as part of a colloquial 
terminology, more than a scientific term. There is no authoritative source for a 
formal definition of it. 

According to Martin Fowler\citing{etymology-refactoring}, there may also be more 
than one origin of the word. The most well-known source, when it comes to the 
origin of \emph{refactoring}, is the Smalltalk\footnote{\emph{Smalltalk}, 
object-oriented, dynamically typed, reflective programming language.}\todo{find 
reference to Smalltalk website or similar?} community and their infamous 
\emph{Refactoring 
Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}} 
described in the article \emph{A Refactoring Tool for 
Smalltalk}\citing{refactoringBrowser1997}, published in 1997.  
Allegedly\citing{etymology-refactoring}, the metaphor of factoring programs was 
also present in the Forth\footnote{\emph{Forth} -- stack-based, extensible 
programming language, without type-checking. See \url{http://www.forth.org}} 
community, and the word ``refactoring'' is mentioned in a book by Leo Brodie, 
called \emph{Thinking Forth}\citing{brodie1984}, first published in 
1984\footnote{\emph{Thinking Forth} was first published in 1984 by the 
\emph{Forth Interest Group}.  Then it was reprinted in 1994 with minor 
typographical corrections, before it was transcribed into an electronic edition 
typeset in \LaTeX\ and published under a Creative Commons licence in 2004. The 
edition cited here is the 2004 edition, but the content should essentially be as 
in 1984.}. The exact word is only printed one place\footnote{p. 232}, but the 
term \emph{factoring} is prominent in the book, that also contains a whole 
chapter dedicated to (re)factoring, and how to keep the (Forth) code clean and 
maintainable.

\begin{quote}
  \ldots good factoring technique is perhaps the most important skill for a 
  Forth programmer.~\cite[p.~172]{brodie1984}
\end{quote}

\noindent Brodie also express what \emph{factoring} means to him:

\begin{quote}
  Factoring means organizing code into useful fragments. To make a fragment 
  useful, you often must separate reusable parts from non-reusable parts. The  
  reusable parts become new definitions. The non-reusable parts become arguments 
  or parameters to the definitions.~\cite[p.~172]{brodie1984}
\end{quote}

Fowler claims that the usage of the word \emph{refactoring} did not pass between 
the \emph{Forth} and \emph{Smalltalk} communities, but that it emerged 
independently in each of the communities.

\todoin{more history?}

\section{Motivation -- Why people refactor}
To get a grasp of what refactoring is all about, we can try to answer this 
question: \emph{Why do people refactor?} Possible answers could include: ``To 
remove duplication'' or ``to break up long methods''.  Practitioners of the art 
of Design Patterns\citing{designPatterns} could say that they do it to introduce 
a long-needed pattern into their program's design.  So it is safe to say that 
peoples' intentions are to make their programs \emph{better} in some sense. But 
what aspects of the programs are becoming improved?

As already mentioned, people often refactor to get rid of duplication. Moving 
identical or similar code into methods, and maybe pushing those up or down in 
their class hierarchies. Making template methods for overlapping 
algorithms/functionality and so on.  It's all about gathering what belongs 
together and putting it all in one place.  And the result? The code is easier to 
maintain. When removing the implicit coupling between the code snippets, the 
location of a bug is limited to only one place, and new functionality need only 
to be added this one place, instead of a number of places people might not even 
remember.

The same people find out that their program contains a lot of long and 
hard-to-grasp methods. Then what do they do? They begin dividing their methods 
into smaller ones, using the \ExtractMethod 
refactoring\citing{refactoring}.  Then they may discover something about their 
program that they weren't aware of before; revealing bugs they didn't know about 
or couldn't find due to the complex structure of their program. \todo{Proof?} 
Making the methods smaller and giving good names to the new ones clarifies the 
algorithms and enhances the \emph{understandability} of the program 
\see{magic_number_seven}. This makes simple refactoring an excellent method for 
exploring unknown program code, or code that you had forgotten that you wrote!

The word \emph{simple} came up in the last section. In fact, most primitive 
refactorings are simple. The true power of them are revealed first when they are 
combined into larger --- higher level --- refactorings, called \emph{composite 
refactorings} \see{compositeRefactorings}. Often the goal of such a series of 
refactorings is a design pattern. Thus the \emph{design} can be evolved 
throughout the lifetime of a program, opposed to designing up-front.  It's all 
about being structured and taking small steps to improve a program's design.

Many refactorings are aimed at lowering the coupling between different classes 
and different layers of logic. \todo{which refactorings?} Say for instance that 
the coupling between the user interface and the business logic of a program is 
lowered.  Then the business logic of the program could much easier be the target 
of automated tests, increasing the productivity in the software development 
process. It is also easier to distribute (e.g. between computers) the different 
components of a program if they are sufficiently decoupled.

Another effect of refactoring is that with the increased separation of concerns 
coming out of many refactorings, the \emph{performance} is improved.  When 
profiling programs, the problem parts are narrowed down to smaller parts of the 
code, which are easier to tune, and optimization can be performed only where 
needed and in a more effective way.

Last, but not least, and this should probably be the best reason to refactor, is 
to refactor to \emph{facilitate a program change}. If one has managed to keep 
one's code clean and tidy, and the code is not bloated with design patterns that 
is not ever going to be needed, then some refactoring might be needed to 
introduce a design pattern that is appropriate for the change that is going to 
happen.

Refactoring program code --- with a goal in mind --- can give the code itself 
more value. That is in the form of robustness to bugs, understandability and 
maintainability. With the first as an obvious advantage, but with the following 
two being also very important for software development. By incorporating 
refactoring in the development process, bugs are found faster, new functionality 
is added more easily and code is easier to understand by the next person exposed 
to it, which might as well be the person who wrote it. The consequence of this, 
is that refactoring can increase the average productivity of the development 
process, and thus also add to the monetary value of a business in the long run.  
Where this last point also should open the eyes of some nearsighted managers who 
seldom see beyond the next milestone.

\section{The magical number seven}\label{magic_number_seven}
\emph{The magical number seven, plus or minus two: some limits on our capacity 
for processing information}\citing{miller1956} is an article by George A. Miller 
that was published in the journal \emph{Psychological Review} in 1956. It 
presents evidence that support that the capacity of the number of objects a 
human being can hold in its working memory is roughly seven, plus or minus two 
objects. This number varies a bit depending on the nature and complexity of the 
objects, but is according to Miller ``\ldots never changing so much as to be 
unrecognizable.''

Miller's article culminates in the section called \emph{Recoding}, a term he 
borrows from communication theory. The central result in this section is that by 
recoding information, the capacity of the amount of information that a human can 
process at a time is increased. By \emph{recoding}, Miller means to group 
objects together in chunks and give each chunk a new name that it can be 
remembered by. By organizing objects into patterns of ever growing depth, one 
can memorize and process a much larger amount of data than if it were to be 
represented as its basic pieces. This grouping and renaming is analogous to how 
many refactorings work, by grouping pieces of code and give them a new name.  
Examples are the central \ExtractMethod and \refactoring{Extract Class} 
refactorings\citing{refactoring}.

\begin{quote}
  \ldots recoding is an extremely powerful weapon for increasing the amount of 
  information that we can deal with.~\cite[p.~95]{miller1956}
\end{quote}

An example from the article address the problem of memorizing a sequence of 
binary digits. Let us say we have the following sequence\footnote{The example 
  presented here is slightly modified (and shortened) from what is presented in 
  the original article\citing{miller1956}, but it is essentially the same.} of 
16 binary digits: ``1010001001110011''. Most of us will have a hard time 
memorizing this sequence by only reading it once or twice. Imagine if we instead 
translate it to this sequence: ``A273''. If you have a background from computer 
science, it will be obvious that the latest sequence is the first sequence 
recoded to be represented by digits with base 16. Most people should be able to 
memorize this last sequence by only looking at it once.

Another result from the Miller article is that when the amount of information a 
human must interpret increases, it is crucial that the translation from one code 
to another must be almost automatic for the subject to be able to remember the 
translation, before \heshe is presented with new information to recode.  Thus 
learning and understanding how to best organize certain kinds of data is 
essential to efficiently handle that kind of data in the future. This is much 
like when children learn to read. First they must learn how to recognize 
letters. Then they can learn distinct words, and later read sequences of words 
that form whole sentences. Eventually, most of them will be able to read whole 
books and briefly retell the important parts of its content. This suggest that 
the use of design patterns\citing{designPatterns} is a good idea when reasoning 
about computer programs. With extensive use of design patterns when creating 
complex program structures, one does not always have to read whole classes of 
code to comprehend how they function, it may be sufficient to only see the name 
of a class to almost fully understand its responsibilities.

\begin{quote}
  Our language is tremendously useful for repackaging material into a few chunks 
  rich in information.~\cite[p.~95]{miller1956}
\end{quote}

Without further evidence, these results at least indicates that refactoring 
source code into smaller units with higher cohesion and, when needed, 
introducing appropriate design patterns, should aid in the cause of creating 
computer programs that are easier to maintain and has code that is easier (and 
better) understood.

\section{Notable contributions to the refactoring literature}
\todoin{Update with more contributions}

\begin{description}
  \item[1992] William F. Opdyke submits his doctoral dissertation called 
    \emph{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This 
    work defines a set of refactorings, that are behavior preserving given that 
    their preconditions are met. The dissertation is focused on the automation 
    of refactorings.
  \item[1999] Martin Fowler et al.: \emph{Refactoring: Improving the Design of 
    Existing Code}\citing{refactoring}. This is maybe the most influential text 
    on refactoring. It bares similarities with Opdykes thesis\citing{opdyke1992} 
    in the way that it provides a catalog of refactorings. But Fowler's book is 
    more about the craft of refactoring, as he focuses on establishing a 
    vocabulary for refactoring, together with the mechanics of different 
    refactorings and when to perform them. His methodology is also founded on 
  the principles of test-driven development.
  \item[2005] Joshua Kerievsky: \emph{Refactoring to 
    Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's 
    \emph{Refactoring}\citing{refactoring} and the Gang of Four \emph{Design 
    Patterns}\citing{designPatterns}. It is building on the refactoring 
    catalogue from Fowler's book, but is trying to bridge the gap between 
    \emph{refactoring} and \emph{design patterns} by providing a series of 
    higher-level composite refactorings, that makes code evolve toward or away 
    from certain design patterns. The book is trying to build up the readers 
    intuition around \emph{why} one would want to use a particular design 
    pattern, and not just \emph{how}. The book is encouraging evolutionary 
    design.  \See{relationToDesignPatterns}
\end{description}

\section{Tool support}\label{toolSupport}

\subsection{Tool support for Java}
This section will briefly compare the refatoring support of the three IDEs 
\emph{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \emph{IntelliJ 
IDEA}\footnote{The IDE under comparison is the \emph{Community Edition}, 
\url{http://www.jetbrains.com/idea/}} and 
\emph{NetBeans}\footnote{\url{https://netbeans.org/}}. These are the most 
popular Java IDEs\citing{javaReport2011}.

All three IDEs provide support for the most useful refactorings, like the 
different extract, move and rename refactorings. In fact, Java-targeted IDEs are 
known for their good refactoring support, so this did not appear as a big 
surprise.

The IDEs seem to have excellent support for the \ExtractMethod refactoring, so 
at least they have all passed the first refactoring 
rubicon\citing{fowlerRubicon2001,secondRubicon2012}.

Regarding the \MoveMethod refactoring, the \emph{Eclipse} and \emph{IntelliJ} 
IDEs do the job in very similar manners. In most situations they both do a 
satisfying job by producing the expected outcome. But they do nothing to check 
that the result does not break the semantics of the program. \See{correctness} 
The \emph{NetBeans} IDE implements this refactoring in a somewhat clumsy way.  
For starters, its default destination for the move is itself, although it 
refuses to perform the refactoring if chosen. But the worst part is, that if 
moving the method \method{f} of the below code to \type{X}, it will break the 
code. Given

\begin{minted}[samepage]{java}
public class C {
    private X x;
    ...
    public void f() {
        x.m();
        x.n();
    }
}
\end{minted}

\noindent the move refactoring will produce the following in class \type{X}:

\begin{minted}[samepage]{java}
public class X {
    ...
    public void f(C c) {
        c.x.m();
        c.x.n();
    }
}
\end{minted}

NetBeans will try to make code that call the methods \method{m} and \method{n} 
of \type{X} by accessing them through \var{c.x}, where \var{c} is a parameter of 
type \type{C} that is added the method \method{f} when it is moved.  If 
\var{c.x} for some reason is inaccessible to \type{X}, as in this case, the 
refactoring breaks the code, and it will not compile. It has a preview of the 
refactoring outcome, but that does not catch that it is about to do something 
stupid. Ironically, this ``feature'' of NetBeans keeps it from breaking the code 
in the example from section \ref{correctness}.

The IDEs under investigation seems to have fairly good support for primitive 
refactorings, but what about more complex ones, such as the \refactoring{Extract 
Class}\citing{refactoring}? The \refactoring{Extract Class} refactoring works by 
creating a class, for then to move members to that class and access them from 
the old class via a reference to the new class. \emph{IntelliJ} seems to handle 
this in a fairly good manner, although, in the case of private methods, it 
leaves unused methods behind. These are methods that delegate to a field of the 
new class, but are not used anywhere. \emph{Eclipse} has added (or withdrawn) 
its own fun twist to the refactoring, and only allows for \emph{fields} to be 
moved to a new class. This makes it effectively only extracting a data 
structure, and calling it \refactoring{Extract Class} is a little misleading.  
One would often be better off with textual extract and paste than using the 
Extract Class refactoring in Eclipse. When it comes to \emph{NetBeans}, it does 
not even seem to have made an attempt on providing this refactoring. (Well, 
probably has, but it does not show in the IDE.) 

\todoin{Visual Studio (C++/C\#), Smalltalk refactoring browser?,
second refactoring rubicon?}

\section{The relation to design patterns}\label{relationToDesignPatterns}

\emph{Refactoring} and \emph{design patterns} have at least one thing in common, 
they are both promoted by advocates of \emph{clean code}\citing{cleanCode} as 
fundamental tools on the road to more maintanable and extendable source code.

\begin{quote}
  Design patterns help you determine how to reorganize a design, and they can 
  reduce the amount of refactoring you need to do 
  later.~\cite[p.~353]{designPatterns}
\end{quote}

Although frequently associated with over-engineering, design patterns are in 
general assumed to be good for maintainability of source code. That may be 
because many of them are designed to support the \emph{open/closed principle} of 
object-oriented programming. The principle was first formulated by Bertrand 
Meyer, the creator of the Eiffel programming language, like this: ``Modules 
should be both open and closed.''\citing{meyer1988} It has been popularized, 
with this as a common version: 

\begin{quote}
  Software entities (classes, modules, functions, etc.) should be open for 
  extension, but closed for modification.\footnote{See 
    \url{http://c2.com/cgi/wiki?OpenClosedPrinciple} or  
    \url{https://en.wikipedia.org/wiki/Open/closed_principle}}
\end{quote} 

Maintainability is often thought of as the ability to be able to introduce new 
functionality without having to change to much of the old code. When 
refactoring, the motivation is often to facilitate adding new functionality. It 
is about factoring the old code in a way that makes the new functionality being 
able to benefit from the functionality already residing in a software system, 
without having to copy old code into new. Then, next time someone shall add new 
functionality, it is less likely that the old code have to change. Assuming that 
a design pattern is the best way to get rid of some case of duplication and 
assist in implementing new functionality, it is reasonable to conclude that a 
design pattern often is the target of a series of refactorings. Having a 
repertoire of design patterns can also help in knowing when and how to refactor 
a program to make it reflect certain desired characteristics.

\begin{quote}
  There is a natural relation between patterns ans refactorings. Patterns are 
  where you want to be; refactorings are ways to get there from somewhere 
  else.~\cite[p.~107]{refactoring}
\end{quote}

This quote is wise in many contexts, but it is not always appropriate to say 
``Patterns are where you want to be\ldots''. \emph{Sometimes}, patterns is where 
you want to be, but only because it will benefit your design. It is not true 
that one should always try to incorporate as many design patterns as possible 
into a program. It is not like they have intrinsic value. They only add value to 
a system when they support its design. Otherwise, the use of design patterns may 
only lead to a program that is more complex than necessary.

\begin{quote}
  The overuse of patterns tends to result from being patterns happy. We are 
  \emph{patterns happy} when we become so enamored of patterns that we simply 
  must use them in our code.~\cite[p.~24]{kerievsky2005}
\end{quote}

This can easily happen when relying largely on up-front design. Then it is 
natural, in the very beginning, to try to build in all the flexibility that one 
believes will be necessary throughout the lifetime of a software system.  
According to Joshua Kerievsky ``That sounds reasonable --- if you happen to be 
psychic.''~\cite[p.~1]{kerievsky2005} He is advocating what he believes is a 
better approach: To let software continually evolve. To start with a simple 
design that meets today's needs, and tackle future needs by refactoring to 
satisfy them. He believes that this is a more economic approach than investing 
time and money into a design that inevitably is going to change. By relying on 
continuously refactoring a system, its design can be made simpler without 
sacrificing flexibility. To be able to fully rely on this approach, it is of 
utter importance to have a reliable suit of tests to lean on. \See{testing} This 
makes the design process more natural and less characterized by difficult 
decisions that has to be made before proceeding in the process, and that is 
going to define a project for all of its unforeseeable future.

\begin{comment}

\section{Classification of refactorings} 
% only interesting refactorings
% with 2 detailed examples? One for structured and one for intra-method?
% Is replacing Bubblesort with Quick Sort considered a refactoring?

\subsection{Structural refactorings}

\subsubsection{Primitive refactorings}

% Composing Methods
\explanation{Extract Method}{You have a code fragment that can be grouped 
together.}{Turn the fragment into a method whose name explains the purpose of 
the method.}

\explanation{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.}

\explanation{Inline Temp}{You have a temp that is assigned to once with a simple 
expression, and the temp is getting in the way of other refactorings.}{Replace 
all references to that temp with the expression}

% Moving Features Between Objects
\explanation{Move Method}{A method is, or will be, using or used by more 
features of another class than the class on which it is defined.}{Create a new 
method with a similar body in the class it uses most. Either turn the old method 
into a simple delegation, or remove it altogether.}

\explanation{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.}

% Organizing Data
\explanation{Replace Magic Number with Symbolic Constant}{You have a literal 
number with a particular meaning.}{Create a constant, name it after the meaning, 
and replace the number with it.}

\explanation{Encapsulate Field}{There is a public field.}{Make it private and 
provide accessors.}

\explanation{Replace Type Code with Class}{A class has a numeric type code that 
does not affect its behavior.}{Replace the number with a new class.}

\explanation{Replace Type Code with Subclasses}{You have an immutable type code 
that affects the behavior of a class.}{Replace the type code with subclasses.}

\explanation{Replace Type Code with State/Strategy}{You have a type code that 
affects the behavior of a class, but you cannot use subclassing.}{Replace the 
type code with a state object.}

% Simplifying Conditional Expressions
\explanation{Consolidate Duplicate Conditional Fragments}{The same fragment of 
code is in all branches of a conditional expression.}{Move it outside of the 
expression.}

\explanation{Remove Control Flag}{You have a variable that is acting as a 
control flag fro a series of boolean expressions.}{Use a break or return 
instead.}

\explanation{Replace Nested Conditional with Guard Clauses}{A method has 
conditional behavior that does not make clear the normal path of 
execution.}{Use guard clauses for all special cases.}

\explanation{Introduce Null Object}{You have repeated checks for a null 
value.}{Replace the null value with a null object.}

\explanation{Introduce Assertion}{A section of code assumes something about the 
state of the program.}{Make the assumption explicit with an assertion.}

% Making Method Calls Simpler
\explanation{Rename Method}{The name of a method does not reveal its 
purpose.}{Change the name of the method}

\explanation{Add Parameter}{A method needs more information from its 
caller.}{Add a parameter for an object that can pass on this information.}

\explanation{Remove Parameter}{A parameter is no longer used by the method 
body.}{Remove it.}

%\explanation{Parameterize Method}{Several methods do similar things but with 
%different values contained in the method.}{Create one method that uses a 
%parameter for the different values.}

\explanation{Preserve Whole Object}{You are getting several values from an 
object and passing these values as parameters in a method call.}{Send the whole 
object instead.}

\explanation{Remove Setting Method}{A field should be set at creation time and 
never altered.}{Remove any setting method for that field.}

\explanation{Hide Method}{A method is not used by any other class.}{Make the 
method private.}

\explanation{Replace Constructor with Factory Method}{You want to do more than 
simple construction when you create an object}{Replace the constructor with a 
factory method.}

% Dealing with Generalization
\explanation{Pull Up Field}{Two subclasses have the same field.}{Move the field 
to the superclass.}

\explanation{Pull Up Method}{You have methods with identical results on 
subclasses.}{Move them to the superclass.}

\explanation{Push Down Method}{Behavior on a superclass is relevant only for 
some of its subclasses.}{Move it to those subclasses.}

\explanation{Push Down Field}{A field is used only by some subclasses.}{Move the 
field to those subclasses}

\explanation{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.}

\explanation{Replace Inheritance with Delegation}{A subclass uses only part of a 
superclasses interface or does not want to inherit data.}{Create a field for the 
superclass, adjust methods to delegate to the superclass, and remove the 
subclassing.}

\explanation{Replace Delegation with Inheritance}{You're using delegation and 
are often writing many simple delegations for the entire interface}{Make the 
delegating class a subclass of the delegate.}

\subsubsection{Composite refactorings}

% Composing Methods
% \explanation{Replace Method with Method Object}{}{}

% Moving Features Between Objects
\explanation{Extract Class}{You have 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.}

\explanation{Inline Class}{A class isn't doing very much.}{Move all its features 
into another class and delete it.}

\explanation{Hide Delegate}{A client is calling a delegate class of an 
object.}{Create Methods on the server to hide the delegate.}

\explanation{Remove Middle Man}{A class is doing to much simple delegation.}{Get 
the client to call the delegate directly.}

% Organizing Data
\explanation{Replace Data Value with Object}{You have a data item that needs 
additional data or behavior.}{Turn the data item into an object.}

\explanation{Change Value to Reference}{You have a class with many equal 
instances that you want to replace with a single object.}{Turn the object into a 
reference object.}

\explanation{Encapsulate Collection}{A method returns a collection}{Make it 
return a read-only view and provide add/remove methods.}

% \explanation{Replace Array with Object}{}{}

\explanation{Replace Subclass with Fields}{You have subclasses that vary only in 
methods that return constant data.}{Change the methods to superclass fields and 
eliminate the subclasses.}

% Simplifying Conditional Expressions
\explanation{Decompose Conditional}{You have a complicated conditional 
(if-then-else) statement.}{Extract methods from the condition, then part, an 
else part.}

\explanation{Consolidate Conditional Expression}{You have a sequence of 
conditional tests with the same result.}{Combine them into a single conditional 
expression and extract it.}

\explanation{Replace Conditional with Polymorphism}{You have a conditional that 
chooses different behavior depending on the type of an object.}{Move each leg 
of the conditional to an overriding method in a subclass. Make the original 
method abstract.}

% Making Method Calls Simpler
\explanation{Replace Parameter with Method}{An object invokes a method, then 
passes the result as a parameter for a method. The receiver can also invoke this 
method.}{Remove the parameter and let the receiver invoke the method.}

\explanation{Introduce Parameter Object}{You have a group of parameters that 
naturally go together.}{Replace them with an object.}

% Dealing with Generalization
\explanation{Extract Subclass}{A class has features that are used only in some 
instances.}{Create a subclass for that subset of features.}

\explanation{Extract Superclass}{You have two classes with similar 
features.}{Create a superclass and move the common features to the 
superclass.}

\explanation{Collapse Hierarchy}{A superclass and subclass are not very 
different.}{Merge them together.}

\explanation{Form Template Method}{You have two methods in subclasses that 
perform similar steps in the same order, yet the steps are different.}{Get the 
steps into methods with the same signature, so that the original methods become 
the same. Then you can pull them up.}


\subsection{Functional refactorings}

\explanation{Substitute Algorithm}{You want to replace an algorithm with one 
that is clearer.}{Replace the body of the method with the new algorithm.}

\end{comment}

\section{The impact on software quality}

\subsection{What is meant by quality?}
The term \emph{software quality} has many meanings. It all depends on the 
context we put it in. If we look at it with the eyes of a software developer, it 
usually mean that the software is easily maintainable and testable, or in other 
words, that it is \emph{well designed}. This often correlates with the 
management scale, where \emph{keeping the schedule} and \emph{customer 
satisfaction} is at the center. From the customers point of view, in addition to 
good usability, \emph{performance} and \emph{lack of bugs} is always 
appreciated, measurements that are also shared by the software developer. (In 
addition, such things as good documentation could be measured, but this is out 
of the scope of this document.)

\subsection{The impact on performance}
\begin{quote}
  Refactoring certainly will make software go more slowly, but it also makes the 
  software more amenable to performance tuning.~\cite[p.~69]{refactoring}
\end{quote}

\noindent There is a common belief that refactoring compromises performance, due 
to increased degree of indirection and that polymorphism is slower than 
conditionals.

In a survey, Demeyer\citing{demeyer2002} disproves this view in the case of 
polymorphism. He is doing an experiment on, what he calls, ``Transform Self Type 
Checks'' where you introduce a new polymorphic method and a new class hierarchy 
to get rid of a class' type checking of a ``type attribute``. He uses this kind 
of transformation to represent other ways of replacing conditionals with 
polymorphism as well. The experiment is performed on the C++ programming 
language and with three different compilers and platforms. \todo{But is the 
result better?} Demeyer concludes that, with compiler optimization turned on, 
polymorphism beats middle to large sized if-statements and does as well as 
case-statements.  (In accordance with his hypothesis, due to similarities 
between the way C++ handles polymorphism and case-statements.)

\begin{quote}
  The interesting thing about performance is that if you analyze most programs, 
  you find that they waste most of their time in a small fraction of the 
  code.~\cite[p.~70]{refactoring}
\end{quote}

\noindent So, although an increased amount of method calls could potentially 
slow down programs, one should avoid premature optimization and sacrificing good 
design, leaving the performance tuning until after profiling\footnote{For and 
  example of a Java profiler, check out VisualVM: 
  \url{http://visualvm.java.net/}} the software and having isolated the actual 
  problem areas.

\section{Composite refactorings}\label{compositeRefactorings}
\todo{motivation, examples, manual vs automated?, what about refactoring in a 
very large code base?}
Generally, when thinking about refactoring, at the mechanical level, there are 
essentially two kinds of refactorings. There are the \emph{primitive} 
refactorings, and the \emph{composite} refactorings. A primitive refactoring can 
be defined like this:

\definition{A \emph{primitive refactoring} is a refactoring that cannot be 
expressed in terms of other refactorings.}

\noindent Examples are the \refactoring{Pull Up Field} and \refactoring{Pull Up 
Method} refactorings\citing{refactoring}, that moves members up in their class 
hierarchies.

A composite refactoring is more complex, and can be defined like this:

\definition{A \emph{composite refactoring} is a refactoring that can be 
expressed in terms of two or more other refactorings.}

\noindent An example of a composite refactoring is the \refactoring{Extract 
Superclass} refactoring\citing{refactoring}. In its simplest form, it is composed 
of the previously described primitive refactorings, in addition to the 
\refactoring{Pull Up Constructor Body} refactoring\citing{refactoring}.  It works 
by creating an abstract superclass that the target class(es) inherits from, then 
by applying \refactoring{Pull Up Field}, \refactoring{Pull Up Method} and 
\refactoring{Pull Up Constructor Body} on the members that are to be members of 
the new superclass. For an overview of the \refactoring{Extract Superclass} 
refactoring, see figure \ref{fig:extractSuperclass}.

\begin{figure}[h]
  \centering
  \includegraphics[angle=270,width=\linewidth]{extractSuperclassItalic.pdf}
  \caption{The Extract Superclass refactoring}
  \label{fig:extractSuperclass}
\end{figure}

\section{Manual vs. automated refactorings}
Refactoring is something every programmer does, even if \heshe does not known 
the term \emph{refactoring}. Every refinement of source code that does not alter 
the program's behavior is a refactoring. For small refactorings, such as 
\ExtractMethod, executing it manually is a manageable task, but is still prone 
to errors. Getting it right the first time is not easy, considering the 
signature and all the other aspects of the refactoring that has to be in place.  

Take for instance the renaming of classes, methods and fields. For complex 
programs these refactorings are almost impossible to get right.  Attacking them 
with textual search and replace, or even regular expressions, will fall short on 
these tasks. Then it is crucial to have proper tool support that can perform 
them automatically. Tools that can parse source code and thus has semantic 
knowledge about which occurrences of which names that belongs to what construct 
in the program. For even trying to perform one of these complex task manually, 
one would have to be very confident on the existing test suite \see{testing}.

\section{Correctness of refactorings}\label{correctness}
For automated refactorings to be truly useful, they must show a high degree of 
behavior preservation. This last sentence might seem obvious, but there are 
examples of refactorings in existing tools that break programs. I will now 
present an example of an \ExtractMethod refactoring followed by a \MoveMethod 
refactoring that breaks a program in both the \emph{Eclipse} and \emph{IntelliJ} 
IDEs\footnote{The NetBeans IDE handles this particular situation, mainly because 
  its Move Method refactoring implementation is crippled in other ways
  \see{toolSupport}.}. The following piece of code shows the target for the 
  composed refactoring:

\begin{minted}[linenos,samepage]{java}
public class C {
    public X x = new X();

    public void f() {
        x.m(this);
        x.n();
    }
}
\end{minted}

\noindent The next piece of code shows the destination of the refactoring. Note 
that the method \method{m(C c)} of class \type{C} assigns to the field \var{x} 
of the argument \var{c} that has type \type{C}:

\begin{minted}[samepage]{java}
public class X {
    public void m(C c) {
        c.x = new X();
    }
    public void n() {}
}
\end{minted}

The refactoring sequence works by extracting line 5 and 6 from the original 
class \type{C} into a method \method{f} with the statements from those lines as 
its method body. The method is then moved to the class \type{X}. The result is 
shown in the following two pieces of code:

\begin{minted}[linenos,samepage]{java}
public class C {
    public X x = new X();

    public void f() {
        x.f(this);
    }
}
\end{minted}

\begin{minted}[linenos,samepage]{java}
public class X {
    public void m(C c) {
        c.x = new X();
    }
    public void n() {}
    public void f(C c) {
        m(c);
        n();
    }
}
\end{minted}

After the refactoring, the method \method{f} of class \type{C} calls the method 
\method{f} of class \type{X}, and the program breaks.  (See line 5 of the 
version of class \type{C} after the refactoring.) Before the refactoring, the 
methods \method{m} and \method{n} of class \type{X} are called on different 
object instances (see line 5 and 6 of the original class \type{C}). After, they 
are called on the same object, and the statement on line 3 of class \type{X} 
(the version after the refactoring) no longer have any effect in our example.

The bug introduced in the previous example is of such a nature that it is very 
difficult to spot if the refactored code is not covered by tests. It does not 
generate compilation errors, and will thus only result in a runtime error or 
corrupted data, which might be hard to detect.

\section{Refactoring and testing}\label{testing}
\begin{quote}
  If you want to refactor, the essential precondition is having solid 
  tests.\citing{refactoring}
\end{quote}

When refactoring, there are roughly two kinds of errors that can be made. There 
are errors that make the code unable to compile, and there are the silent 
errors, only popping up at runtime. Compile-time errors are the nice ones. They 
flash up at the moment they are made (at least when using an IDE), and are 
usually easy to fix. The other kind of error is the dangerous one. It is the 
kind of error introduced in the example of section \ref{correctness}. It is an 
error sneaking into your code without you noticing, maybe. For discovering those 
kind of errors when refactoring, it is essential to have good test coverage. It 
is not a way to \emph{prove} that the code is correct, but it is a way to make 
you confindent that it \emph{probably} works as desired. In the context of test 
driven development, the tests are even a way to define how the program is 
supposed to work. It is then, by definition, working if the tests are passing.  

If the test coverage for a code base is perfect, then it should, theoretically, 
be risk-free to perform refactorings on it. This is why tests and refactoring is 
such a great match.

\section{Software metrics}
\todoin{Is this the appropriate place to have this section?}

%\part{The project}
%\chapter{Planning the project}
%\part{Conclusion}
%\chapter{Results}                   



\chapter{\ldots}
\todoin{write}
\section{The problem statement}
\section{Choosing the target language}
Choosing which programming language to use as the target for manipulation is not 
a very difficult task. The language have to be an object-oriented programming 
language, and it must have existing tool support for refactoring. The 
\emph{Java} programming language\footnote{\url{https://www.java.com/}} is the 
dominating language when it comes to examples in the literature of refactoring, 
and is thus a natural choice. Java is perhaps, currently the most influential 
programming language in the world, with its \emph{Java Virtual Machine} that 
runs on all of the most popular architectures and also supports\footnote{They 
compile to java bytecode.} dozens of other programming languages, with 
\emph{Scala}, \emph{Clojure} and \emph{Groovy} as the most prominent ones. Java 
is currently the language that every other programming language is compared 
against. It is also the primary language of the author of this thesis.

\section{Choosing the tools}
When choosing a tool for manipulating Java, there are certain criterias that 
have to be met. First of all, the tool should have some existing refactoring 
support that this thesis can build upon. Secondly it should provide some kind of 
framework for parsing and analyzing Java source code. Third, it should itself be 
open source. This is both because of the need to be able to browse the code for 
the existing refactorings that is contained in the tool, and also because open 
source projects hold value in them selves. Another important aspect to consider 
is that open source projects of a certain size, usually has large communities of 
people connected to them, that are commited to answering questions regarding the 
use and misuse of the products, that to a large degree is made by the cummunity 
itself.

There is a certain class of tools that meet these criterias, namely the class of 
\emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are 
proagrams that is ment to support the whole production cycle of a cumputer 
program, and the most popular IDEs that support Java, generally have quite good 
refactoring support.

The main contenders for this thesis is the \emph{Eclipse IDE}, with the 
\emph{Java development tools} (JDT), the \emph{IntelliJ IDEA Community Edition} 
and the \emph{NetBeans IDE}. \See{toolSupport} Eclipse and NetBeans are both 
free, open source and community driven, while the IntelliJ IDEA has an open 
sourced community edition that is free of charge, but also offer an 
\emph{Ultimate Edition} with an extended set of features, at additional cost.  
All three IDEs supports adding plugins to extend their functionality and tools 
that can be used to parse and analyze Java source code. \todo{investigate if 
this is true} But one of the IDEs stand out as a favorite, and that is the 
\emph{Eclipse IDE}. This is the most popular\citing{javaReport2011} among them 
and seems to be de facto standard IDE for Java development regardless of 
platform.


\chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful 
Thinking}\label{ch:jdt_refactorings}

This chapter will deal with some of the design behind refactoring support in 
Eclipse, and the JDT in specific. After which it will follow a section about 
shortcomings of the refactoring API in terms of composition of refactorings. The 
chapter will be concluded with a section telling some of the ways the 
implementation of refactorings in the JDT could have worked to facilitate 
composition of refactorings.

\section{Design}
The refactoring world of Eclipse can in general be separated into two parts: The 
language independent part and the part written for a specific programming 
language -- the language that is the target of the supported refactorings.  
\todo{What about the language specific part?}

\subsection{The Language Toolkit}
The Language Toolkit, or LTK for short, is the framework that is used to 
implement refactorings in Eclipse. It is language independent and provides the 
abstractions of a refactoring and the change it generates, in the form of the 
classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} and 
\typewithref{org.eclipse.ltk.core.refactoring}{Change}. (There is also parts of 
the LTK that is concerned with user interaction, but they will not be discussed 
here, since they are of little value to us and our use of the framework.)

\subsubsection{The Refactoring Class}
The abstract class \type{Refactoring} is the core of the LTK framework. Every 
refactoring that is going to be supported by the LTK have to end up creating an 
instance of one of its subclasses. The main responsibilities of subclasses of 
\type{Refactoring} is to implement template methods for condition checking 
(\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkInitialConditions} 
and 
\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkFinalConditions}), 
in addition to the 
\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{createChange} 
method that creates and returns an instance of the \type{Change} class.

If the refactoring shall support that others participate in it when it is 
executed, the refactoring has to be a processor-based 
refactoring\typeref{org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring}.  
It then delegates to its given 
\typewithref{org.eclipse.ltk.core.refactoring.participants}{RefactoringProcessor} 
for condition checking and change creation.

\subsubsection{The Change Class}
This class is the base class for objects that is responsible for performing the 
actual workspace transformations in a refactoring. The main responsibilities for 
its subclasses is to implement the 
\methodwithref{org.eclipse.ltk.core.refactoring.Change}{perform} and 
\methodwithref{org.eclipse.ltk.core.refactoring.Change}{isValid} methods. The 
\method{isValid} method verifies that the change object is valid and thus can be 
executed by calling its \method{perform} method. The \method{perform} method 
performs the desired change and returns an undo change that can be executed to 
reverse the effect of the transformation done by its originating change object. 

\subsubsection{Executing a Refactoring}\label{executing_refactoring}
The life cycle of a refactoring generally follows two steps after creation: 
condition checking and change creation. By letting the refactoring object be 
handled by a 
\typewithref{org.eclipse.ltk.core.refactoring}{CheckConditionsOperation} that
in turn is handled by a 
\typewithref{org.eclipse.ltk.core.refactoring}{CreateChangeOperation}, it is 
assured that the change creation process is managed in a proper manner.

The actual execution of a change object has to follow a detailed life cycle.  
This life cycle is honored if the \type{CreateChangeOperation} is handled by a 
\typewithref{org.eclipse.ltk.core.refactoring}{PerformChangeOperation}. If also 
an undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} is set 
for the \type{PerformChangeOperation}, the undo change is added into the undo 
history.

\section{Shortcomings}
This section is introduced naturally with a conclusion: The JDT refactoring 
implementation does not facilitate composition of refactorings. 
\todo{refine}This section will try to explain why, and also identify other 
shortcomings of both the usability and the readability of the JDT refactoring 
source code.

I will begin at the end and work my way toward the composition part of this 
section.

\subsection{Absence of Generics in Eclipse Source Code}
This section is not only concerning the JDT refactoring API, but also large 
quantities of the Eclipse source code. The code shows a striking absence of the 
Java language feature of generics. It is hard to read a class' interface when 
methods return objects or takes parameters of raw types such as \type{List} or 
\type{Map}. This sometimes results in having to read a lot of source code to 
understand what is going on, instead of relying on the available interfaces. In 
addition, it results in a lot of ugly code, making the use of typecasting more 
of a rule than an exception.

\subsection{Composite Refactorings Will Not Appear as Atomic Actions}

\subsubsection{Missing Flexibility from JDT Refactorings}
The JDT refactorings are not made with composition of refactorings in mind. When 
a JDT refactoring is executed, it assumes that all conditions for it to be 
applied successfully can be found by reading source files that has been 
persisted to disk. They can only operate on the actual source material, and not 
(in-memory) copies thereof. This constitutes a major disadvantage when trying to 
compose refactorings, since if an exception occur in the middle of a sequence of 
refactorings, it can leave the project in a state where the composite 
refactoring was executed only partly. It makes it hard to discard the changes 
done without monitoring and consulting the undo manager, an approach that is not 
bullet proof.

\subsubsection{Broken Undo History}
When designing a composed refactoring that is to be performed as a sequence of 
refactorings, you would like it to appear as a single change to the workspace.  
This implies that you would also like to be able to undo all the changes done by 
the refactoring in a single step. This is not the way it appears when a sequence 
of JDT refactorings is executed. It leaves the undo history filled up with 
individual undo actions corresponding to every single JDT refactoring in the 
sequence. This problem is not trivial to handle in Eclipse. (See section 
\ref{hacking_undo_history}.)

\section{Wishful Thinking}



\chapter{Composite Refactorings in Eclipse}

\section{A Simple Ad Hoc Model}
As pointed out in chapter \ref{ch:jdt_refactorings}, the Eclipse JDT refactoring 
model is not very well suited for making composite refactorings. Therefore a 
simple model using changer objects (of type \type{RefaktorChanger}) is used as 
an abstraction layer on top of the existing Eclipse refactorings.

\section{The Extract and Move Method Refactoring}
%The Extract and Move Method Refactoring is implemented mainly using these 
%classes:
%\begin{itemize}
%  \item \type{ExtractAndMoveMethodChanger}
%  \item \type{ExtractAndMoveMethodPrefixesExtractor}
%  \item \type{Prefix}
%  \item \type{PrefixSet}
%\end{itemize}

\subsection{The Building Blocks}
This is a composite refactoring, and hence is built up using several primitive 
refactorings. These basic building blocks are, as its name implies, the 
\ExtractMethod refactoring\citing{refactoring} and the \MoveMethod 
refactoring\citing{refactoring}. In Eclipse, the implementations of these 
refactorings are found in the classes 
\typewithref{org.eclipse.jdt.internal.corext.refactoring.code}{ExtractMethodRefactoring} 
and 
\typewithref{org.eclipse.jdt.internal.corext.refactoring.structure}{MoveInstanceMethodProcessor}, 
where the last class is designed to be used together with the processor-based 
\typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveRefactoring}.

\subsubsection{The ExtractMethodRefactoring Class}
This class is quite simple in its use. The only parameters it requires for 
construction is a compilation 
unit\typeref{org.eclipse.jdt.core.ICompilationUnit}, the offset into the source 
code where the extraction shall start, and the length of the source to be 
extracted. Then you have to set the method name for the new method together with 
which access modifier that shall be used and some not so interesting parameters.

\subsubsection{The MoveInstanceMethodProcessor Class}
For the Move Method the processor requires a little more advanced input than  
the class for the Extract Method. For construction it requires a method 
handle\typeref{org.eclipse.jdt.core.IMethod} from the Java Model for the method 
that is to be moved. Then the target for the move have to be supplied as the 
variable binding from a chosen variable declaration. In addition to this, one 
have to set some parameters regarding setters/getters and delegation.

To make a whole refactoring from the processor, one have to construct a 
\type{MoveRefactoring} from it.

\subsection{The ExtractAndMoveMethodChanger Class}
The \typewithref{no.uio.ifi.refaktor.changers}{ExtractAndMoveMethodChanger} 
class, that is a subclass of the class 
\typewithref{no.uio.ifi.refaktor.changers}{RefaktorChanger}, is the class 
responsible for composing the \type{ExtractMethodRefactoring} and the 
\type{MoveRefactoring}. Its constructor takes a project 
handle\typeref{org.eclipse.core.resources.IProject}, the method name for the new 
method and a \typewithref{no.uio.ifi.refaktor.utils}{SmartTextSelection}.

A \type{SmartTextSelection} is basically a text 
selection\typeref{org.eclipse.jface.text.ITextSelection} object that enforces 
the providing of the underlying document during creation. I.e. its 
\methodwithref{no.uio.ifi.refaktor.utils.SmartTextSelection}{getDocument} method 
will never return \type{null}.

Before extracting the new method, the possible targets for the move operation is 
found with the help of an
\typewithref{no.uio.ifi.refaktor.extractors}{ExtractAndMoveMethodPrefixesExtractor}.  
The possible targets is computed from the prefixes that the extractor returns 
from its
\methodwithref{no.uio.ifi.refaktor.extractors.ExtractAndMoveMethodPrefixesExtractor}{getSafePrefixes} 
method. The changer then choose the most suitable target by finding the most 
frequent occurring prefix among the safe ones. The target is the type of the 
first part of the prefix.

After finding a suitable target, the \type{ExtractAndMoveMethodChanger} first 
creates an \type{ExtractMethodRefactoring} and performs it as explained in 
section \ref{executing_refactoring} about the execution of refactorings. Then it 
creates and performs the \type{MoveRefactoring} in the same way, based on the 
changes done by the Extract Method refactoring.

\subsection{The ExtractAndMoveMethodPrefixesExtractor Class}
This extractor extracts properties needed for building the Extract and Move 
Method refactoring. It searches through the given selection to find safe 
prefixes, and those prefixes form a base that can be used to compute possible 
targets for the move part of the refactoring.  It finds both the candidates, in 
the form of prefixes, and the non-candidates, called unfixes. All prefixes (and 
unfixes) are represented by a 
\typewithref{no.uio.ifi.refaktor.extractors}{Prefix}, and they are collected 
into prefix sets.\typeref{no.uio.ifi.refaktor.extractors.PrefixSet}. 

The prefixes and unfixes are found by property 
collectors\typeref{no.uio.ifi.refaktor.extractors.collectors.PropertyCollector}.  
A property collector follows the visitor pattern\citing{designPatterns} and is 
of the \typewithref{org.eclipse.jdt.core.dom}{ASTVisitor} type.  An 
\type{ASTVisitor} visits nodes in an abstract syntax tree that forms the Java 
document object model. The tree consists of nodes of type 
\typewithref{org.eclipse.jdt.core.do}{ASTNode}.

\subsubsection{The PrefixesCollector}
The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{PrefixesCollector} 
is of type \type{PropertyCollector}. It visits expression 
statements\typeref{org.eclipse.jdt.core.dom.ExpressionStatement} and creates 
prefixes from its expressions in the case of method invocations. The prefixes 
found is registered with a prefix set, together with all its sub-prefixes.
\todo{Rewrite in the case of changes to the way prefixes are found}

\subsubsection{The UnfixesCollector}
The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{UnfixesCollector} 
finds unfixes within the selection. An unfix is a name that is assigned to 
within the selection. The reason that this cannot be allowed, is that the result 
would be an assignment to the \type{this} keyword, which is not valid in Java.

\subsubsection{Computing Safe Prefixes}
A safe prefix is a prefix that does not enclose an unfix. A prefix is enclosing 
an unfix if the unfix is in the set of its sub-prefixes. As an example, 
\texttt{``a.b''} is enclosing \texttt{``a''}, as is \texttt{``a''}. The safe 
prefixes is unified in a \type{PrefixSet} and can be fetched calling the 
\method{getSafePrefixes} method of the 
\type{ExtractAndMoveMethodPrefixesExtractor}.

\subsection{The Prefix Class}
\todo{?}
\subsection{The PrefixSet Class}

\subsection{Hacking the Refactoring Undo 
History}\label{hacking_undo_history}
\todo{Where to put this section?}

As an attempt to make multiple subsequent changes to the workspace appear as a 
single action (i.e. make the undo changes appear as such), I tried to alter 
the undo changes\typeref{org.eclipse.ltk.core.refactoring.Change} in the history 
of the refactorings.  

My first impulse was to remove the, in this case, last two undo changes from the 
undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} for the 
Eclipse refactorings, and then add them to a composite 
change\typeref{org.eclipse.ltk.core.refactoring.CompositeChange} that could be 
added back to the manager. The interface of the undo manager does not offer a 
way to remove/pop the last added undo change, so a possible solution could be to 
decorate\citing{designPatterns} the undo manager, to intercept and collect the 
undo changes before delegating to the \method{addUndo} 
method\methodref{org.eclipse.ltk.core.refactoring.IUndoManager}{addUndo} of the 
manager. Instead of giving it the intended undo change, a null change could be 
given to prevent it from making any changes if run. Then one could let the 
collected undo changes form a composite change to be added to the manager.

There is a technical challenge with this approach, and it relates to the undo 
manager, and the concrete implementation 
UndoManager2\typeref{org.eclipse.ltk.internal.core.refactoring.UndoManager2}.  
This implementation is designed in a way that it is not possible to just add an 
undo change, you have to do it in the context of an active 
operation\typeref{org.eclipse.core.commands.operations.TriggeredOperations}.  
One could imagine that it might be possible to trick the undo manager into 
believing that you are doing a real change, by executing a refactoring that is 
returning a kind of null change that is returning our composite change of undo 
refactorings when it is performed.

Apart from the technical problems with this solution, there is a functional 
problem: If it all had worked out as planned, this would leave the undo history 
in a dirty state, with multiple empty undo operations corresponding to each of 
the sequentially executed refactoring operations, followed by a composite undo 
change corresponding to an empty change of the workspace for rounding of our 
composite refactoring. The solution to this particular problem could be to 
intercept the registration of the intermediate changes in the undo manager, and 
only register the last empty change.

Unfortunately, not everything works as desired with this solution. The grouping 
of the undo changes into the composite change does not make the undo operation 
appear as an atomic operation. The undo operation is still split up into 
separate undo actions, corresponding to the change done by its originating
refactoring. And in addition, the undo actions has to be performed separate in 
all the editors involved. This makes it no solution at all, but a step toward 
something worse.

There might be a solution to this problem, but it remains to be found. The 
design of the refactoring undo management is partly to be blamed for this, as it 
it is to complex to be easily manipulated.



\chapter{Related Work}

\section{The compositional paradigm of refactoring}
This paradigm builds upon the observation of Vakilian et 
al.\citing{vakilian2012}, that of the many automated refactorings existing in 
modern IDEs, the simplest ones are dominating the usage statistics. The report 
mainly focuses on \emph{Eclipse} as the tool under investigation.

The paradigm is described almost as the opposite of automated composition of 
refactorings \see{compositeRefactorings}. It works by providing the programmer 
with easily accessible primitive refactorings. These refactorings shall be 
accessed via keyboard shortcuts or quick-assist menus\footnote{Think 
quick-assist with Ctrl+1 in Eclipse} and be promptly executed, opposed to in the 
currently dominating wizard-based refactoring paradigm. They are ment to 
stimulate composing smaller refactorings into more complex changes, rather than 
doing a large upfront configuration of a wizard-based refactoring, before 
previewing and executing it. The compositional paradigm of refactoring is 
supposed to give control back to the programmer, by supporting \himher with an 
option of performing small rapid changes instead of large changes with a lesser 
degree of control. The report authors hope this will lead to fewer unsuccessful 
refactorings. It also could lower the bar for understanding the steps of a 
larger composite refactoring and thus also help in figuring out what goes wrong 
if one should choose to op in on a wizard-based refactoring.

Vakilian and his associates have performed a survey of the effectiveness of the 
compositional paradigm versus the wizard-based one. They claim to have found 
evidence of that the \emph{compositional paradigm} outperforms the 
\emph{wizard-based}. It does so by reducing automation, which seem 
counterintuitive. Therefore they ask the question ``What is an appropriate level 
of automation?'', and thus questions what they feel is a rush toward more 
automation in the software engineering community.


\backmatter{}
\printbibliography
\listoftodos
\end{document}