1 \documentclass[USenglish]{ifimaster}
3 \usepackage[utf8]{inputenc}
4 \usepackage[T1]{fontenc,url}
5 \usepackage{lmodern} % using Latin Modern to be able to use bold typewriter font
10 \usepackage{tikz-qtree}
11 \usetikzlibrary{shapes,snakes,trees,arrows,shadows,positioning,calc}
12 \usepackage{babel,textcomp,csquotes,ifimasterforside,varioref}
13 \usepackage[hidelinks]{hyperref}
15 \usepackage[style=numeric-comp,backend=bibtex]{biblatex}
18 % use 'disable' before printing:
19 \usepackage[]{todonotes}
26 \usepackage{perpage} %the perpage package
27 \MakePerPage{footnote} %the perpage package command
29 \theoremstyle{definition}
30 \newtheorem*{wordDef}{Definition}
32 \graphicspath{ {./figures/} }
34 \newcommand{\citing}[1]{~\cite{#1}}
35 \newcommand{\myref}[1]{\cref{#1} on \cpageref{#1}}
37 \newcommand{\definition}[1]{\begin{wordDef}#1\end{wordDef}}
38 \newcommand{\see}[1]{(see \myref{#1})}
39 \newcommand{\See}[1]{(See \myref{#1}.)}
40 \newcommand{\explanation}[3]{\noindent\textbf{\textit{#1}}\\*\emph{When:}
41 #2\\*\emph{How:} #3\\*[-7px]}
43 %\newcommand{\type}[1]{\lstinline{#1}}
44 \newcommand{\code}[1]{\texttt{\textbf{#1}}}
45 \newcommand{\type}[1]{\code{#1}}
46 \newcommand{\typeref}[1]{\footnote{\type{#1}}}
47 \newcommand{\typewithref}[2]{\type{#2}\typeref{#1.#2}}
48 \newcommand{\method}[1]{\type{#1}}
49 \newcommand{\methodref}[2]{\footnote{\type{#1}\method{\##2()}}}
50 \newcommand{\methodwithref}[2]{\method{#2}\footnote{\type{#1}\method{\##2()}}}
51 \newcommand{\var}[1]{\type{#1}}
53 \newcommand{\refactoring}[1]{\emph{#1}}
54 \newcommand{\ExtractMethod}{\refactoring{Extract Method}\xspace}
55 \newcommand{\MoveMethod}{\refactoring{Move Method}\xspace}
56 \newcommand{\ExtractAndMoveMethod}{\refactoring{Extract and Move Method}\xspace}
58 \newcommand\todoin[2][]{\todo[inline, caption={2do}, #1]{
59 \begin{minipage}{\textwidth-4pt}#2\end{minipage}}}
63 \author{Erlend Kristiansen}
65 \bibliography{bibliography/master-thesis-erlenkr-bibliography}
67 % UML comment in TikZ:
68 % ref: https://tex.stackexchange.com/questions/103688/folded-paper-shape-tikz
70 \pgfdeclareshape{umlcomment}{
71 \inheritsavedanchors[from=rectangle] % this is nearly a rectangle
72 \inheritanchorborder[from=rectangle]
73 \inheritanchor[from=rectangle]{center}
74 \inheritanchor[from=rectangle]{north}
75 \inheritanchor[from=rectangle]{south}
76 \inheritanchor[from=rectangle]{west}
77 \inheritanchor[from=rectangle]{east}
78 % ... and possibly more
79 \backgroundpath{% this is new
80 % store lower right in xa/ya and upper right in xb/yb
81 \southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
82 \northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
83 % compute corner of ‘‘flipped page’’
84 \pgf@xc=\pgf@xb \advance\pgf@xc by-10pt % this should be a parameter
85 \pgf@yc=\pgf@yb \advance\pgf@yc by-10pt
87 \pgfpathmoveto{\pgfpoint{\pgf@xa}{\pgf@ya}}
88 \pgfpathlineto{\pgfpoint{\pgf@xa}{\pgf@yb}}
89 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yb}}
90 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
91 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@ya}}
94 \pgfpathmoveto{\pgfpoint{\pgf@xc}{\pgf@yb}}
95 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
96 \pgfpathlineto{\pgfpoint{\pgf@xb}{\pgf@yc}}
97 \pgfpathlineto{\pgfpoint{\pgf@xc}{\pgf@yc}}
102 \tikzstyle{comment}=[%
121 \todoin{\textbf{Remove all todos (including list) before delivery/printing!!!
122 Can be done by removing ``draft'' from documentclass.}}
123 \todoin{Write abstract}
131 The discussions in this report must be seen in the context of object oriented
132 programming languages, and Java in particular, since that is the language in
133 which most of the examples will be given. All though the techniques discussed
134 may be applicable to languages from other paradigms, they will not be the
135 subject of this report.
139 \chapter{What is Refactoring?}
141 This question is best answered by first defining the concept of a
142 \emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects
143 of programming make people want to refactor their code.
145 \section{Defining refactoring}
146 Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a
147 refactoring like this:
150 \emph{Refactoring} (noun): a change made to the internal
151 structure\footnote{The structure observable by the programmer.} of software to
152 make it easier to understand and cheaper to modify without changing its
153 observable behavior.~\cite[p.~53]{refactoring}
156 \noindent This definition assigns additional meaning to the word
157 \emph{refactoring}, beyond the composition of the prefix \emph{re-}, usually
158 meaning something like ``again'' or ``anew'', and the word \emph{factoring},
159 that can mean to isolate the \emph{factors} of something. Here a \emph{factor}
160 would be close to the mathematical definition of something that divides a
161 quantity, without leaving a remainder. Fowler is mixing the \emph{motivation}
162 behind refactoring into his definition. Instead it could be more refined, formed
163 to only consider the \emph{mechanical} and \emph{behavioral} aspects of
164 refactoring. That is to factor the program again, putting it together in a
165 different way than before, while preserving the behavior of the program. An
166 alternative definition could then be:
168 \definition{A \emph{refactoring} is a transformation
169 done to a program without altering its external behavior.}
171 From this we can conclude that a refactoring primarily changes how the
172 \emph{code} of a program is perceived by the \emph{programmer}, and not the
173 \emph{behavior} experienced by any user of the program. Although the logical
174 meaning is preserved, such changes could potentially alter the program's
175 behavior when it comes to performance gain or -penalties. So any logic depending
176 on the performance of a program could make the program behave differently after
179 In the extreme case one could argue that such a thing as \emph{software
180 obfuscation} is refactoring. Software obfuscation is to make source code harder
181 to read and analyze, while preserving its semantics. It could be done composing
182 many, more or less randomly chosen, refactorings. Then the question arise
183 whether it can be called a \emph{composite refactoring}
184 \see{compositeRefactorings} or not? The answer is not obvious. First, there is
185 no way to describe \emph{the} mechanics of software obfuscation, beacause there
186 are infinitely many ways to do that. Second, \emph{obfuscation} can be thought
187 of as \emph{one operation}: Either the code is obfuscated, or it is not. Third,
188 it makes no sense to call software obfuscation \emph{a} refactoring, since it
189 holds different meaning to different people. The last point is important, since
190 one of the motivations behind defining different refactorings is to build up a
191 vocabulary for software professionals to reason and discuss about programs,
192 similar to the motivation behind design patterns\citing{designPatterns}. So for
193 describing \emph{software obfuscation}, it might be more appropriate to define
194 what you do when performing it rather than precisely defining its mechanics in
195 terms of other refactorings.
197 \section{The etymology of 'refactoring'}
198 It is a little difficult to pinpoint the exact origin of the word
199 ``refactoring'', as it seems to have evolved as part of a colloquial
200 terminology, more than a scientific term. There is no authoritative source for a
201 formal definition of it.
203 According to Martin Fowler\citing{etymology-refactoring}, there may also be more
204 than one origin of the word. The most well-known source, when it comes to the
205 origin of \emph{refactoring}, is the Smalltalk\footnote{\emph{Smalltalk},
206 object-oriented, dynamically typed, reflective programming language. See
207 \url{http://www.smalltalk.org}} community and their infamous \emph{Refactoring
208 Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}}
209 described in the article \emph{A Refactoring Tool for
210 Smalltalk}\citing{refactoringBrowser1997}, published in 1997.
211 Allegedly\citing{etymology-refactoring}, the metaphor of factoring programs was
212 also present in the Forth\footnote{\emph{Forth} -- stack-based, extensible
213 programming language, without type-checking. See \url{http://www.forth.org}}
214 community, and the word ``refactoring'' is mentioned in a book by Leo Brodie,
215 called \emph{Thinking Forth}\citing{brodie1984}, first published in
216 1984\footnote{\emph{Thinking Forth} was first published in 1984 by the
217 \emph{Forth Interest Group}. Then it was reprinted in 1994 with minor
218 typographical corrections, before it was transcribed into an electronic edition
219 typeset in \LaTeX\ and published under a Creative Commons licence in 2004. The
220 edition cited here is the 2004 edition, but the content should essentially be as
221 in 1984.}. The exact word is only printed one place~\cite[p.~232]{brodie1984},
222 but the term \emph{factoring} is prominent in the book, that also contains a
223 whole chapter dedicated to (re)factoring, and how to keep the (Forth) code clean
227 \ldots good factoring technique is perhaps the most important skill for a
228 Forth programmer.~\cite[p.~172]{brodie1984}
231 \noindent Brodie also express what \emph{factoring} means to him:
234 Factoring means organizing code into useful fragments. To make a fragment
235 useful, you often must separate reusable parts from non-reusable parts. The
236 reusable parts become new definitions. The non-reusable parts become arguments
237 or parameters to the definitions.~\cite[p.~172]{brodie1984}
240 Fowler claims that the usage of the word \emph{refactoring} did not pass between
241 the \emph{Forth} and \emph{Smalltalk} communities, but that it emerged
242 independently in each of the communities.
244 \section{Motivation -- Why people refactor}
245 There are many reasons why people want to refactor their programs. They can for
246 instance do it to remove duplication, break up long methods or to introduce
247 design patterns\citing{designPatterns} into their software systems. The shared
248 trait for all these are that peoples intentions are to make their programs
249 \emph{better}, in some sense. But what aspects of their programs are becoming
252 As already mentioned, people often refactor to get rid of duplication. Moving
253 identical or similar code into methods, and maybe pushing methods up or down in
254 their class hierarchies. Making template methods for overlapping
255 algorithms/functionality and so on. It is all about gathering what belongs
256 together and putting it all in one place. The resulting code is then easier to
257 maintain. When removing the implicit coupling\footnote{When duplicating code,
258 the code might not be coupled in other ways than that it is supposed to
259 represent the same functionality. So if this functionality is going to change,
260 it might need to change in more than one place, thus creating an implicit
261 coupling between the multiple pieces of code.} between code snippets, the
262 location of a bug is limited to only one place, and new functionality need only
263 to be added to this one place, instead of a number of places people might not
266 A problem you often encounter when programming, is that a program contains a lot
267 of long and hard-to-grasp methods. It can then help to break the methods into
268 smaller ones, using the \ExtractMethod refactoring\citing{refactoring}. Then you
269 may discover something about a program that you were not aware of before;
270 revealing bugs you did not know about or could not find due to the complex
271 structure of your program. \todo{Proof?} Making the methods smaller and giving
272 good names to the new ones clarifies the algorithms and enhances the
273 \emph{understandability} of the program \see{magic_number_seven}. This makes
274 refactoring an excellent method for exploring unknown program code, or code that
275 you had forgotten that you wrote.
277 Most primitive refactorings are simple. Their true power is first revealed when
278 they are combined into larger --- higher level --- refactorings, called
279 \emph{composite refactorings} \see{compositeRefactorings}. Often the goal of
280 such a series of refactorings is a design pattern. Thus the \emph{design} can be
281 evolved throughout the lifetime of a program, as opposed to designing up-front.
282 It is all about being structured and taking small steps to improve a program's
285 Many software design pattern are aimed at lowering the coupling between
286 different classes and different layers of logic. One of the most famous is
287 perhaps the \emph{Model-View-Controller}\citing{designPatterns} pattern. It is
288 aimed at lowering the coupling between the user interface and the business logic
289 and data representation of a program. This also has the added benefit that the
290 business logic could much easier be the target of automated tests, increasing
291 the productivity in the software development process. Refactoring is an
292 important tool on the way to something greater.
294 Another effect of refactoring is that with the increased separation of concerns
295 coming out of many refactorings, the \emph{performance} can be improved. When
296 profiling programs, the problematic parts are narrowed down to smaller parts of
297 the code, which are easier to tune, and optimization can be performed only where
298 needed and in a more effective way.
300 Last, but not least, and this should probably be the best reason to refactor, is
301 to refactor to \emph{facilitate a program change}. If one has managed to keep
302 one's code clean and tidy, and the code is not bloated with design patterns that
303 are not ever going to be needed, then some refactoring might be needed to
304 introduce a design pattern that is appropriate for the change that is going to
307 Refactoring program code --- with a goal in mind --- can give the code itself
308 more value. That is in the form of robustness to bugs, understandability and
309 maintainability. Having robust code is an obvious advantage, but
310 understandability and maintainability are both very important aspects of
311 software development. By incorporating refactoring in the development process,
312 bugs are found faster, new functionality is added more easily and code is easier
313 to understand by the next person exposed to it, which might as well be the
314 person who wrote it. The consequence of this, is that refactoring can increase
315 the average productivity of the development process, and thus also add to the
316 monetary value of a business in the long run. The perspective on productivity
317 and money should also be able to open the eyes of the many nearsighted managers
318 that seldom see beyond the next milestone.
320 \section{The magical number seven}\label{magic_number_seven}
321 The article \emph{The magical number seven, plus or minus two: some limits on
322 our capacity for processing information}\citing{miller1956} by George A.
323 Miller, was published in the journal \emph{Psychological Review} in 1956. It
324 presents evidence that support that the capacity of the number of objects a
325 human being can hold in its working memory is roughly seven, plus or minus two
326 objects. This number varies a bit depending on the nature and complexity of the
327 objects, but is according to Miller ``\ldots never changing so much as to be
330 Miller's article culminates in the section called \emph{Recoding}, a term he
331 borrows from communication theory. The central result in this section is that by
332 recoding information, the capacity of the amount of information that a human can
333 process at a time is increased. By \emph{recoding}, Miller means to group
334 objects together in chunks and give each chunk a new name that it can be
335 remembered by. By organizing objects into patterns of ever growing depth, one
336 can memorize and process a much larger amount of data than if it were to be
337 represented as its basic pieces. This grouping and renaming is analogous to how
338 many refactorings work, by grouping pieces of code and give them a new name.
339 Examples are the fundamental \ExtractMethod and \refactoring{Extract Class}
340 refactorings\citing{refactoring}.
343 \ldots recoding is an extremely powerful weapon for increasing the amount of
344 information that we can deal with.~\cite[p.~95]{miller1956}
347 An example from the article addresses the problem of memorizing a sequence of
348 binary digits. Let us say we have the following sequence\footnote{The example
349 presented here is slightly modified (and shortened) from what is presented in
350 the original article\citing{miller1956}, but it is essentially the same.} of
351 16 binary digits: ``1010001001110011''. Most of us will have a hard time
352 memorizing this sequence by only reading it once or twice. Imagine if we instead
353 translate it to this sequence: ``A273''. If you have a background from computer
354 science, it will be obvious that the latest sequence is the first sequence
355 recoded to be represented by digits with base 16. Most people should be able to
356 memorize this last sequence by only looking at it once.
358 Another result from the Miller article is that when the amount of information a
359 human must interpret increases, it is crucial that the translation from one code
360 to another must be almost automatic for the subject to be able to remember the
361 translation, before \heshe is presented with new information to recode. Thus
362 learning and understanding how to best organize certain kinds of data is
363 essential to efficiently handle that kind of data in the future. This is much
364 like when humans learn to read. First they must learn how to recognize letters.
365 Then they can learn distinct words, and later read sequences of words that form
366 whole sentences. Eventually, most of them will be able to read whole books and
367 briefly retell the important parts of its content. This suggest that the use of
368 design patterns\citing{designPatterns} is a good idea when reasoning about
369 computer programs. With extensive use of design patterns when creating complex
370 program structures, one does not always have to read whole classes of code to
371 comprehend how they function, it may be sufficient to only see the name of a
372 class to almost fully understand its responsibilities.
375 Our language is tremendously useful for repackaging material into a few chunks
376 rich in information.~\cite[p.~95]{miller1956}
379 Without further evidence, these results at least indicate that refactoring
380 source code into smaller units with higher cohesion and, when needed,
381 introducing appropriate design patterns, should aid in the cause of creating
382 computer programs that are easier to maintain and has code that is easier (and
385 \section{Notable contributions to the refactoring literature}
386 \todoin{Update with more contributions}
389 \item[1992] William F. Opdyke submits his doctoral dissertation called
390 \emph{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This
391 work defines a set of refactorings, that are behavior preserving given that
392 their preconditions are met. The dissertation is focused on the automation
394 \item[1999] Martin Fowler et al.: \emph{Refactoring: Improving the Design of
395 Existing Code}\citing{refactoring}. This is maybe the most influential text
396 on refactoring. It bares similarities with Opdykes thesis\citing{opdyke1992}
397 in the way that it provides a catalog of refactorings. But Fowler's book is
398 more about the craft of refactoring, as he focuses on establishing a
399 vocabulary for refactoring, together with the mechanics of different
400 refactorings and when to perform them. His methodology is also founded on
401 the principles of test-driven development.
402 \item[2005] Joshua Kerievsky: \emph{Refactoring to
403 Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's
404 \emph{Refactoring}\citing{refactoring} and the ``Gang of Four'' \emph{Design
405 Patterns}\citing{designPatterns}. It is building on the refactoring
406 catalogue from Fowler's book, but is trying to bridge the gap between
407 \emph{refactoring} and \emph{design patterns} by providing a series of
408 higher-level composite refactorings, that makes code evolve toward or away
409 from certain design patterns. The book is trying to build up the readers
410 intuition around \emph{why} one would want to use a particular design
411 pattern, and not just \emph{how}. The book is encouraging evolutionary
412 design. \See{relationToDesignPatterns}
415 \section{Tool support (for Java)}\label{toolSupport}
416 This section will briefly compare the refatoring support of the three IDEs
417 \emph{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \emph{IntelliJ
418 IDEA}\footnote{The IDE under comparison is the \emph{Community Edition},
419 \url{http://www.jetbrains.com/idea/}} and
420 \emph{NetBeans}\footnote{\url{https://netbeans.org/}}. These are the most
421 popular Java IDEs\citing{javaReport2011}.
423 All three IDEs provide support for the most useful refactorings, like the
424 different extract, move and rename refactorings. In fact, Java-targeted IDEs are
425 known for their good refactoring support, so this did not appear as a big
428 The IDEs seem to have excellent support for the \ExtractMethod refactoring, so
429 at least they have all passed the first refactoring
430 rubicon\citing{fowlerRubicon2001,secondRubicon2012}.
432 Regarding the \MoveMethod refactoring, the \emph{Eclipse} and \emph{IntelliJ}
433 IDEs do the job in very similar manners. In most situations they both do a
434 satisfying job by producing the expected outcome. But they do nothing to check
435 that the result does not break the semantics of the program \see{correctness}.
436 The \emph{NetBeans} IDE implements this refactoring in a somewhat
437 unsophisticated way. For starters, its default destination for the move is
438 itself, although it refuses to perform the refactoring if chosen. But the worst
439 part is, that if moving the method \method{f} of the class \type{C} to the class
440 \type{X}, it will break the code. The result is shown in
441 \myref{lst:moveMethod_NetBeans}.
445 \begin{minted}[samepage]{java}
458 \begin{minted}[samepage]{java}
468 \caption{Moving method \method{f} from \type{C} to \type{X}.}
469 \label{lst:moveMethod_NetBeans}
472 NetBeans will try to make code that call the methods \method{m} and \method{n}
473 of \type{X} by accessing them through \var{c.x}, where \var{c} is a parameter of
474 type \type{C} that is added the method \method{f} when it is moved. (This is
475 seldom the desired outcome of this refactoring, but ironically, this ``feature''
476 keeps NetBeans from breaking the code in the example from \myref{correctness}.)
477 If \var{c.x} for some reason is inaccessible to \type{X}, as in this case, the
478 refactoring breaks the code, and it will not compile. NetBeans presents a
479 preview of the refactoring outcome, but the preview does not catch it if the IDE
480 is about break the program.
482 The IDEs under investigation seems to have fairly good support for primitive
483 refactorings, but what about more complex ones, such as the \refactoring{Extract
484 Class}\citing{refactoring}? The \refactoring{Extract Class} refactoring works by
485 creating a class, for then to move members to that class and access them from
486 the old class via a reference to the new class. \emph{IntelliJ} handles this in
487 a fairly good manner, although, in the case of private methods, it leaves unused
488 methods behind. These are methods that delegate to a field with the type of the
489 new class, but are not used anywhere. \emph{Eclipse} has added (or withdrawn)
490 its own quirk to the Extract Class refactoring, and only allows for
491 \emph{fields} to be moved to a new class, \emph{not methods}. This makes it
492 effectively only extracting a data structure, and calling it
493 \refactoring{Extract Class} is a little misleading. One would often be better
494 off with textual extract and paste than using the Extract Class refactoring in
495 Eclipse. When it comes to \emph{NetBeans}, it does not even seem to have made an
496 attempt on providing this refactoring. (Well, it probably has, but it does not
499 \todoin{Visual Studio (C++/C\#), Smalltalk refactoring browser?,
500 second refactoring rubicon?}
502 \section{The relation to design patterns}\label{relationToDesignPatterns}
504 \emph{Refactoring} and \emph{design patterns} have at least one thing in common,
505 they are both promoted by advocates of \emph{clean code}\citing{cleanCode} as
506 fundamental tools on the road to more maintanable and extendable source code.
509 Design patterns help you determine how to reorganize a design, and they can
510 reduce the amount of refactoring you need to do
511 later.~\cite[p.~353]{designPatterns}
514 Although sometimes associated with
515 over-engineering\citing{kerievsky2005,refactoring}, design patterns are in
516 general assumed to be good for maintainability of source code. That may be
517 because many of them are designed to support the \emph{open/closed principle} of
518 object-oriented programming. The principle was first formulated by Bertrand
519 Meyer, the creator of the Eiffel programming language, like this: ``Modules
520 should be both open and closed.''\citing{meyer1988} It has been popularized,
521 with this as a common version:
524 Software entities (classes, modules, functions, etc.) should be open for
525 extension, but closed for modification.\footnote{See
526 \url{http://c2.com/cgi/wiki?OpenClosedPrinciple} or
527 \url{https://en.wikipedia.org/wiki/Open/closed_principle}}
530 Maintainability is often thought of as the ability to be able to introduce new
531 functionality without having to change too much of the old code. When
532 refactoring, the motivation is often to facilitate adding new functionality. It
533 is about factoring the old code in a way that makes the new functionality being
534 able to benefit from the functionality already residing in a software system,
535 without having to copy old code into new. Then, next time someone shall add new
536 functionality, it is less likely that the old code has to change. Assuming that
537 a design pattern is the best way to get rid of duplication and assist in
538 implementing new functionality, it is reasonable to conclude that a design
539 pattern often is the target of a series of refactorings. Having a repertoire of
540 design patterns can also help in knowing when and how to refactor a program to
541 make it reflect certain desired characteristics.
544 There is a natural relation between patterns and refactorings. Patterns are
545 where you want to be; refactorings are ways to get there from somewhere
546 else.~\cite[p.~107]{refactoring}
549 This quote is wise in many contexts, but it is not always appropriate to say
550 ``Patterns are where you want to be\ldots''. \emph{Sometimes}, patterns are
551 where you want to be, but only because it will benefit your design. It is not
552 true that one should always try to incorporate as many design patterns as
553 possible into a program. It is not like they have intrinsic value. They only add
554 value to a system when they support its design. Otherwise, the use of design
555 patterns may only lead to a program that is more complex than necessary.
558 The overuse of patterns tends to result from being patterns happy. We are
559 \emph{patterns happy} when we become so enamored of patterns that we simply
560 must use them in our code.~\cite[p.~24]{kerievsky2005}
563 This can easily happen when relying largely on up-front design. Then it is
564 natural, in the very beginning, to try to build in all the flexibility that one
565 believes will be necessary throughout the lifetime of a software system.
566 According to Joshua Kerievsky ``That sounds reasonable --- if you happen to be
567 psychic.''~\cite[p.~1]{kerievsky2005} He is advocating what he believes is a
568 better approach: To let software continually evolve. To start with a simple
569 design that meets today's needs, and tackle future needs by refactoring to
570 satisfy them. He believes that this is a more economic approach than investing
571 time and money into a design that inevitably is going to change. By relying on
572 continuously refactoring a system, its design can be made simpler without
573 sacrificing flexibility. To be able to fully rely on this approach, it is of
574 utter importance to have a reliable suit of tests to lean on. \See{testing} This
575 makes the design process more natural and less characterized by difficult
576 decisions that has to be made before proceeding in the process, and that is
577 going to define a project for all of its unforeseeable future.
581 \section{Classification of refactorings}
582 % only interesting refactorings
583 % with 2 detailed examples? One for structured and one for intra-method?
584 % Is replacing Bubblesort with Quick Sort considered a refactoring?
586 \subsection{Structural refactorings}
588 \subsubsection{Primitive refactorings}
591 \explanation{Extract Method}{You have a code fragment that can be grouped
592 together.}{Turn the fragment into a method whose name explains the purpose of
595 \explanation{Inline Method}{A method's body is just as clear as its name.}{Put
596 the method's body into the body of its callers and remove the method.}
598 \explanation{Inline Temp}{You have a temp that is assigned to once with a simple
599 expression, and the temp is getting in the way of other refactorings.}{Replace
600 all references to that temp with the expression}
602 % Moving Features Between Objects
603 \explanation{Move Method}{A method is, or will be, using or used by more
604 features of another class than the class on which it is defined.}{Create a new
605 method with a similar body in the class it uses most. Either turn the old method
606 into a simple delegation, or remove it altogether.}
608 \explanation{Move Field}{A field is, or will be, used by another class more than
609 the class on which it is defined}{Create a new field in the target class, and
610 change all its users.}
613 \explanation{Replace Magic Number with Symbolic Constant}{You have a literal
614 number with a particular meaning.}{Create a constant, name it after the meaning,
615 and replace the number with it.}
617 \explanation{Encapsulate Field}{There is a public field.}{Make it private and
620 \explanation{Replace Type Code with Class}{A class has a numeric type code that
621 does not affect its behavior.}{Replace the number with a new class.}
623 \explanation{Replace Type Code with Subclasses}{You have an immutable type code
624 that affects the behavior of a class.}{Replace the type code with subclasses.}
626 \explanation{Replace Type Code with State/Strategy}{You have a type code that
627 affects the behavior of a class, but you cannot use subclassing.}{Replace the
628 type code with a state object.}
630 % Simplifying Conditional Expressions
631 \explanation{Consolidate Duplicate Conditional Fragments}{The same fragment of
632 code is in all branches of a conditional expression.}{Move it outside of the
635 \explanation{Remove Control Flag}{You have a variable that is acting as a
636 control flag fro a series of boolean expressions.}{Use a break or return
639 \explanation{Replace Nested Conditional with Guard Clauses}{A method has
640 conditional behavior that does not make clear the normal path of
641 execution.}{Use guard clauses for all special cases.}
643 \explanation{Introduce Null Object}{You have repeated checks for a null
644 value.}{Replace the null value with a null object.}
646 \explanation{Introduce Assertion}{A section of code assumes something about the
647 state of the program.}{Make the assumption explicit with an assertion.}
649 % Making Method Calls Simpler
650 \explanation{Rename Method}{The name of a method does not reveal its
651 purpose.}{Change the name of the method}
653 \explanation{Add Parameter}{A method needs more information from its
654 caller.}{Add a parameter for an object that can pass on this information.}
656 \explanation{Remove Parameter}{A parameter is no longer used by the method
659 %\explanation{Parameterize Method}{Several methods do similar things but with
660 %different values contained in the method.}{Create one method that uses a
661 %parameter for the different values.}
663 \explanation{Preserve Whole Object}{You are getting several values from an
664 object and passing these values as parameters in a method call.}{Send the whole
667 \explanation{Remove Setting Method}{A field should be set at creation time and
668 never altered.}{Remove any setting method for that field.}
670 \explanation{Hide Method}{A method is not used by any other class.}{Make the
673 \explanation{Replace Constructor with Factory Method}{You want to do more than
674 simple construction when you create an object}{Replace the constructor with a
677 % Dealing with Generalization
678 \explanation{Pull Up Field}{Two subclasses have the same field.}{Move the field
681 \explanation{Pull Up Method}{You have methods with identical results on
682 subclasses.}{Move them to the superclass.}
684 \explanation{Push Down Method}{Behavior on a superclass is relevant only for
685 some of its subclasses.}{Move it to those subclasses.}
687 \explanation{Push Down Field}{A field is used only by some subclasses.}{Move the
688 field to those subclasses}
690 \explanation{Extract Interface}{Several clients use the same subset of a class's
691 interface, or two classes have part of their interfaces in common.}{Extract the
692 subset into an interface.}
694 \explanation{Replace Inheritance with Delegation}{A subclass uses only part of a
695 superclasses interface or does not want to inherit data.}{Create a field for the
696 superclass, adjust methods to delegate to the superclass, and remove the
699 \explanation{Replace Delegation with Inheritance}{You're using delegation and
700 are often writing many simple delegations for the entire interface}{Make the
701 delegating class a subclass of the delegate.}
703 \subsubsection{Composite refactorings}
706 % \explanation{Replace Method with Method Object}{}{}
708 % Moving Features Between Objects
709 \explanation{Extract Class}{You have one class doing work that should be done by
710 two}{Create a new class and move the relevant fields and methods from the old
711 class into the new class.}
713 \explanation{Inline Class}{A class isn't doing very much.}{Move all its features
714 into another class and delete it.}
716 \explanation{Hide Delegate}{A client is calling a delegate class of an
717 object.}{Create Methods on the server to hide the delegate.}
719 \explanation{Remove Middle Man}{A class is doing to much simple delegation.}{Get
720 the client to call the delegate directly.}
723 \explanation{Replace Data Value with Object}{You have a data item that needs
724 additional data or behavior.}{Turn the data item into an object.}
726 \explanation{Change Value to Reference}{You have a class with many equal
727 instances that you want to replace with a single object.}{Turn the object into a
730 \explanation{Encapsulate Collection}{A method returns a collection}{Make it
731 return a read-only view and provide add/remove methods.}
733 % \explanation{Replace Array with Object}{}{}
735 \explanation{Replace Subclass with Fields}{You have subclasses that vary only in
736 methods that return constant data.}{Change the methods to superclass fields and
737 eliminate the subclasses.}
739 % Simplifying Conditional Expressions
740 \explanation{Decompose Conditional}{You have a complicated conditional
741 (if-then-else) statement.}{Extract methods from the condition, then part, an
744 \explanation{Consolidate Conditional Expression}{You have a sequence of
745 conditional tests with the same result.}{Combine them into a single conditional
746 expression and extract it.}
748 \explanation{Replace Conditional with Polymorphism}{You have a conditional that
749 chooses different behavior depending on the type of an object.}{Move each leg
750 of the conditional to an overriding method in a subclass. Make the original
753 % Making Method Calls Simpler
754 \explanation{Replace Parameter with Method}{An object invokes a method, then
755 passes the result as a parameter for a method. The receiver can also invoke this
756 method.}{Remove the parameter and let the receiver invoke the method.}
758 \explanation{Introduce Parameter Object}{You have a group of parameters that
759 naturally go together.}{Replace them with an object.}
761 % Dealing with Generalization
762 \explanation{Extract Subclass}{A class has features that are used only in some
763 instances.}{Create a subclass for that subset of features.}
765 \explanation{Extract Superclass}{You have two classes with similar
766 features.}{Create a superclass and move the common features to the
769 \explanation{Collapse Hierarchy}{A superclass and subclass are not very
770 different.}{Merge them together.}
772 \explanation{Form Template Method}{You have two methods in subclasses that
773 perform similar steps in the same order, yet the steps are different.}{Get the
774 steps into methods with the same signature, so that the original methods become
775 the same. Then you can pull them up.}
778 \subsection{Functional refactorings}
780 \explanation{Substitute Algorithm}{You want to replace an algorithm with one
781 that is clearer.}{Replace the body of the method with the new algorithm.}
785 \section{The impact on software quality}
787 \subsection{What is software quality?}
788 The term \emph{software quality} has many meanings. It all depends on the
789 context we put it in. If we look at it with the eyes of a software developer, it
790 usually means that the software is easily maintainable and testable, or in other
791 words, that it is \emph{well designed}. This often correlates with the
792 management scale, where \emph{keeping the schedule} and \emph{customer
793 satisfaction} is at the center. From the customers point of view, in addition to
794 good usability, \emph{performance} and \emph{lack of bugs} is always
795 appreciated, measurements that are also shared by the software developer. (In
796 addition, such things as good documentation could be measured, but this is out
797 of the scope of this document.)
799 \subsection{The impact on performance}
801 Refactoring certainly will make software go more slowly\footnote{With todays
802 compiler optimization techniques and performance tuning of e.g. the Java
803 virtual machine, the penalties of object creation and method calls are
804 debatable.}, but it also makes the software more amenable to performance
805 tuning.~\cite[p.~69]{refactoring}
808 \noindent There is a common belief that refactoring compromises performance, due
809 to increased degree of indirection and that polymorphism is slower than
812 In a survey, Demeyer\citing{demeyer2002} disproves this view in the case of
813 polymorphism. He did an experiment on, what he calls, ``Transform Self Type
814 Checks'' where you introduce a new polymorphic method and a new class hierarchy
815 to get rid of a class' type checking of a ``type attribute``. He uses this kind
816 of transformation to represent other ways of replacing conditionals with
817 polymorphism as well. The experiment is performed on the C++ programming
818 language and with three different compilers and platforms. Demeyer concludes
819 that, with compiler optimization turned on, polymorphism beats middle to large
820 sized if-statements and does as well as case-statements. (In accordance with
821 his hypothesis, due to similarities between the way C++ handles polymorphism and
825 The interesting thing about performance is that if you analyze most programs,
826 you find that they waste most of their time in a small fraction of the
827 code.~\cite[p.~70]{refactoring}
830 \noindent So, although an increased amount of method calls could potentially
831 slow down programs, one should avoid premature optimization and sacrificing good
832 design, leaving the performance tuning until after profiling\footnote{For and
833 example of a Java profiler, check out VisualVM:
834 \url{http://visualvm.java.net/}} the software and having isolated the actual
837 \section{Composite refactorings}\label{compositeRefactorings}
838 \todo{motivation, examples, manual vs automated?, what about refactoring in a
839 very large code base?}
840 Generally, when thinking about refactoring, at the mechanical level, there are
841 essentially two kinds of refactorings. There are the \emph{primitive}
842 refactorings, and the \emph{composite} refactorings.
844 \definition{A \emph{primitive refactoring} is a refactoring that cannot be
845 expressed in terms of other refactorings.}
847 \noindent Examples are the \refactoring{Pull Up Field} and \refactoring{Pull Up
848 Method} refactorings\citing{refactoring}, that move members up in their class
851 \definition{A \emph{composite refactoring} is a refactoring that can be
852 expressed in terms of two or more other refactorings.}
854 \noindent An example of a composite refactoring is the \refactoring{Extract
855 Superclass} refactoring\citing{refactoring}. In its simplest form, it is composed
856 of the previously described primitive refactorings, in addition to the
857 \refactoring{Pull Up Constructor Body} refactoring\citing{refactoring}. It works
858 by creating an abstract superclass that the target class(es) inherits from, then
859 by applying \refactoring{Pull Up Field}, \refactoring{Pull Up Method} and
860 \refactoring{Pull Up Constructor Body} on the members that are to be members of
861 the new superclass. For an overview of the \refactoring{Extract Superclass}
862 refactoring, see \myref{fig:extractSuperclass}.
866 \includegraphics[angle=270,width=\linewidth]{extractSuperclassItalic.pdf}
867 \caption{The Extract Superclass refactoring}
868 \label{fig:extractSuperclass}
871 \section{Manual vs. automated refactorings}
872 Refactoring is something every programmer does, even if \heshe does not known
873 the term \emph{refactoring}. Every refinement of source code that does not alter
874 the program's behavior is a refactoring. For small refactorings, such as
875 \ExtractMethod, executing it manually is a manageable task, but is still prone
876 to errors. Getting it right the first time is not easy, considering the method
877 signature and all the other aspects of the refactoring that has to be in place.
879 Take for instance the renaming of classes, methods and fields. For complex
880 programs these refactorings are almost impossible to get right. Attacking them
881 with textual search and replace, or even regular expressions, will fall short on
882 these tasks. Then it is crucial to have proper tool support that can perform
883 them automatically. Tools that can parse source code and thus have semantic
884 knowledge about which occurrences of which names belong to what construct in the
885 program. For even trying to perform one of these complex task manually, one
886 would have to be very confident on the existing test suite \see{testing}.
888 \section{Correctness of refactorings}\label{correctness}
889 For automated refactorings to be truly useful, they must show a high degree of
890 behavior preservation. This last sentence might seem obvious, but there are
891 examples of refactorings in existing tools that break programs. I will now
892 present an example of an \ExtractMethod refactoring followed by a \MoveMethod
893 refactoring that breaks a program in both the \emph{Eclipse} and \emph{IntelliJ}
894 IDEs\footnote{The NetBeans IDE handles this particular situation without
895 altering ther program's beavior, mainly because its Move Method refactoring
896 implementation is a bit rancid in other ways \see{toolSupport}.}. The
897 following piece of code shows the target for the composed refactoring:
899 \begin{minted}[linenos,samepage]{java}
901 public X x = new X();
910 \noindent The next piece of code shows the destination of the refactoring. Note
911 that the method \method{m(C c)} of class \type{C} assigns to the field \var{x}
912 of the argument \var{c} that has type \type{C}:
914 \begin{minted}[samepage]{java}
923 The refactoring sequence works by extracting line 5 and 6 from the original
924 class \type{C} into a method \method{f} with the statements from those lines as
925 its method body. The method is then moved to the class \type{X}. The result is
926 shown in the following two pieces of code:
928 \begin{minted}[linenos,samepage]{java}
930 public X x = new X();
938 \begin{minted}[linenos,samepage]{java}
951 After the refactoring, the method \method{f} of class \type{C} is calling the
952 method \method{f} of class \type{X}, and the program now behaves different than
953 before. (See line 5 of the version of class \type{C} after the refactoring.)
954 Before the refactoring, the methods \method{m} and \method{n} of class \type{X}
955 are called on different object instances (see line 5 and 6 of the original class
956 \type{C}). After, they are called on the same object, and the statement on line
957 3 of class \type{X} (the version after the refactoring) no longer have any
958 effect in our example.
960 The bug introduced in the previous example is of such a nature\footnote{Caused
961 by aliasing. See \url{https://en.wikipedia.org/wiki/Aliasing_(computing)}}
962 that it is very difficult to spot if the refactored code is not covered by
963 tests. It does not generate compilation errors, and will thus only result in
964 a runtime error or corrupted data, which might be hard to detect.
966 \section{Refactoring and the importance of testing}\label{testing}
968 If you want to refactor, the essential precondition is having solid
969 tests.\citing{refactoring}
972 When refactoring, there are roughly three classes of errors that can be made.
973 The first class of errors are the ones that make the code unable to compile.
974 These \emph{compile-time} errors are of the nicer kind. They flash up at the
975 moment they are made (at least when using an IDE), and are usually easy to fix.
976 The second class are the \emph{runtime} errors. Although they take a bit longer
977 to surface, they usually manifest after some time in an illegal argument
978 exception, null pointer exception or similar during the program execution.
979 These kind of errors are a bit harder to handle, but at least they will show,
980 eventually. Then there are the \emph{behavior-changing} errors. These errors are
981 of the worst kind. They do not show up during compilation and they do not turn
982 on a blinking red light during runtime either. The program can seem to work
983 perfectly fine with them in play, but the business logic can be damaged in ways
984 that will only show up over time.
986 For discovering runtime errors and behavior changes when refactoring, it is
987 essential to have good test coverage. Testing in this context means writing
988 automated tests. Manual testing may have its uses, but when refactoring, it is
989 automated unit testing that dominate. For discovering behavior changes it is
990 especially important to have tests that cover potential problems, since these
991 kind of errors does not reveal themselves.
993 Unit testing is not a way to \emph{prove} that a program is correct, but it is a
994 way to make you confindent that it \emph{probably} works as desired. In the
995 context of test driven development (commonly known as TDD), the tests are even a
996 way to define how the program is \emph{supposed} to work. It is then, by
997 definition, working if the tests are passing.
999 If the test coverage for a code base is perfect, then it should, theoretically,
1000 be risk-free to perform refactorings on it. This is why automated tests and
1001 refactoring are such a great match.
1003 \subsection{Testing the code from correctness section}
1004 The worst thing that can happen when refactoring is to introduce changes to the
1005 behavior of a program, as in the example on \myref{correctness}. This example
1006 may be trivial, but the essence is clear. The only problem with the example is
1007 that it is not clear how to create automated tests for it, without changing it
1010 Unit tests, as they are known from the different xUnit frameworks around, are
1011 only suitable to test the \emph{result} of isolated operations. They can not
1012 easily (if at all) observe the \emph{history} of a program.
1015 \todoin{Write \ldots}
1017 Assuming a sequential (non-concurrent) program:
1019 \begin{minted}{java}
1020 tracematch (C c, X x) {
1022 call(* X.m(C)) && args(c) && cflow(within(C));
1024 call(* X.n()) && target(x) && cflow(within(C));
1026 set(C.x) && target(c) && !cflow(m);
1030 { assert x == c.x; }
1034 %\begin{minted}{java}
1035 %tracematch (X x1, X x2) {
1037 % call(* X.m(C)) && target(x1);
1039 % call(* X.n()) && target(x2);
1041 % set(C.x) && !cflow(m) && !cflow(n);
1045 % { assert x1 != x2; }
1049 \section{The project}
1050 The aim of this project will be to investigate the relationship between a
1051 composite refactoring composed of the \ExtractMethod and \MoveMethod
1052 refactorings, and its impact on one or more software metrics.
1054 The composition of \ExtractMethod and \MoveMethod springs naturally out of the
1055 need to move procedures closer to the data they manipulate. This composed
1056 refactoring is not well described in the literature, but it is implemented in at
1057 least one tool called
1058 \emph{CodeRush}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument3519}},
1059 that is an extension for \emph{MS Visual
1060 Studio}\footnote{\url{http://www.visualstudio.com/}}. In CodeRush it is called
1061 \emph{Extract Method to
1062 Type}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument6710}},
1063 but I choose to call it \ExtractAndMoveMethod, since I feel it better
1064 communicates which primitive refactorings it is composed of.
1066 For the metrics, I will at least measure the \emph{Coupling between object
1067 classes} (CBO) metric that is described by Chidamber and Kemerer in their
1068 article \emph{A Metrics Suite for Object Oriented
1069 Design}\citing{metricsSuite1994}.
1071 The project will then consist in implementing the \ExtractAndMoveMethod
1072 refactoring, as well as executing it over a larger code base. Then the effect of
1073 the change must be measured by calculating the chosen software metrics both
1074 before and after the execution. To be able to execute the refactoring
1075 automatically I have to make it analyze code to determine the best selections to
1076 extract into new methods.
1078 \section{Software metrics}
1079 \todoin{Is this the appropriate place to have this section?}
1082 %\chapter{Planning the project}
1090 \section{The problem statement}
1091 \section{Choosing the target language}
1092 Choosing which programming language to use as the target for manipulation is not
1093 a very difficult task. The language has to be an object-oriented programming
1094 language, and it must have existing tool support for refactoring. The
1095 \emph{Java} programming language\footnote{\url{https://www.java.com/}} is the
1096 dominating language when it comes to examples in the literature of refactoring,
1097 and is thus a natural choice. Java is perhaps, currently the most influential
1098 programming language in the world, with its \emph{Java Virtual Machine} that
1099 runs on all of the most popular architectures and also supports\footnote{They
1100 compile to java bytecode.} dozens of other programming languages, with
1101 \emph{Scala}, \emph{Clojure} and \emph{Groovy} as the most prominent ones. Java
1102 is currently the language that every other programming language is compared
1103 against. It is also the primary language of the author of this thesis.
1105 \section{Choosing the tools}
1106 When choosing a tool for manipulating Java, there are certain criterias that
1107 have to be met. First of all, the tool should have some existing refactoring
1108 support that this thesis can build upon. Secondly it should provide some kind of
1109 framework for parsing and analyzing Java source code. Third, it should itself be
1110 open source. This is both because of the need to be able to browse the code for
1111 the existing refactorings that is contained in the tool, and also because open
1112 source projects hold value in them selves. Another important aspect to consider
1113 is that open source projects of a certain size, usually has large communities of
1114 people connected to them, that are commited to answering questions regarding the
1115 use and misuse of the products, that to a large degree is made by the cummunity
1118 There is a certain class of tools that meet these criterias, namely the class of
1119 \emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
1120 proagrams that is ment to support the whole production cycle of a cumputer
1121 program, and the most popular IDEs that support Java, generally have quite good
1122 refactoring support.
1124 The main contenders for this thesis is the \emph{Eclipse IDE}, with the
1125 \emph{Java development tools} (JDT), the \emph{IntelliJ IDEA Community Edition}
1126 and the \emph{NetBeans IDE}. \See{toolSupport} Eclipse and NetBeans are both
1127 free, open source and community driven, while the IntelliJ IDEA has an open
1128 sourced community edition that is free of charge, but also offer an
1129 \emph{Ultimate Edition} with an extended set of features, at additional cost.
1130 All three IDEs supports adding plugins to extend their functionality and tools
1131 that can be used to parse and analyze Java source code. But one of the IDEs
1132 stand out as a favorite, and that is the \emph{Eclipse IDE}. This is the most
1133 popular\citing{javaReport2011} among them and seems to be de facto standard IDE
1134 for Java development regardless of platform.
1136 \section{Organizing the programming project}
1137 The software written is organized as some Eclipse plugins. Writing a plugin is
1138 the natural way to utilize the API of Eclipse. This also makes it possible to
1139 provide a user interface to manually run operations on selections in program
1140 source code or whole projects/packages.
1142 When writing a plugin in Eclipse, one has access to resources such as the
1143 current workspace, the open editor and the current selection.
1147 \chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful
1148 Thinking}\label{ch:jdt_refactorings}
1150 This chapter will deal with some of the design behind refactoring support in
1151 Eclipse, and the JDT in specific. After which it will follow a section about
1152 shortcomings of the refactoring API in terms of composition of refactorings. The
1153 chapter will be concluded with a section telling some of the ways the
1154 implementation of refactorings in the JDT could have worked to facilitate
1155 composition of refactorings.
1158 The refactoring world of Eclipse can in general be separated into two parts: The
1159 language independent part and the part written for a specific programming
1160 language -- the language that is the target of the supported refactorings.
1161 \todo{What about the language specific part?}
1163 \subsection{The Language Toolkit}
1164 The Language Toolkit, or LTK for short, is the framework that is used to
1165 implement refactorings in Eclipse. It is language independent and provides the
1166 abstractions of a refactoring and the change it generates, in the form of the
1167 classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} and
1168 \typewithref{org.eclipse.ltk.core.refactoring}{Change}. (There is also parts of
1169 the LTK that is concerned with user interaction, but they will not be discussed
1170 here, since they are of little value to us and our use of the framework.)
1172 \subsubsection{The Refactoring Class}
1173 The abstract class \type{Refactoring} is the core of the LTK framework. Every
1174 refactoring that is going to be supported by the LTK have to end up creating an
1175 instance of one of its subclasses. The main responsibilities of subclasses of
1176 \type{Refactoring} is to implement template methods for condition checking
1177 (\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkInitialConditions}
1179 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkFinalConditions}),
1181 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{createChange}
1182 method that creates and returns an instance of the \type{Change} class.
1184 If the refactoring shall support that others participate in it when it is
1185 executed, the refactoring has to be a processor-based
1186 refactoring\typeref{org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring}.
1187 It then delegates to its given
1188 \typewithref{org.eclipse.ltk.core.refactoring.participants}{RefactoringProcessor}
1189 for condition checking and change creation.
1191 \subsubsection{The Change Class}
1192 This class is the base class for objects that is responsible for performing the
1193 actual workspace transformations in a refactoring. The main responsibilities for
1194 its subclasses is to implement the
1195 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{perform} and
1196 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{isValid} methods. The
1197 \method{isValid} method verifies that the change object is valid and thus can be
1198 executed by calling its \method{perform} method. The \method{perform} method
1199 performs the desired change and returns an undo change that can be executed to
1200 reverse the effect of the transformation done by its originating change object.
1202 \subsubsection{Executing a Refactoring}\label{executing_refactoring}
1203 The life cycle of a refactoring generally follows two steps after creation:
1204 condition checking and change creation. By letting the refactoring object be
1206 \typewithref{org.eclipse.ltk.core.refactoring}{CheckConditionsOperation} that
1207 in turn is handled by a
1208 \typewithref{org.eclipse.ltk.core.refactoring}{CreateChangeOperation}, it is
1209 assured that the change creation process is managed in a proper manner.
1211 The actual execution of a change object has to follow a detailed life cycle.
1212 This life cycle is honored if the \type{CreateChangeOperation} is handled by a
1213 \typewithref{org.eclipse.ltk.core.refactoring}{PerformChangeOperation}. If also
1214 an undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} is set
1215 for the \type{PerformChangeOperation}, the undo change is added into the undo
1218 \section{Shortcomings}
1219 This section is introduced naturally with a conclusion: The JDT refactoring
1220 implementation does not facilitate composition of refactorings.
1221 \todo{refine}This section will try to explain why, and also identify other
1222 shortcomings of both the usability and the readability of the JDT refactoring
1225 I will begin at the end and work my way toward the composition part of this
1228 \subsection{Absence of Generics in Eclipse Source Code}
1229 This section is not only concerning the JDT refactoring API, but also large
1230 quantities of the Eclipse source code. The code shows a striking absence of the
1231 Java language feature of generics. It is hard to read a class' interface when
1232 methods return objects or takes parameters of raw types such as \type{List} or
1233 \type{Map}. This sometimes results in having to read a lot of source code to
1234 understand what is going on, instead of relying on the available interfaces. In
1235 addition, it results in a lot of ugly code, making the use of typecasting more
1236 of a rule than an exception.
1238 \subsection{Composite Refactorings Will Not Appear as Atomic Actions}
1240 \subsubsection{Missing Flexibility from JDT Refactorings}
1241 The JDT refactorings are not made with composition of refactorings in mind. When
1242 a JDT refactoring is executed, it assumes that all conditions for it to be
1243 applied successfully can be found by reading source files that has been
1244 persisted to disk. They can only operate on the actual source material, and not
1245 (in-memory) copies thereof. This constitutes a major disadvantage when trying to
1246 compose refactorings, since if an exception occur in the middle of a sequence of
1247 refactorings, it can leave the project in a state where the composite
1248 refactoring was executed only partly. It makes it hard to discard the changes
1249 done without monitoring and consulting the undo manager, an approach that is not
1252 \subsubsection{Broken Undo History}
1253 When designing a composed refactoring that is to be performed as a sequence of
1254 refactorings, you would like it to appear as a single change to the workspace.
1255 This implies that you would also like to be able to undo all the changes done by
1256 the refactoring in a single step. This is not the way it appears when a sequence
1257 of JDT refactorings is executed. It leaves the undo history filled up with
1258 individual undo actions corresponding to every single JDT refactoring in the
1259 sequence. This problem is not trivial to handle in Eclipse.
1260 \See{hacking_undo_history}
1262 \section{Wishful Thinking}
1265 \chapter{Composite Refactorings in Eclipse}
1267 \section{A Simple Ad Hoc Model}
1268 As pointed out in \myref{ch:jdt_refactorings}, the Eclipse JDT refactoring model
1269 is not very well suited for making composite refactorings. Therefore a simple
1270 model using changer objects (of type \type{RefaktorChanger}) is used as an
1271 abstraction layer on top of the existing Eclipse refactorings, instead of
1272 extending the \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} class.
1274 The use of an additional abstraction layer is a deliberate choice. It is due to
1275 the problem of creating a composite
1276 \typewithref{org.eclipse.ltk.core.refactoring}{Change} that can handle text
1277 changes that interfere with each other. Thus, a \type{RefaktorChanger} may, or
1278 may not, take advantage of one or more existing refactorings, but it is always
1279 intended to make a change to the workspace.
1281 \subsection{A typical \type{RefaktorChanger}}
1282 The typical refaktor changer class has two responsibilities, checking
1283 preconditions and executing the requested changes. This is not too different
1284 from the responsibilities of an LTK refactoring, with the distinction that a
1285 refaktor changer also executes the change, while an LTK refactoring is only
1286 responsible for creating the object that can later be used to do the job.
1288 Checking of preconditions is typically done by an
1289 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{Analyzer}. If the
1290 preconditions validate, the upcoming changes are executed by an
1291 \typewithref{no.uio.ifi.refaktor.change.executors}{Executor}.
1293 \section{The Extract and Move Method Refactoring}
1294 %The Extract and Move Method Refactoring is implemented mainly using these
1297 % \item \type{ExtractAndMoveMethodChanger}
1298 % \item \type{ExtractAndMoveMethodPrefixesExtractor}
1299 % \item \type{Prefix}
1300 % \item \type{PrefixSet}
1303 \subsection{The Building Blocks}
1304 This is a composite refactoring, and hence is built up using several primitive
1305 refactorings. These basic building blocks are, as its name implies, the
1306 \ExtractMethod refactoring\citing{refactoring} and the \MoveMethod
1307 refactoring\citing{refactoring}. In Eclipse, the implementations of these
1308 refactorings are found in the classes
1309 \typewithref{org.eclipse.jdt.internal.corext.refactoring.code}{ExtractMethodRefactoring}
1311 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure}{MoveInstanceMethodProcessor},
1312 where the last class is designed to be used together with the processor-based
1313 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveRefactoring}.
1315 \subsubsection{The ExtractMethodRefactoring Class}
1316 This class is quite simple in its use. The only parameters it requires for
1317 construction is a compilation
1318 unit\typeref{org.eclipse.jdt.core.ICompilationUnit}, the offset into the source
1319 code where the extraction shall start, and the length of the source to be
1320 extracted. Then you have to set the method name for the new method together with
1321 its visibility and some not so interesting parameters.
1323 \subsubsection{The MoveInstanceMethodProcessor Class}
1324 For the Move Method, the processor requires a little more advanced input than
1325 the class for the Extract Method. For construction it requires a method
1326 handle\typeref{org.eclipse.jdt.core.IMethod} for the method that is to be moved.
1327 Then the target for the move have to be supplied as the variable binding from a
1328 chosen variable declaration. In addition to this, one have to set some
1329 parameters regarding setters/getters, as well as delegation.
1331 To make a working refactoring from the processor, one have to create a
1332 \type{MoveRefactoring} with it.
1334 \subsection{The ExtractAndMoveMethodChanger Class}
1336 The \typewithref{no.uio.ifi.refaktor.changers}{ExtractAndMoveMethodChanger}
1337 class is a subclass of the class
1338 \typewithref{no.uio.ifi.refaktor.changers}{RefaktorChanger}. It is responsible
1339 for analyzing and finding the best target for, and also executing, a composition
1340 of the Extract Method and Move Method refactorings. This particular changer is
1341 the one of my changers that is closest to being a true LTK refactoring. It can
1342 be reworked to be one if the problems with overlapping changes are resolved. The
1343 changer requires a text selection and the name of the new method, or else a
1344 method name will be generated. The selection has to be of the type
1345 \typewithref{no.uio.ifi.refaktor.utils}{CompilationUnitTextSelection}. This
1346 class is a custom extension to
1347 \typewithref{org.eclipse.jface.text}{TextSelection}, that in addition to the
1348 basic offset, length and similar methods, also carry an instance of the
1349 underlying compilation unit handle for the selection.
1351 \subsubsection{The \type{ExtractAndMoveMethodAnalyzer}}
1352 The analysis and precondition checking is done by the
1353 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{ExtractAnd\-MoveMethodAnalyzer}.
1354 First is check whether the selection is a valid selection or not, with respect
1355 to statement boundaries and that it actually contains any selections. Then it
1356 checks the legality of both extracting the selection and also moving it to
1357 another class. This checking of is performed by a range of checkers
1358 \see{checkers}. If the selection is approved as legal, it is analyzed to find
1359 the presumably best target to move the extracted method to.
1361 For finding the best suitable target the analyzer is using a
1362 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{PrefixesCollector} that
1363 collects all the possible candidates for the refactoring. All the non-candidates
1365 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{UnfixesCollector} that
1366 collects all the targets that will give some kind of error if used. (For
1367 details about the property collectors, se \myref{propertyCollectors}.) All
1368 prefixes (and unfixes) are represented by a
1369 \typewithref{no.uio.ifi.refaktor.extractors}{Prefix}, and they are collected
1370 into sets of prefixes. The safe prefixes is found by subtracting from the set of
1371 candidate prefixes the prefixes that is enclosing any of the unfixes. A prefix
1372 is enclosing an unfix if the unfix is in the set of its sub-prefixes. As an
1373 example, \texttt{``a.b''} is enclosing \texttt{``a''}, as is \texttt{``a''}. The
1374 safe prefixes is unified in a \type{PrefixSet}. If a prefix has only one
1375 occurrence, and is a simple expression, it is considered unsuitable as a move
1376 target. This occurs in statements such as \texttt{``a.foo()''}. For such
1377 statements it bares no meaning to extract and move them. It only generates an
1378 extra method and the calling of it.
1380 The most suitable target for the refactoring is found by finding the prefix with
1381 the most occurrences. If two prefixes have the same occurrence count, but they
1382 differ in length, the longest of them is chosen.
1384 \todoin{Clean up sections/subsections.}
1386 \subsubsection{The \type{ExtractAndMoveMethodExecutor}}
1387 If the analysis finds a possible target for the composite refactoring, it is
1389 \typewithref{no.uio.ifi.refaktor.change.executors}{ExtractAndMoveMethodExecutor}.
1390 It is composed of the two executors known as
1391 \typewithref{no.uio.ifi.refaktor.change.executors}{ExtractMethodRefactoringExecutor}
1393 \typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethodRefactoringExecutor}.
1394 The \type{ExtractAndMoveMethodExecutor} is responsible for gluing the two
1395 together by feeding the \type{MoveMethod\-RefactoringExecutor} with the
1396 resources needed after executing the extract method refactoring.
1397 \See{postExtractExecution}
1399 \subsubsection{The \type{ExtractMethodRefactoringExecutor}}
1400 This executor is responsible for creating and executing an instance of the
1401 \type{ExtractMethodRefactoring} class. It is also responsible for collecting
1402 some post execution resources that can be used to find the method handle for the
1403 extracted method, as well as information about its parameters, including the
1404 variable they originated from.
1406 \subsubsection{The \type{MoveMethodRefactoringExecutor}}
1407 This executor is responsible for creating and executing an instance of the
1408 \type{MoveRefactoring}. The move refactoring is a processor-based refactoring,
1409 and for the Move Method refactoring it is the \type{MoveInstanceMethodProcessor}
1412 The handle for the method to be moved is found on the basis of the information
1413 gathered after the execution of the Extract Method refactoring. The only
1414 information the \type{ExtractMethodRefactoring} is sharing after its execution,
1415 regarding find the method handle, is the textual representation of the new
1416 method signature. Therefore it must be parsed, the strings for types of the
1417 parameters must be found and translated to a form that can be used to look up
1418 the method handle from its type handle. They have to be on the unresolved
1419 form.\todo{Elaborate?} The name for the type is found from the original
1420 selection, since an extracted method must end up in the same type as the
1423 When analyzing a selection prior to performing the Extract Method refactoring, a
1424 target is chosen. It has to be a variable binding, so it is either a field or a
1425 local variable/parameter. If the target is a field, it can be used with the
1426 \type{MoveInstanceMethodProcessor} as it is, since the extracted method still is
1427 in its scope. But if the target is local to the originating method, the target
1428 that is to be used for the processor must be among its parameters. Thus the
1429 target must be found among the extracted method's parameters. This is done by
1430 finding the parameter information object that corresponds to the parameter that
1431 was declared on basis of the original target's variable when the method was
1432 extracted. (The extracted method must take one such parameter for each local
1433 variable that is declared outside the selection that is extracted.) To match the
1434 original target with the correct parameter information object, the key for the
1435 information object is compared to the key from the original target's binding.
1436 The source code must then be parsed to find the method declaration for the
1437 extracted method. The new target must be found by searching through the
1438 parameters of the declaration and choose the one that has the same type as the
1439 old binding from the parameter information object, as well as the same name that
1440 is provided by the parameter information object.
1443 \subsection{Finding the IMethod}\label{postExtractExecution}
1444 \todoin{Rename section. Write.}
1447 \subsection{The Prefix Class}
1448 This class exists mainly for holding data about a prefix, such as the expression
1449 that the prefix represents and the occurrence count of the prefix within a
1450 selection. In addition to this, it has some functionality such as calculating
1451 its sub-prefixes and intersecting it with another prefix. The definition of the
1452 intersection between two prefixes is a prefix representing the longest common
1453 expression between the two.
1455 \subsection{The PrefixSet Class}
1456 A prefix set holds elements of type \type{Prefix}. It is implemented with the
1457 help of a \typewithref{java.util}{HashMap} and contains some typical set
1458 operations, but it does not implement the \typewithref{java.util}{Set}
1459 interface, since the prefix set does not need all of the functionality a
1460 \type{Set} requires to be implemented. In addition It needs some other
1461 functionality not found in the \type{Set} interface. So due to the relatively
1462 limited use of prefix sets, and that it almost always needs to be referenced as
1463 such, and not a \type{Set<Prefix>}, it remains as an ad hoc solution to a
1466 There are two ways adding prefixes to a \type{PrefixSet}. The first is through
1467 its \method{add} method. This works like one would expect from a set. It adds
1468 the prefix to the set if it does not already contain the prefix. The other way
1469 is to \emph{register} the prefix with the set. When registering a prefix, if the
1470 set does not contain the prefix, it is just added. If the set contains the
1471 prefix, its count gets incremented. This is how the occurrence count is handled.
1473 The prefix set also computes the set of prefixes that is not enclosing any
1474 prefixes of another set. This is kind of a set difference operation only for
1477 \subsection{Hacking the Refactoring Undo
1478 History}\label{hacking_undo_history}
1479 \todoin{Where to put this section?}
1481 As an attempt to make multiple subsequent changes to the workspace appear as a
1482 single action (i.e. make the undo changes appear as such), I tried to alter
1483 the undo changes\typeref{org.eclipse.ltk.core.refactoring.Change} in the history
1484 of the refactorings.
1486 My first impulse was to remove the, in this case, last two undo changes from the
1487 undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} for the
1488 Eclipse refactorings, and then add them to a composite
1489 change\typeref{org.eclipse.ltk.core.refactoring.CompositeChange} that could be
1490 added back to the manager. The interface of the undo manager does not offer a
1491 way to remove/pop the last added undo change, so a possible solution could be to
1492 decorate\citing{designPatterns} the undo manager, to intercept and collect the
1493 undo changes before delegating to the \method{addUndo}
1494 method\methodref{org.eclipse.ltk.core.refactoring.IUndoManager}{addUndo} of the
1495 manager. Instead of giving it the intended undo change, a null change could be
1496 given to prevent it from making any changes if run. Then one could let the
1497 collected undo changes form a composite change to be added to the manager.
1499 There is a technical challenge with this approach, and it relates to the undo
1500 manager, and the concrete implementation
1501 UndoManager2\typeref{org.eclipse.ltk.internal.core.refactoring.UndoManager2}.
1502 This implementation is designed in a way that it is not possible to just add an
1503 undo change, you have to do it in the context of an active
1504 operation\typeref{org.eclipse.core.commands.operations.TriggeredOperations}.
1505 One could imagine that it might be possible to trick the undo manager into
1506 believing that you are doing a real change, by executing a refactoring that is
1507 returning a kind of null change that is returning our composite change of undo
1508 refactorings when it is performed.
1510 Apart from the technical problems with this solution, there is a functional
1511 problem: If it all had worked out as planned, this would leave the undo history
1512 in a dirty state, with multiple empty undo operations corresponding to each of
1513 the sequentially executed refactoring operations, followed by a composite undo
1514 change corresponding to an empty change of the workspace for rounding of our
1515 composite refactoring. The solution to this particular problem could be to
1516 intercept the registration of the intermediate changes in the undo manager, and
1517 only register the last empty change.
1519 Unfortunately, not everything works as desired with this solution. The grouping
1520 of the undo changes into the composite change does not make the undo operation
1521 appear as an atomic operation. The undo operation is still split up into
1522 separate undo actions, corresponding to the change done by its originating
1523 refactoring. And in addition, the undo actions has to be performed separate in
1524 all the editors involved. This makes it no solution at all, but a step toward
1527 There might be a solution to this problem, but it remains to be found. The
1528 design of the refactoring undo management is partly to be blamed for this, as it
1529 it is to complex to be easily manipulated.
1534 \chapter{Analyzing Source Code in Eclipse}
1536 \section{The Java model}
1537 The Java model of Eclipse is its internal representation of a Java project. It
1538 is light-weight, and has only limited possibilities for manipulating source
1539 code. It is typically used as a basis for the Package Explorer in Eclipse.
1541 The elements of the Java model is only handles to the underlying elements. This
1542 means that the underlying element of a handle does not need to actually exist.
1543 Hence the user of a handle must always check that it exist by calling the
1544 \method{exists} method of the handle.
1546 The handles with descriptions is listed in \myref{tab:javaModelTable}.
1551 \newcolumntype{L}[1]{>{\hsize=#1\hsize\raggedright\arraybackslash}X}%
1552 % sum must equal number of columns (3)
1553 \begin{tabularx}{\textwidth}{| L{0.7} | L{1.1} | L{1.2} |}
1555 \textbf{Project Element} & \textbf{Java Model element} &
1556 \textbf{Description} \\
1558 Java project & \type{IJavaProject} & The Java project which contains all other objects. \\
1560 Source folder /\linebreak[2] binary folder /\linebreak[3] external library &
1561 \type{IPackageFragmentRoot} & Hold source or binary files, can be a folder
1562 or a library (zip / jar file). \\
1564 Each package & \type{IPackageFragment} & Each package is below the
1565 \type{IPackageFragmentRoot}, sub-packages are not leaves of the package,
1566 they are listed directed under \type{IPackageFragmentRoot}. \\
1568 Java Source file & \type{ICompilationUnit} & The Source file is always below
1569 the package node. \\
1571 Types /\linebreak[2] Fields /\linebreak[3] Methods & \type{IType} /
1573 \type{IField} /\linebreak[3] \type{IMethod} & Types, fields and methods. \\
1576 \caption{The elements of the Java Model. {\footnotesize Taken from
1577 \url{http://www.vogella.com/tutorials/EclipseJDT/article.html}}}
1578 \label{tab:javaModelTable}
1581 The hierarchy of the Java Model is shown in \myref{fig:javaModel}.
1585 \begin{tikzpicture}[%
1586 grow via three points={one child at (0,-0.7) and
1587 two children at (0,-0.7) and (0,-1.4)},
1588 edge from parent path={(\tikzparentnode.south west)+(0.5,0) |-
1589 (\tikzchildnode.west)}]
1590 \tikzstyle{every node}=[draw=black,thick,anchor=west]
1591 \tikzstyle{selected}=[draw=red,fill=red!30]
1592 \tikzstyle{optional}=[dashed,fill=gray!50]
1593 \node {\type{IJavaProject}}
1594 child { node {\type{IPackageFragmentRoot}}
1595 child { node {\type{IPackageFragment}}
1596 child { node {\type{ICompilationUnit}}
1597 child { node {\type{IType}}
1598 child { node {\type{\{ IType \}*}}
1599 child { node {\type{\ldots}}}
1602 child { node {\type{\{ IField \}*}}}
1603 child { node {\type{IMethod}}
1604 child { node {\type{\{ IType \}*}}
1605 child { node {\type{\ldots}}}
1610 child { node {\type{\{ IMethod \}*}}}
1619 child { node {\type{\{ IType \}*}}}
1630 child { node {\type{\{ ICompilationUnit \}*}}}
1643 child { node {\type{\{ IPackageFragment \}*}}}
1658 child { node {\type{\{ IPackageFragmentRoot \}*}}}
1661 \caption{The Java model of Eclipse. ``\type{\{ SomeElement \}*}'' means
1662 \type{SomeElement} zero or more times. For recursive structures,
1663 ``\type{\ldots}'' is used.}
1664 \label{fig:javaModel}
1667 \section{The Abstract Synax Tree}
1668 Eclipse is following the common paradigm of using an abstract syntaxt tree for
1669 source code analysis and manipulation.
1671 When parsing program source code into something that can be used as a foundation
1672 for analysis, the start of the process follows the same steps as in a compiler.
1673 This is all natural, because the way a compiler anayzes code is no different
1674 from how source manipulation programs would do it, except for some properties of
1675 code that is analyzed in the parser, and that they may be differing in what
1676 kinds of properties they analyze. Thus the process of translation source code
1677 into a structure that is suitable for analyzing, can be seen as a kind of
1678 interrupted compilation process \see{fig:interruptedCompilationProcess}.
1683 base/.style={anchor=north, align=center, rectangle, minimum height=1.4cm},
1684 basewithshadow/.style={base, drop shadow, fill=white},
1685 outlined/.style={basewithshadow, draw, rounded corners, minimum
1687 primary/.style={outlined, font=\bfseries},
1688 dashedbox/.style={outlined, dashed},
1689 arrowpath/.style={black, align=center, font=\small},
1690 processarrow/.style={arrowpath, ->, >=angle 90, shorten >=1pt},
1692 \begin{tikzpicture}[node distance=1.3cm and 3cm, scale=1, every
1693 node/.style={transform shape}]
1694 \node[base](AuxNode1){\small source code};
1695 \node[primary, right=of AuxNode1, xshift=-2.5cm](Scanner){Scanner};
1696 \node[primary, right=of Scanner, xshift=0.5cm](Parser){Parser};
1697 \node[dashedbox, below=of Parser](SemanticAnalyzer){Semantic\\Analyzer};
1698 \node[dashedbox, left=of SemanticAnalyzer](SourceCodeOptimizer){Source
1700 \node[dashedbox, below=of SourceCodeOptimizer
1701 ](CodeGenerator){Code\\Generator};
1702 \node[dashedbox, right=of CodeGenerator](TargetCodeOptimizer){Target
1704 \node[base, right=of TargetCodeOptimizer](AuxNode2){};
1706 \draw[processarrow](AuxNode1) -- (Scanner);
1708 \path[arrowpath] (Scanner) -- node [sloped](tokens){tokens}(Parser);
1709 \draw[processarrow](Scanner) -- (tokens) -- (Parser);
1711 \path[arrowpath] (Parser) -- node (syntax){syntax
1712 tree}(SemanticAnalyzer);
1713 \draw[processarrow](Parser) -- (syntax) -- (SemanticAnalyzer);
1715 \path[arrowpath] (SemanticAnalyzer) -- node
1716 [sloped](annotated){annotated\\tree}(SourceCodeOptimizer);
1717 \draw[processarrow, dashed](SemanticAnalyzer) -- (annotated) --
1718 (SourceCodeOptimizer);
1720 \path[arrowpath] (SourceCodeOptimizer) -- node
1721 (intermediate){intermediate code}(CodeGenerator);
1722 \draw[processarrow, dashed](SourceCodeOptimizer) -- (intermediate) --
1725 \path[arrowpath] (CodeGenerator) -- node [sloped](target1){target
1726 code}(TargetCodeOptimizer);
1727 \draw[processarrow, dashed](CodeGenerator) -- (target1) --
1728 (TargetCodeOptimizer);
1730 \path[arrowpath](TargetCodeOptimizer) -- node [sloped](target2){target
1732 \draw[processarrow, dashed](TargetCodeOptimizer) -- (target2) (AuxNode2);
1734 \caption{Interrupted compilation process. {\footnotesize (Full compilation
1735 process borrowed from \emph{Compiler construction: principles and practice}
1736 by Kenneth C. Louden\citing{louden1997}.)}}
1737 \label{fig:interruptedCompilationProcess}
1740 The process starts with a \emph{scanner}, or lexer. The job of the scanner is to
1741 read the source code and divide it into tokens for the parser. Therefore, it is
1742 also sometimes called a tokenizer. A token is a logical unit, defined in the
1743 language specification, consisting of one or more consecutive characters. In
1744 the java language the tokens can for instance be the \var{this} keyword, a curly
1745 bracket \var{\{} or a \var{nameToken}. It is recognized by the scanner on the
1746 basis of something eqivalent of a regular expression. This part of the process
1747 is often implemented with the use of a finite automata. In fact, it is common to
1748 specify the tokens in regular expressions, that in turn is translated into a
1749 finite automata lexer. This process can be automated.
1751 The program component used to translate a a stream of tokens into something
1752 meaningful, is called a parser. A parser is fed tokens from the scanner and
1753 performs an analysis of the structure of a program. It verifies that the syntax
1754 is correct according to the grammar rules of a language, that is usually
1755 specified in a context-free grammar, and often in a variant of the
1757 Form}\footnote{\url{https://en.wikipedia.org/wiki/Backus-Naur\_Form}}. The
1758 result coming from the parser is in the form of an \emph{Abstract Syntax Tree},
1759 AST for short. It is called \emph{abstract}, because the structure does not
1760 contain all of the tokens produced by the scanner. It only contain logical
1761 constructs, and because it forms a tree, all kinds of parentheses and brackets
1762 are implicit in the structure. It is this AST that is used when performing the
1763 semantic analysis of the code.
1765 As an example we can think of the expression \code{(5 + 7) * 2}. The root of
1766 this tree would in Eclipse be an \type{InfixExpression} with the operator
1767 \var{TIMES}, and a left operand that is also an \type{InfixExpression} with the
1768 operator \var{PLUS}. The left operand \type{InfixExpression}, has in turn a left
1769 operand of type \type{NumberLiteral} with the value \var{``5''} and a right
1770 operand \type{NumberLiteral} with the value \var{``7''}. The root will have a
1771 right operand of type \type{NumberLiteral} and value \var{``2''}. The AST for
1772 this expression is illustrated in \myref{fig:astInfixExpression}.
1774 Contrary to the Java Model, an abstract syntaxt tree is a heavy-weight
1775 representation of source code. It contains information about propertes like type
1776 bindings for variables and variable bindings for names.
1781 \begin{tikzpicture}[scale=0.8]
1782 \tikzset{level distance=40pt}
1783 \tikzset{sibling distance=5pt}
1784 \tikzstyle{thescale}=[scale=0.8]
1785 \tikzset{every tree node/.style={align=center}}
1786 \tikzset{edge from parent/.append style={thick}}
1787 \tikzstyle{inode}=[rectangle,rounded corners,draw,fill=lightgray,drop
1788 shadow,align=center]
1789 \tikzset{every internal node/.style={inode}}
1790 \tikzset{every leaf node/.style={draw=none,fill=none}}
1792 \Tree [.\type{InfixExpression} [.\type{InfixExpression}
1793 [.\type{NumberLiteral} \var{``5''} ] [.\type{Operator} \var{PLUS} ]
1794 [.\type{NumberLiteral} \var{``7''} ] ]
1795 [.\type{Operator} \var{TIMES} ]
1796 [.\type{NumberLiteral} \var{``2''} ]
1799 \caption{The abstract syntax tree for the expression \code{(5 + 7) * 2}.}
1800 \label{fig:astInfixExpression}
1803 \subsection{The AST in Eclipse}
1804 In Eclipse, every node in the AST is a child of the abstract superclass
1805 \typewithref{org.eclipse.jdt.core.dom}{ASTNode}. Every \type{ASTNode}, among a
1806 lot of other things, provides information about its position and length in the
1807 source code, as well as a reference to its parent and to the root of the tree.
1809 The root of the AST is always of type \type{CompilationUnit}. It is not the same
1810 as an instance of an \type{ICompilationUnit}, which is the compilation unit
1811 handle of the Java model. The children of a \type{CompilationUnit} is an
1812 optional \type{PackageDeclaration}, zero or more nodes of type
1813 \type{ImportDecaration} and all its top-level type declarations that has node
1814 types \type{AbstractTypeDeclaration}.
1816 An \type{AbstractType\-Declaration} can be one of the types
1817 \type{AnnotationType\-Declaration}, \type{Enum\-Declaration} or
1818 \type{Type\-Declaration}. The children of an \type{AbstractType\-Declaration}
1819 must be a subtype of a \type{BodyDeclaration}. These subtypes are:
1820 \type{AnnotationTypeMember\-Declaration}, \type{EnumConstant\-Declaration},
1821 \type{Field\-Declaration}, \type{Initializer} and \type{Method\-Declaration}.
1823 Of the body declarations, the \type{Method\-Declaration} is the most interesting
1824 one. Its children include lists of modifiers, type parameters, parameters and
1825 exceptions. It has a return type node and a body node. The body, if present, is
1826 of type \type{Block}. A \type{Block} is itself a \type{Statement}, and its
1827 children is a list of \type{Statement} nodes.
1829 There are too many types of the abstract type \type{Statement} to list up, but
1830 there exists a subtype of \type{Statement} for every statement type of Java, as
1831 one would expect. This also applies to the abstract type \type{Expression}.
1832 However, the expression \type{Name} is a little special, since it is both used
1833 as an operand in compound expressions, as well as for names in type declarations
1836 There is an overview of some of the structure of an Eclipse AST in
1837 \myref{fig:astEclipse}.
1841 \begin{tikzpicture}[scale=0.8]
1842 \tikzset{level distance=50pt}
1843 \tikzset{sibling distance=5pt}
1844 \tikzstyle{thescale}=[scale=0.8]
1845 \tikzset{every tree node/.style={align=center}}
1846 \tikzset{edge from parent/.append style={thick}}
1847 \tikzstyle{inode}=[rectangle,rounded corners,draw,fill=lightgray,drop
1848 shadow,align=center]
1849 \tikzset{every internal node/.style={inode}}
1850 \tikzset{every leaf node/.style={draw=none,fill=none}}
1852 \Tree [.\type{CompilationUnit} [.\type{[ PackageDeclaration ]} [.\type{Name} ]
1853 [.\type{\{ Annotation \}*} ] ]
1854 [.\type{\{ ImportDeclaration \}*} [.\type{Name} ] ]
1855 [.\type{\{ AbstractTypeDeclaration \}+} [.\node(site){\type{\{
1856 BodyDeclaration \}*}}; ] [.\type{SimpleName} ] ]
1858 \begin{scope}[shift={(0.5,-6)}]
1859 \node[inode,thescale](root){\type{MethodDeclaration}};
1860 \node[inode,thescale](modifiers) at (4.5,-5){\type{\{ IExtendedModifier \}*}
1861 \\ {\footnotesize (Of type \type{Modifier} or \type{Annotation})}};
1862 \node[inode,thescale](typeParameters) at (-6,-3.5){\type{\{ TypeParameter
1864 \node[inode,thescale](parameters) at (-5,-5){\type{\{
1865 SingleVariableDeclaration \}*} \\ {\footnotesize (Parameters)}};
1866 \node[inode,thescale](exceptions) at (5,-3){\type{\{ Name \}*} \\
1867 {\footnotesize (Exceptions)}};
1868 \node[inode,thescale](return) at (-6.5,-2){\type{Type} \\ {\footnotesize
1870 \begin{scope}[shift={(0,-5)}]
1871 \Tree [.\node(body){\type{[ Block ]} \\ {\footnotesize (Body)}};
1872 [.\type{\{ Statement \}*} [.\type{\{ Expression \}*} ]
1873 [.\type{\{ Statement \}*} [.\type{\ldots} ]]
1878 \draw[->,>=triangle 90,shorten >=1pt](root.east)..controls +(east:2) and
1879 +(south:1)..(site.south);
1881 \draw (root.south) -- (modifiers);
1882 \draw (root.south) -- (typeParameters);
1883 \draw (root.south) -- ($ (parameters.north) + (2,0) $);
1884 \draw (root.south) -- (exceptions);
1885 \draw (root.south) -- (return);
1886 \draw (root.south) -- (body);
1889 \caption{The format of the abstract syntax tree in Eclipse.}
1890 \label{fig:astEclipse}
1892 \todoin{Add more to the AST format tree? \myref{fig:astEclipse}}
1894 \section{The ASTVisitor}\label{astVisitor}
1895 So far, the only thing that has been adressed is how the the data that is going
1896 to be the basis for our analysis is structured. Another aspect of it is how we
1897 are going to traverse the AST to gather the information we need, so we can
1898 conclude about the properties we are analysing. It is of course possible to
1899 start at the top of the tree, and manually search through its nodes for the ones
1900 we are looking for, but that is a bit inconvenient. To be able to efficiently
1901 utilize such an approach, we would need to make our own framework for traversing
1902 the tree and visiting only the types of nodes we are after. Luckily, this
1903 functionality is already provided in Eclipse, by its
1904 \typewithref{org.eclipse.jdt.core.dom}{ASTVisitor}.
1906 The Eclipse AST, together with its \type{ASTVisitor}, follows the \emph{Visitor}
1907 pattern\citing{designPatterns}. The intent of this design pattern is to
1908 facilitate extending the functionality of classes without touching the classes
1911 Let us say that there is a class hierarchy of \emph{Elements}. These elements
1912 all have a method \method{accept(Visitor visitor)}. In its simplest form, the
1913 \method{accept} method just calls the \method{visit} method of the visitor with
1914 itself as an argument, like this: \code{visitor.visit(this)}. For the visitors
1915 to be able to extend the functionality of all the classes in the elements
1916 hierarchy, each \type{Visitor} must have one visit method for each concrete
1917 class in the hierarchy. Say the hierarchy consists of the concrete classes
1918 \type{ConcreteElementA} and \type{ConcreteElementB}. Then each visitor must have
1919 the (possibly empty) methods \method{visit(ConcreteElementA element)} and
1920 \method{visit(ConcreteElementB element)}. This scenario is depicted in
1921 \myref{fig:visitorPattern}.
1925 \tikzstyle{abstract}=[rectangle, draw=black, fill=white, drop shadow, text
1926 centered, anchor=north, text=black, text width=6cm, every one node
1927 part/.style={align=center, font=\bfseries\itshape}]
1928 \tikzstyle{concrete}=[rectangle, draw=black, fill=white, drop shadow, text
1929 centered, anchor=north, text=black, text width=6cm]
1930 \tikzstyle{inheritarrow}=[->, >=open triangle 90, thick]
1931 \tikzstyle{commentarrow}=[->, >=angle 90, dashed]
1932 \tikzstyle{line}=[-, thick]
1933 \tikzset{every one node part/.style={align=center, font=\bfseries}}
1934 \tikzset{every second node part/.style={align=center, font=\ttfamily}}
1936 \begin{tikzpicture}[node distance=1cm, scale=0.8, every node/.style={transform
1938 \node (Element) [abstract, rectangle split, rectangle split parts=2]
1940 \nodepart{one}{Element}
1941 \nodepart{second}{+accept(visitor: Visitor)}
1943 \node (AuxNode01) [text width=0, minimum height=2cm, below=of Element] {};
1944 \node (ConcreteElementA) [concrete, rectangle split, rectangle split
1945 parts=2, left=of AuxNode01]
1947 \nodepart{one}{ConcreteElementA}
1948 \nodepart{second}{+accept(visitor: Visitor)}
1950 \node (ConcreteElementB) [concrete, rectangle split, rectangle split
1951 parts=2, right=of AuxNode01]
1953 \nodepart{one}{ConcreteElementB}
1954 \nodepart{second}{+accept(visitor: Visitor)}
1957 \node[comment, below=of ConcreteElementA] (CommentA) {visitor.visit(this)};
1959 \node[comment, below=of ConcreteElementB] (CommentB) {visitor.visit(this)};
1961 \node (AuxNodeX) [text width=0, minimum height=1cm, below=of AuxNode01] {};
1963 \node (Visitor) [abstract, rectangle split, rectangle split parts=2,
1966 \nodepart{one}{Visitor}
1967 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
1969 \node (AuxNode02) [text width=0, minimum height=2cm, below=of Visitor] {};
1970 \node (ConcreteVisitor1) [concrete, rectangle split, rectangle split
1971 parts=2, left=of AuxNode02]
1973 \nodepart{one}{ConcreteVisitor1}
1974 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
1976 \node (ConcreteVisitor2) [concrete, rectangle split, rectangle split
1977 parts=2, right=of AuxNode02]
1979 \nodepart{one}{ConcreteVisitor2}
1980 \nodepart{second}{+visit(ConcreteElementA)\\+visit(ConcreteElementB)}
1984 \draw[inheritarrow] (ConcreteElementA.north) -- ++(0,0.7) -|
1986 \draw[line] (ConcreteElementA.north) -- ++(0,0.7) -|
1987 (ConcreteElementB.north);
1989 \draw[inheritarrow] (ConcreteVisitor1.north) -- ++(0,0.7) -|
1991 \draw[line] (ConcreteVisitor1.north) -- ++(0,0.7) -|
1992 (ConcreteVisitor2.north);
1994 \draw[commentarrow] (CommentA.north) -- (ConcreteElementA.south);
1995 \draw[commentarrow] (CommentB.north) -- (ConcreteElementB.south);
1999 \caption{The Visitor Pattern.}
2000 \label{fig:visitorPattern}
2003 The use of the visitor pattern can be appropriate when the hierarchy of elements
2004 is mostly stable, but the family of operations over its elements is constantly
2005 growing. This is clearly the cas for the Eclipse AST, since the hierarchy of
2006 type \type{ASTNode} is very stable, but the functionality of its elements is
2007 extended every time someone needs to operate on the AST. Another aspect of the
2008 Eclipse implementation is that it is a public API, and the visitor pattern is an
2009 easy way to provide access to the nodes in the tree.
2011 The version of the visitor pattern implemented for the AST nodes in Eclipse also
2012 provides an elegant way to traverse the tree. It does so by following the
2013 convention that every node in the tree first let the visitor visit itself,
2014 before it also makes all its children accept the visitor. The children are only
2015 visited if the visit method of their parent returns \var{true}. This pattern
2016 then makes for a prefix traversal of the AST. If postfix traversal is desired,
2017 the visitors also has \method{endVisit} methods for each node type, that is
2018 called after the \method{visit} method for a node. In addition to these visit
2019 methods, there are also the methods \method{preVisit(ASTNode)},
2020 \method{postVisit(ASTNode)} and \method{preVisit2(ASTNode)}. The
2021 \method{preVisit} method is called before the type-specific \method{visit}
2022 method. The \method{postVisit} method is called after the type-specific
2023 \method{endVisit}. The type specific \method{visit} is only called if
2024 \method{preVisit2} returns \var{true}. Overriding the \method{preVisit2} is also
2025 altering the behavior of \method{preVisit}, since the default implementation is
2026 responsible for calling it.
2028 An example of a trivial \type{ASTVisitor} is shown in
2029 \myref{lst:astVisitorExample}.
2032 \begin{minted}{java}
2033 public class CollectNamesVisitor extends ASTVisitor {
2034 Collection<Name> names = new LinkedList<Name>();
2037 public boolean visit(QualifiedName node) {
2043 public boolean visit(SimpleName node) {
2049 \caption{An \type{ASTVisitor} that visits all the names in a subtree and adds
2050 them to a collection, except those names that are children of any
2051 \type{QualifiedName}.}
2052 \label{lst:astVisitorExample}
2055 \section{Property collectors}\label{propertyCollectors}
2056 The prefixes and unfixes are found by property
2057 collectors\typeref{no.uio.ifi.refaktor.extractors.collectors.PropertyCollector}.
2058 A property collector is of the \type{ASTVisitor} type, and thus visits nodes of
2059 type \type{ASTNode} of the abstract syntax tree \see{astVisitor}.
2061 \subsection{The PrefixesCollector}
2062 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{PrefixesCollector}
2063 finds prefixes that makes up the basis for calculating move targets for the
2064 Extract and Move Method refactoring. It visits expression
2065 statements\typeref{org.eclipse.jdt.core.dom.ExpressionStatement} and creates
2066 prefixes from its expressions in the case of method invocations. The prefixes
2067 found is registered with a prefix set, together with all its sub-prefixes.
2069 \subsection{The UnfixesCollector}\label{unfixes}
2070 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{UnfixesCollector}
2071 finds unfixes within a selection. That is prefixes that cannot be used as a
2072 basis for finding a move target in a refactoring.
2074 An unfix can be a name that is assigned to within a selection. The reason that
2075 this cannot be allowed, is that the result would be an assignment to the
2076 \type{this} keyword, which is not valid in Java \see{eclipse_bug_420726}.
2078 Prefixes that originates from variable declarations within the same selection
2079 are also considered unfixes. This is because when a method is moved, it needs to
2080 be called through a variable. If this variable is also within the method that is
2081 to be moved, this obviously cannot be done.
2083 Also considered as unfixes are variable references that are of types that is not
2084 suitable for moving a methods to. This can be either because it is not
2085 physically possible to move the method to the desired class or that it will
2086 cause compilation errors by doing so.
2088 If the type binding for a name is not resolved it is considered and unfix. The
2089 same applies to types that is only found in compiled code, so they have no
2090 underlying source that is accessible to us. (E.g. the \type{java.lang.String}
2093 Interfaces types are not suitable as targets. This is simply because interfaces
2094 in java cannot contain methods with bodies. (This thesis does not deal with
2095 features of Java versions later than Java 7. Java 8 has interfaces with default
2096 implementations of methods.) Neither are local types allowed. This accounts for
2097 both local and anonymous classes. Anonymous classes are effectively the same as
2098 interface types with respect to unfixes. Local classes could in theory be used
2099 as targets, but this is not possible due to limitations of the implementation of
2100 the Extract and Move Method refactoring. The problem is that the refactoring is
2101 done in two steps, so the intermediate state between the two refactorings would
2102 not be legal Java code. In the case of local classes, the problem is that, in
2103 the intermediate step, a selection referencing a local class would need to take
2104 the local class as a parameter if it were to be extracted to a new method. This
2105 new method would need to live in the scope of the declaring class of the
2106 originating method. The local class would then not be in the scope of the
2107 extracted method, thus bringing the source code into an illegal state. One could
2108 imagine that the method was extracted and moved in one operation, without an
2109 intermediate state. Then it would make sense to include variables with types of
2110 local classes in the set of legal targets, since the local classes would then be
2111 in the scopes of the method calls. If this makes any difference for software
2112 metrics that measure coupling would be a different discussion.
2115 \begin{multicols}{2}
2116 \begin{minted}[]{java}
2118 void declaresLocalClass() {
2133 \begin{minted}[]{java}
2134 // After Extract Method
2135 void declaresLocalClass() {
2146 // Intermediate step
2147 void fooBar(LocalClass inst) {
2153 \caption{When Extract and Move Method tries to use a variable with a local type
2154 as the move target, an intermediate step is taken that is not allowed. Here:
2155 \type{LocalClass} is not in the scope of \method{fooBar} in its intermediate
2157 \label{lst:extractMethod_LocalClass}
2160 The last class of names that are considered unfixes is names used in null tests.
2161 These are tests that reads like this: if \texttt{<name>} equals \var{null} then
2162 do something. If allowing variables used in those kinds of expressions as
2163 targets for moving methods, we would end up with code containing boolean
2164 expressions like \texttt{this == null}, which would not be meaningful, since
2165 \var{this} would never be \var{null}.
2168 \subsection{The ContainsReturnStatementCollector}
2170 \typewithref{no.uio.ifi.refaktor.analyze.collectors}{ContainsReturnStatementCollector}
2171 is a very simple property collector. It only visits the return statements within
2172 a selection, and can report whether it encountered a return statement or not.
2174 \subsection{The LastStatementCollector}
2175 The \typewithref{no.uio.ifi.refaktor.analyze.collectors}{LastStatementCollector}
2176 collects the last statement of a selection. It does so by only visiting the top
2177 level statements of the selection, and compares the textual end offset of each
2178 encuntered statement with the end offset of the previous statement found.
2180 \section{Checkers}\label{checkers}
2181 The checkers are a range of classes that checks that selections complies with
2182 certian criterias. If a
2183 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{Checker} fails, it throws a
2184 \type{CheckerException}. The checkers are managed by the
2185 \type{LegalStatementsChecker}, which does not, in fact, implement the
2186 \type{Checker} interface. It does, however, run all the checkers registered with
2187 it, and reports that all statements are considered legal if no
2188 \type{CheckerException} is thrown. Many of the checkers either extends the
2189 \type{PropertyCollector} or utilizes one or more property collectors to verify
2190 some criterias. The checkers registered with the \type{LegalStatementsChecker}
2191 are described next. They are run in the order presented below.
2193 \subsection{The EnclosingInstanceReferenceChecker}
2194 The purpose of this checker is to verify that the names in a selection is not
2195 referencing any enclosing instances. This is for making sure that all references
2196 is legal in a method that is to be moved. Theoretically, some situations could
2197 be easily solved my passing a reference to the referenced class with the moved
2198 method (e.g. when calling public methods), but the dependency on the
2199 \type{MoveInstanceMethodProcessor} prevents this.
2202 \typewithref{no.uio.ifi.refaktor.analyze.analyzers}{EnclosingInstanceReferenceChecker}
2203 is a modified version of the
2204 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure.MoveInstanceMethodProcessor}{EnclosingInstanceReferenceFinder}
2205 from the \type{MoveInstanceMethodProcessor}. Wherever the
2206 \type{EnclosingInstanceReferenceFinder} would create a fatal error status, the
2207 checker throws a \type{CheckerException}.
2209 It works by first finding all of the enclosing types of a selection. Thereafter
2210 it visits all its simple names to check that they are not references to
2211 variables or methods declared in any of the enclosing types. In addition the
2212 checker visits \var{this}-expressions to verify that no such expressions is
2213 qualified with any name.
2215 \subsection{The ReturnStatementsChecker}\label{returnStatementsChecker}
2216 \todoin{Write\ldots/change implementation/use control flow graph?}
2218 \subsection{The AmbiguousReturnValueChecker}
2219 This checker verifies that there are no \emph{ambiguous return statements} in a
2220 selection. The problem with ambiguous return statements arise when a selection
2221 is chosen to be extracted into a new method, but it needs to return more than
2222 one value from that method. This problem occurs in two situations. The first
2223 situation arise when there is more than one local variable that is both assigned
2224 to within a selection and also referenced after the selection. The other
2225 situation occur when there is only one such assignment, but there is also one or
2226 more return statements in the selection.
2228 First the checker needs to collect some data. Those data are the binding keys
2229 for all simple names that are assigned to within the selection, including
2230 variable declarations, but excluding fields. The checker also collects whether
2231 there exists a return statement in the selection or not. No further checks of
2232 return statements are needed, since, at this point, the selection is already
2233 checked for illegal return statements \see{returnStatementsChecker}.
2235 After the binding keys of the assignees are collected, the checker searches the
2236 part of the enclosing method that is after the selection for references whose
2237 binding keys are among the the collected keys. If more than one unique referral
2238 is found, or only one referral is found, but the selection also contains a
2239 return statement, we have a situation with an ambiguous return value, and an
2240 exception is thrown.
2242 %\todoin{Explain why we do not need to consider variables assigned inside
2243 %local/anonymous classes. (The referenced variables need to be final and so
2246 \subsection{The IllegalStatementsChecker}
2247 This checker is designed to check for illegal statements.
2249 Any use of the \var{super} keyword is prohibited, since its meaning is altered
2250 when moving a method to another class.
2252 For a \emph{break} statement, there is two situations to consider: A break
2253 statement with or without a label. If the break statement has a label, it is
2254 checked that whole of the labeled statement is inside the selection. Since a
2255 label does not have any binding information, we have to search upwards in the
2256 AST to find the \type{LabeledStatement} that corresponds to the label from the
2257 break statement, and check that it is contained in the selection. If the break
2258 statement does not have a label attached to it, it is checked that its innermost
2259 enclosing loop or switch statement also is inside the selection.
2261 The situation for a \emph{continue} statement is the same as for a break
2262 statement, except that it is not allowed inside switch statements.
2264 Regarding \emph{assignments}, two types of assignments is allowed: Assignment to
2265 a non-final variable and assignment to an array access. All other assignments is
2268 \todoin{Finish\ldots}
2270 \chapter{Eclipse Bugs Found}
2271 \todoin{Add other things and change headline?}
2273 \section{Eclipse bug 420726: Code is broken when moving a method that is
2274 assigning to the parameter that is also the move
2275 destination}\label{eclipse_bug_420726}
2276 This bug\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=420726}}
2277 was found when analyzing what kinds of names that was to be considered as
2278 \emph{unfixes} \see{unfixes}.
2280 \subsection{The bug}
2281 The bug emerges when trying to move a method from one class to another, and when
2282 the target for the move (must be a variable, local or field) is both a parameter
2283 variable and also is assigned to within the method body. Eclipse allows this to
2284 happen, although it is the sure path to a compilation error. This is because we
2285 would then have an assignment to a \var{this} expression, which is not allowed
2288 \subsection{The solution}
2289 The solution to this problem is to add all simple names that are assigned to in
2290 a method body to the set of unfixes.
2292 \section{Eclipse bug 429416: IAE when moving method from anonymous class}
2294 discovered\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429416}}
2295 this bug during a batch change on the \type{org.eclipse.jdt.ui} project.
2297 \subsection{The bug}
2298 This bug surfaces when trying to use the Move Method refactoring to move a
2299 method from an anonymous class to another class. This happens both for my
2300 simulation as well as in Eclipse, through the user interface. It only occurs
2301 when Eclipse analyzes the program and finds it necessary to pass an instance of
2302 the originating class as a parameter to the moved method. I.e. it want to pass a
2303 \var{this} expression. The execution ends in an
2304 \typewithref{java.lang}{IllegalArgumentException} in
2305 \typewithref{org.eclipse.jdt.core.dom}{SimpleName} and its
2306 \method{setIdentifier(String)} method. The simple name is attempted created in
2308 \methodwithref{org.eclipse.jdt.internal.corext.refactoring.structure.\\MoveInstanceMethodProcessor}{createInlinedMethodInvocation}
2309 so the \type{MoveInstanceMethodProcessor} was early a clear suspect.
2311 The \method{createInlinedMethodInvocation} is the method that creates a method
2312 invocation where the previous invocation to the method that was moved was. From
2313 its code it can be read that when a \var{this} expression is going to be passed
2314 in to the invocation, it shall be qualified with the name of the original
2315 method's declaring class, if the declaring class is either an anonymous clas or
2316 a member class. The problem with this, is that an anonymous class does not have
2317 a name, hence the term \emph{anonymous} class! Therefore, when its name, an
2318 empty string, is passed into
2319 \methodwithref{org.eclipse.jdt.core.dom.AST}{newSimpleName} it all ends in an
2320 \type{IllegalArgumentException}.
2322 \subsection{How I solved the problem}
2323 Since the \type{MoveInstanceMethodProcessor} is instantiated in the
2324 \typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethod\-RefactoringExecutor},
2325 and only need to be a
2326 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveProcessor}, I
2327 was able to copy the code for the original move processor and modify it so that
2328 it works better for me. It is now called
2329 \typewithref{no.uio.ifi.refaktor.refactorings.processors}{ModifiedMoveInstanceMethodProcessor}.
2330 The only modification done (in addition to some imports and suppression of
2331 warnings), is in the \method{createInlinedMethodInvocation}. When the declaring
2332 class of the method to move is anonymous, the \var{this} expression in the
2333 parameter list is not qualified with the declaring class' (empty) name.
2335 \section{Eclipse bug 429954: Extracting statement with reference to local type
2336 breaks code}\label{eclipse_bug_429954}
2337 The bug\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429954}}
2338 was discovered when doing some changes to the way unfixes is computed.
2340 \subsection{The bug}
2341 The problem is that Eclipse is allowing selections that references variables of
2342 local types to be extracted. When this happens the code is broken, since the
2343 extracted method must take a parameter of a local type that is not in the
2344 methods scope. The problem is illustrated in
2345 \myref{lst:extractMethod_LocalClass}, but there in another setting.
2347 \subsection{Actions taken}
2348 There are no actions directly springing out of this bug, since the Extract
2349 Method refactoring cannot be meant to be this way. This is handled on the
2350 analysis stage of our Extract and Move Method refactoring. So names representing
2351 variables of local types is considered unfixes \see{unfixes}.
2352 \todoin{write more when fixing this in legal statements checker}
2354 \chapter{Related Work}
2356 \section{The compositional paradigm of refactoring}
2357 This paradigm builds upon the observation of Vakilian et
2358 al.\citing{vakilian2012}, that of the many automated refactorings existing in
2359 modern IDEs, the simplest ones are dominating the usage statistics. The report
2360 mainly focuses on \emph{Eclipse} as the tool under investigation.
2362 The paradigm is described almost as the opposite of automated composition of
2363 refactorings \see{compositeRefactorings}. It works by providing the programmer
2364 with easily accessible primitive refactorings. These refactorings shall be
2365 accessed via keyboard shortcuts or quick-assist menus\footnote{Think
2366 quick-assist with Ctrl+1 in Eclipse} and be promptly executed, opposed to in the
2367 currently dominating wizard-based refactoring paradigm. They are ment to
2368 stimulate composing smaller refactorings into more complex changes, rather than
2369 doing a large upfront configuration of a wizard-based refactoring, before
2370 previewing and executing it. The compositional paradigm of refactoring is
2371 supposed to give control back to the programmer, by supporting \himher with an
2372 option of performing small rapid changes instead of large changes with a lesser
2373 degree of control. The report authors hope this will lead to fewer unsuccessful
2374 refactorings. It also could lower the bar for understanding the steps of a
2375 larger composite refactoring and thus also help in figuring out what goes wrong
2376 if one should choose to op in on a wizard-based refactoring.
2378 Vakilian and his associates have performed a survey of the effectiveness of the
2379 compositional paradigm versus the wizard-based one. They claim to have found
2380 evidence of that the \emph{compositional paradigm} outperforms the
2381 \emph{wizard-based}. It does so by reducing automation, which seem
2382 counterintuitive. Therefore they ask the question ``What is an appropriate level
2383 of automation?'', and thus questions what they feel is a rush toward more
2384 automation in the software engineering community.