\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{\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}
the \emph{Forth} and \emph{Smalltalk} communities, but that it emerged
independently in each of the communities.
-\todo{more history?}
+\todoin{more history?}
\section{Motivation -- Why people refactor}
To get a grasp of what refactoring is all about, we can try to answer this
better) understood.
\section{Notable contributions to the refactoring literature}
-\todo{Update with more contributions}
+\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
\item[todo] \emph{Refactoring to Patterns}\todo{include}
\end{description}
-\section{Tool support}
-\todo{write, section vs. subsection}
+\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.
+
+\todoin{Extract class, Visual Studio (C++/C\#), Smalltalk refactoring browser?,
+second refactoring rubicon?}
\section{Relation to design patterns}
-\todo{write, section vs. subsection, refactoring to patterns?}
+\todoin{refactoring to patterns?}
\begin{comment}
\section{Classification of refactorings}
\section{Correctness of refactorings}\label{correctness}
For automated refactorings to be truly useful, they must show a high degree of
-behavior preservation. This might seem obvious, but there are examples of
-refactorings in existing tools that break programs. \todo{More than Eclipse?} I
-will now present an example of an \ExtractMethod refactoring followed by a
-\MoveMethod refactoring that breaks a program. The following piece of code shows
-the target for the composed refactoring:
-
-\begin{minted}[linenos]{java}
+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();
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}{java}
+\begin{minted}[samepage]{java}
public class X {
public void m(C c) {
c.x = new X();
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]{java}
+\begin{minted}[linenos,samepage]{java}
public class C {
public X x = new X();
}
\end{minted}
-\begin{minted}[linenos]{java}
+\begin{minted}[linenos,samepage]{java}
public class X {
public void m(C c) {
c.x = new X();
\chapter{\ldots}
-\todo{write}
+\todoin{write}
\section{The problem statement}
\section{Choosing the target language}
Choosing which programming language to use as the target for manipulation is not
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}\footnote{\url{http://www.eclipse.org/}}, with the \emph{Java development
-tools} (JDT), the \emph{IntelliJ IDEA Community
-Edition}\footnote{\url{http://www.jetbrains.com/idea/}} and the \emph{NetBeans
-IDE}\footnote{\url{https://netbeans.org/}}. 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.
+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}
git://git.uio.no / ifi-stolz-refaktor.git / commitdiff