Some talks, mostly identical.

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

\documentclass[USenglish,11pt]{ifimaster}
\usepackage{import}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc,url}
\usepackage{lmodern} % using Latin Modern to be able to use bold typewriter font
%\usepackage{mathpazo}
\urlstyle{sf}
\usepackage{listings}
\usepackage{tabularx}
\usepackage{tikz}
\usepackage{tikz-qtree}
\usetikzlibrary{shapes,snakes,trees,arrows,shadows,positioning,calc}
\usepackage{babel,textcomp,csquotes,ifikompendiumforside}

\usepackage{varioref}
\usepackage[hidelinks]{hyperref}
\usepackage{cleveref}
\usepackage[xindy,entrycounter]{glossaries}

\usepackage[style=alphabetic,backend=biber]{biblatex}
\usepackage{amsthm}
\usepackage{mathtools}
\usepackage{graphicx}
% use 'disable' before printing:
\usepackage[disable]{todonotes}
\usepackage{xspace}
\usepackage{he-she}
\usepackage{verbatim}
\usepackage{minted}
\usepackage{multicol}
\usemintedstyle{bw}
\usepackage{perpage} %the perpage package
\MakePerPage{footnote} %the perpage package command

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

\graphicspath{ {./figures/} }

\newcommand{\citing}[1]{~\cite{#1}}
%\newcommand{\myref}[1]{\cref{#1} on \cpageref{#1}}
\newcommand{\myref}[1]{\vref{#1}}

\newcommand{\glossref}[1]{\textsuperscript{(\glsrefentry{#1})}}
%\newcommand{\gloss}[1]{\gls{#1}\glossref{#1}}
%\newcommand{\glosspl}[1]{\glspl{#1}\glossref{#1}}
\newcommand{\gloss}[1]{\gls{#1}}
\newcommand{\glosspl}[1]{\glspl{#1}}

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

%\newcommand{\type}[1]{\lstinline{#1}}
\newcommand{\code}[1]{\texttt{\textbf{#1}}}
\newcommand{\type}[1]{\code{#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{\name}[1]{#1}
\newcommand{\tit}[1]{\emph{#1}}
\newcommand{\refa}[1]{\emph{#1}}
\newcommand{\pattern}[1]{\emph{#1}}
\newcommand{\metr}[1]{\emph{#1}}
\newcommand{\ExtractMethod}{\refa{Extract Method}\xspace}
\newcommand{\MoveMethod}{\refa{Move Method}\xspace}
\newcommand{\ExtractAndMoveMethod}{\refa{Extract and Move Method}\xspace}

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

\title{Refactoring}
\subtitle{An essay}
\author{Erlend Kristiansen}
\date{2014}

\makeglossaries
\newglossaryentry{profiling}
{
  name=profiling,
  description={is to run a computer program through a profiler/with a profiler 
  attached. A profiler is a program for analyzing performance within an 
application.  It is used to analyze memory consumption, processing time and 
frequency of procedure calls and such},
  %see={profiler}
}
\newglossaryentry{profiler}
{
  name=profiler,
  description={A profiler is a program for analyzing performance within an 
  application. It is used to analyze memory consumption, processing time and 
frequency of procedure calls and such.}
}
\newglossaryentry{xUnit}
{
  name={xUnit framework},
  description={An xUnit framework is a framework for writing unit tests for a 
    computer program. It follows the patterns known from the JUnit framework for 
    Java\citing{fowlerXunit}
  },
  plural={xUnit frameworks}
}
\newglossaryentry{softwareObfuscation}
{
  name={software obfuscation},
  description={makes source code harder to read and analyze, while preserving 
  its semantics}
}
\newglossaryentry{extractClass}
{
  name=\refa{Extract Class},
  description={The \refa{Extract Class} refactoring works by creating a class, 
for then to move members from another class to that class and access them from 
the old class via a reference to the new class}
}
\newglossaryentry{designPattern}
{
  name={design pattern},
  description={A design pattern is a named abstraction, that is meant to solve a 
  general design problem.  It describes the key aspects of a common problem and 
identifies its participators and how they collaborate},
  plural={design patterns}
}
\newglossaryentry{extractMethod}
{
  name=\refa{Extract Method},
  description={The \refa{Extract Method} refactoring is used to extract a 
fragment of code from its context and into a new method. A call to the new 
method is inlined where the fragment was before. It is used to break code into 
logical units, with names that explain their purpose}
}
\newglossaryentry{moveMethod}
{
  name=\refa{Move Method},
  description={The \refa{Move Method} refactoring is used to move a method from   
  one class to another. This is useful if the method is using more features of 
  another class than of the class which it is currently defined. Then all calls 
  to this method must be updated, or the method must be copied, with the old 
method delegating to the new method}
}

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

% UML comment in TikZ:
% ref: https://tex.stackexchange.com/questions/103688/folded-paper-shape-tikz
\makeatletter
\pgfdeclareshape{umlcomment}{
  \inheritsavedanchors[from=rectangle] % this is nearly a rectangle
  \inheritanchorborder[from=rectangle]
  \inheritanchor[from=rectangle]{center}
  \inheritanchor[from=rectangle]{north}
  \inheritanchor[from=rectangle]{south}
  \inheritanchor[from=rectangle]{west}
  \inheritanchor[from=rectangle]{east}
  % ... and possibly more
  \backgroundpath{% this is new
  % store lower right in xa/ya and upper right in xb/yb
  \southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
  \northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
  % compute corner of ‘‘flipped page’’
  \pgf@xc=\pgf@xb \advance\pgf@xc by-10pt % this should be a parameter
  \pgf@yc=\pgf@yb \advance\pgf@yc by-10pt
  % construct main path
  \pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
  \pgfpathlineto{\pgfpoint{\pgf@xa}{\pgf@yb}}
  \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yb}}
  \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
  \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@ya}}
  \pgfpathclose
  % add little corner
  \pgfpathmoveto{\pgfpoint{\pgf@xc}{\pgf@yb}}
  \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
  \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
  \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
  }
}
\makeatother

\tikzstyle{comment}=[%
  draw,
  drop shadow,
  fill=white,
  align=center,
  shape=document,
  minimum width=20mm,
  minimum height=10mm,
  shape=umlcomment,
  inner sep=2ex,
  font=\ttfamily,
]

%\interfootnotelinepenalty=10000
\renewcommand{\thesection}{\arabic{section}}

\begin{document}
\pagenumbering{roman}
\ififorside
\frontmatter{}

\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 make people want to refactor their code.

\section{Defining refactoring}
Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a 
refactoring like this:

\begin{quote}
  \emph{Refactoring} (noun): a change made to the internal 
  structure\footnote{The structure observable by the programmer.} 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 assigns 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 more refined, formed 
to only consider the \emph{mechanical} and \emph{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 \gloss{softwareObfuscation} is 
refactoring. It is often used to protect proprietary software. It restrains 
uninvited viewers, so they have a hard time analyzing code that they are not 
supposed to know how works. This could be a problem when using a language that 
is possible to decompile, such as Java. 

Obfuscation could be done composing many, more or less randomly chosen, 
refactorings. Then the question arises whether it can be called a 
\emph{composite refactoring} or not \see{compositeRefactorings}?  The answer is 
not obvious.  First, there is no way to describe the mechanics of software 
obfuscation, because there are infinitely many ways to do that. Second, 
obfuscation can be thought of as \emph{one operation}: Either the code is 
obfuscated, or it is not. Third, it makes no sense to call software obfuscation 
\emph{a refactoring}, since it holds different meaning to different people.

This last point is important, since one of the motivations behind defining 
different refactorings, is to establish a \emph{vocabulary} for software 
professionals to use when reasoning about and discussing programs, similar to 
the motivation behind \glosspl{designPattern}\citing{designPatterns}.  
\begin{comment}
So for describing \emph{software obfuscation}, it might be more appropriate to 
define what you do when performing it rather than precisely defining its 
mechanics in terms of other refactorings.
\end{comment}

\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{\label{footNote}Programming language} community and their 
infamous \name{Refactoring 
Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}} 
described in the article \tit{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\textsuperscript{\ref{footNote}} community, and the 
word ``refactoring'' is mentioned in a book by Leo Brodie, called \tit{Thinking 
Forth}\citing{brodie2004}, first published in 1984\footnote{\tit{Thinking Forth} 
was first published in 1984 by the \name{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~\cite[p.~232]{brodie2004}, 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]{brodie2004}
\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]{brodie2004}
\end{quote}

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

\section{Motivation -- Why people refactor}
There are many reasons why people want to refactor their programs. They can for 
instance do it to remove duplication, break up long methods or to introduce 
design patterns into their software systems. The shared trait for all these are 
that peoples' intentions are to make their programs \emph{better}, in some 
sense.  But what aspects of their programs are becoming improved?

As just mentioned, people often refactor to get rid of duplication. They are 
moving identical or similar code into methods, and are pushing methods up or 
down in their class hierarchies. They are making template methods for 
overlapping algorithms/functionality, and so on. It is all about gathering what 
belongs together and putting it all in one place. The resulting code is then 
easier to maintain. When removing the implicit coupling\footnote{When 
  duplicating code, the duplicate pieces of code might not be coupled, apart 
from representing the same functionality. So if this functionality is going to 
change, it might need to change in more than one place, thus creating an 
implicit coupling between multiple pieces of code.} between code snippets, the 
location of a bug is limited to only one place, and new functionality need only 
to be added to this one place, instead of a number of places people might not 
even remember.

A problem you often encounter when programming, is that a program contains a lot 
of long and hard-to-grasp methods. It can then help to break the methods into 
smaller ones, using the \gloss{extractMethod} refactoring\citing{refactoring}.  
Then you may discover something about a program that you were not aware of 
before; revealing bugs you did not know about or could not find due to the 
complex structure of your 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 
refactoring an excellent method for exploring unknown program code, or code that 
you had forgotten that you wrote.

Most primitive refactorings are simple, and usually involves moving code 
around\citing{kerievsky2005}. The motivation behind them may first be revealed 
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 design can 
\emph{evolve} throughout the lifetime of a program, as opposed to designing 
up-front.  It is all about being structured and taking small steps to improve a 
program's design.

Many software design pattern are aimed at lowering the coupling between 
different classes and different layers of logic. One of the most famous is 
perhaps the \pattern{Model-View-Controller}\citing{designPatterns} pattern. It 
is aimed at lowering the coupling between the user interface, the business logic 
and the data representation of a program. This also has the added benefit that 
the business logic could much easier be the target of automated tests, thus 
increasing the productivity in the software development process.

Another effect of refactoring is that with the increased separation of concerns 
coming out of many refactorings, the \emph{performance} can be improved. When 
profiling programs, the problematic 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\citing{refactoring}.

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 
are 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. Having robust code is an obvious advantage, but 
understandability and maintainability are both very important aspects of 
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. The perspective on productivity 
and money should also be able to open the eyes of the many nearsighted managers 
that seldom see beyond the next milestone.

\section{The magical number seven}\label{magic_number_seven}
The article \tit{The magical number seven, plus or minus two: some limits on our 
capacity for processing information}\citing{miller1956} by George A.  Miller, 
was published in the journal \name{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. 

\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}

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 
fundamental \ExtractMethod and \refa{Extract Class} 
refactorings\citing{refactoring}.

An example from the article addresses the problem of memorizing a sequence of 
binary digits. The example presented here is a slightly modified version of the 
one presented in the original article\citing{miller1956}, but it preserves the 
essence of it. Let us say we have the following sequence 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 latter sequence is the first sequence 
recoded to be represented by digits in 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 humans 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 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 indicate 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 have 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 
    \tit{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.: \tit{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: \tit{Refactoring to 
    Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's 
    \tit{Refactoring}\citing{refactoring} and the ``Gang of Four'' \tit{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 reader's 
    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 (for Java)}\label{toolSupport}
This section will briefly compare the refactoring support of the three IDEs 
\name{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \name{IntelliJ 
IDEA}\footnote{The IDE under comparison is the \name{Community Edition}, 
\url{http://www.jetbrains.com/idea/}} and 
\name{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 \gloss{moveMethod} refactoring, the \name{Eclipse} and 
\name{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 \name{NetBeans} IDE implements this refactoring in a somewhat 
unsophisticated way. For starters, the refactoring's default destination for the 
move, is the same class as the method already resides in, although it refuses to 
perform the refactoring if chosen.  But the worst part is, that if moving the 
method \method{f} of the class \type{C} to the class \type{X}, it will break the 
code.  The result is shown in \myref{lst:moveMethod_NetBeans}.

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

\columnbreak

\begin{minted}[samepage]{java}
public class X {
    ...
    public void f(C c) {
        c.x.m();
        c.x.n();
    }
}
\end{minted}
\end{multicols}
\caption{Moving method \method{f} from \type{C} to \type{X}.}
\label{lst:moveMethod_NetBeans}
\end{listing}

\name{NetBeans} will try to create 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. (This is 
seldom the desired outcome of this refactoring, but ironically, this ``feature'' 
keeps \name{NetBeans} from breaking the code in the example from \myref{correctness}.) 
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. \name{NetBeans} presents a 
preview of the refactoring outcome, but the preview does not catch it if the IDE 
is about break the program. 

The IDEs under investigation seem to have fairly good support for primitive 
refactorings, but what about more complex ones, such as 
\gloss{extractClass}\citing{refactoring}? \name{IntelliJ} handles 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 with the type of the 
new class, but are not used anywhere. \name{Eclipse} has added its own quirk to 
the \refa{Extract Class} refactoring, and only allows for \emph{fields} to be 
moved to a new class, \emph{not methods}. This makes it effectively only 
extracting a data structure, and calling it \refa{Extract Class} is a little 
misleading.  One would often be better off with textual extract and paste than 
using the \refa{Extract Class} refactoring in \name{Eclipse}. When it comes to 
\name{NetBeans}, it does not even show an attempt on providing this refactoring.  

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

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

Refactoring and 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 maintainable 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 sometimes associated with 
over-engineering\citing{kerievsky2005,refactoring}, 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 too 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 has to change. Assuming that 
a design pattern is the best way to get rid 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 and 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 are 
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 software 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 means 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\footnote{With todays 
  compiler optimization techniques and performance tuning of e.g. the Java 
virtual machine, the penalties of object creation and method calls are 
debatable.}, 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 did 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. 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 \gloss{profiling} 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. 

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

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

\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 \refa{Extract 
Superclass} refactoring\citing{refactoring}. In its simplest form, it is composed 
of the previously described primitive refactorings, in addition to the 
\refa{Pull Up Constructor Body} refactoring\citing{refactoring}. It works 
by creating an abstract superclass that the target class(es) inherits from, then 
by applying \refa{Pull Up Field}, \refa{Pull Up Method} and 
\refa{Pull Up Constructor Body} on the members that are to be members of 
the new superclass. If there are multiple classes in play, their interfaces may 
need to be united with the help of some rename refactorings, before extracting 
the superclass. For an overview of the \refa{Extract Superclass} 
refactoring, see \myref{fig:extractSuperclass}.

\begin{figure}[h]
  \centering
  \includegraphics[angle=270,width=\linewidth]{extractSuperclassItalic.pdf}
  \caption{The Extract Superclass refactoring, with united interfaces.}
  \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 method 
signature and all the other aspects of the refactoring that has to be in place.  

Consider 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 have semantic knowledge 
about which occurrences of which names belong 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. In an ideal 
world, every automated refactoring would be ``complete'', in the sense that it 
would never break a program. In an ideal world, every program would also be free 
from bugs. In modern IDEs the implemented automated refactorings are working for 
\emph{most} cases, that is enough for making them useful.

I will now present an example of a \emph{corner case} where a program breaks 
when a refactoring is applied. The example shows an \ExtractMethod refactoring 
followed by a \MoveMethod refactoring that breaks a program in both the 
\name{Eclipse} and \name{IntelliJ} IDEs\footnote{The \name{NetBeans} IDE handles this 
  particular situation without altering the program's behavior, mainly because 
  its \refa{Move Method} refactoring implementation is a bit flawed in other ways 
  \see{toolSupport}.}.  The target and the destination for the composed 
  refactoring is shown in \myref{lst:correctnessExtractAndMove}.  Note that the 
  method \method{m(C c)} of class \type{X} assigns to the field \var{x} of the 
  argument \var{c} that has type \type{C}.

\begin{listing}[h]
\begin{multicols}{2}
\begin{minted}[linenos]{java}
// Refactoring target
public class C {
  public X x = new X();

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

\columnbreak

\begin{minted}[]{java}
// Method destination
public class X {
  public void m(C c) {
    c.x = new X();
    // If m is called from
    // c, then c.x no longer
    // equals 'this'
  }
  public void n() {}
}
\end{minted}
\end{multicols}
\caption{The target and the destination for the composition of the Extract 
Method and \refa{Move Method} refactorings.}
\label{lst:correctnessExtractAndMove}
\end{listing}


The refactoring sequence works by extracting line 6 through 8 from the original 
class \type{C} into a method \method{f} with the statements from those lines as 
its method body (but with the comment left out, since it will no longer hold any 
meaning). The method is then moved to the class \type{X}.  The result is shown 
in \myref{lst:correctnessExtractAndMoveResult}.

Before the refactoring, the methods \method{m} and \method{n} of class \type{X} 
are called on different object instances (see line 6 and 8 of the original class 
\type{C} in \cref{lst:correctnessExtractAndMove}). After the refactoring, they 
are called on the same object, and the statement on line 
3 of class \type{X} (in \cref{lst:correctnessExtractAndMoveResult}) no longer 
  has the desired effect in our example. The method \method{f} of class \type{C} 
  is now calling the method \method{f} of class \type{X} (see line 5 of class 
  \type{C} in \cref{lst:correctnessExtractAndMoveResult}), and the program now 
  behaves different than before.

\begin{listing}[h]
\begin{multicols}{2}
\begin{minted}[linenos]{java}
public class C {
    public X x = new X();

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

\columnbreak

\begin{minted}[linenos]{java}
public class X {
    public void m(C c) {
        c.x = new X();
    }
    public void n() {}
    // Extracted and 
    // moved method
    public void f(C c) {
        m(c);
        n();
    }
}
\end{minted}
\end{multicols}
\caption{The result of the composed refactoring.}
\label{lst:correctnessExtractAndMoveResult}
\end{listing}

The bug introduced in the previous example is of such a nature\footnote{Caused 
  by aliasing. See \url{https://en.wikipedia.org/wiki/Aliasing_(computing)}} 
  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 the importance of 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 three classes of errors that can be made.  
The first class of errors are the ones that make the code unable to compile.  
These \emph{compile-time} errors are of the nicer kind. They flash up at the 
moment they are made (at least when using an IDE), and are usually easy to fix.  
The second class are the \emph{runtime} errors. Although they take a bit longer 
to surface, they usually manifest after some time in an illegal argument 
exception, null pointer exception or similar during the program execution.  
These kind of errors are a bit harder to handle, but at least they will show, 
eventually. Then there are the \emph{behavior-changing} errors. These errors are 
of the worst kind. They do not show up during compilation and they do not turn 
on a blinking red light during runtime either. The program can seem to work 
perfectly fine with them in play, but the business logic can be damaged in ways 
that will only show up over time.

For discovering runtime errors and behavior changes when refactoring, it is 
essential to have good test coverage. Testing in this context means writing 
automated tests. Manual testing may have its uses, but when refactoring, it is 
automated unit testing that dominate. For discovering behavior changes it is 
especially important to have tests that cover potential problems, since these 
kind of errors does not reveal themselves.

Unit testing is not a way to \emph{prove} that a program is correct, but it is a 
way to make you confident that it \emph{probably} works as desired.  In the 
context of test driven development (commonly known as TDD), the tests are even a 
way to define how the program is \emph{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 automated tests and 
refactoring are such a great match.

\subsection{Testing the code from correctness section}
The worst thing that can happen when refactoring is to introduce changes to the 
behavior of a program, as in the example on \myref{correctness}. This example 
may be trivial, but the essence is clear. The only problem with the example is 
that it is not clear how to create automated tests for it, without changing it 
in intrusive ways.

Unit tests, as they are known from the different \glosspl{xUnit} around, are 
only suitable to test the \emph{result} of isolated operations. They can not 
easily (if at all) observe the \emph{history} of a program.

This problem is still open.

\todoin{Write?}
\begin{comment}

Assuming a sequential (non-concurrent) program:

\begin{minted}{java}
tracematch (C c, X x) {
  sym m before:
    call(* X.m(C)) && args(c) && cflow(within(C));
  sym n before:
    call(* X.n()) && target(x) && cflow(within(C));
  sym setCx after:
    set(C.x) && target(c) && !cflow(m);

  m n

  { assert x == c.x; }
}
\end{minted}

%\begin{minted}{java}
%tracematch (X x1, X x2) {
%  sym m before:
%    call(* X.m(C)) && target(x1);
%  sym n before:
%    call(* X.n()) && target(x2);
%  sym setX after:
%    set(C.x) && !cflow(m) && !cflow(n);
%
%  m n
%
%  { assert x1 != x2; }
%}
%\end{minted}
\end{comment}

\section{The project}
The aim of this master project will be to investigate the relationship between a 
composite refactoring composed of the \ExtractMethod and \MoveMethod 
refactorings, and its impact on one or more software metrics.

The composition of the \ExtractMethod and \MoveMethod refactorings springs 
naturally out of the need to move procedures closer to the data they manipulate.  
This composed refactoring is not well described in the literature, but it is 
implemented in at least one tool called 
\name{CodeRush}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument3519}}, 
that is an extension for \name{MS Visual 
Studio}\footnote{\url{http://www.visualstudio.com/}}. In CodeRush it is called 
\refa{Extract Method to 
Type}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument6710}}, 
but I choose to call it \ExtractAndMoveMethod, since I feel it better 
communicates which primitive refactorings it is composed of. 

For the metrics, I will at least measure the \metr{Coupling between object 
classes} (CBO) metric that is described by Chidamber and Kemerer in their 
article \tit{A Metrics Suite for Object Oriented 
Design}\citing{metricsSuite1994}.

The project will then consist in implementing the \ExtractAndMoveMethod 
refactoring, as well as executing it over a larger code base. Then the effect of 
the change must be measured by calculating the chosen software metrics both 
before and after the execution. To be able to execute the refactoring 
automatically I have to make it analyze code to determine the best selections to 
extract into new methods.


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