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
8 \usepackage{babel,textcomp,csquotes,ifimasterforside,varioref}
9 \usepackage[hidelinks]{hyperref}
11 \usepackage[style=numeric-comp,backend=bibtex]{biblatex}
14 % use 'disable' before printing:
15 \usepackage[]{todonotes}
22 \usepackage{perpage} %the perpage package
23 \MakePerPage{footnote} %the perpage package command
25 \theoremstyle{definition}
26 \newtheorem*{wordDef}{Definition}
28 \graphicspath{ {./figures/} }
30 \newcommand{\citing}[1]{~\cite{#1}}
31 \newcommand{\myref}[1]{\cref{#1} on \cpageref{#1}}
33 \newcommand{\definition}[1]{\begin{wordDef}#1\end{wordDef}}
34 \newcommand{\see}[1]{(see \myref{#1})}
35 \newcommand{\See}[1]{(See \myref{#1}.)}
36 \newcommand{\explanation}[3]{\noindent\textbf{\textit{#1}}\\*\emph{When:}
37 #2\\*\emph{How:} #3\\*[-7px]}
39 %\newcommand{\type}[1]{\lstinline{#1}}
40 \newcommand{\type}[1]{\texttt{\textbf{#1}}}
41 \newcommand{\typeref}[1]{\footnote{\type{#1}}}
42 \newcommand{\typewithref}[2]{\type{#2}\typeref{#1.#2}}
43 \newcommand{\method}[1]{\type{#1}}
44 \newcommand{\methodref}[2]{\footnote{\type{#1}\method{\##2()}}}
45 \newcommand{\methodwithref}[2]{\method{#2}\footnote{\type{#1}\method{\##2()}}}
46 \newcommand{\var}[1]{\type{#1}}
48 \newcommand{\refactoring}[1]{\emph{#1}}
49 \newcommand{\ExtractMethod}{\refactoring{Extract Method}\xspace}
50 \newcommand{\MoveMethod}{\refactoring{Move Method}\xspace}
51 \newcommand{\ExtractAndMoveMethod}{\refactoring{Extract and Move Method}\xspace}
53 \newcommand\todoin[2][]{\todo[inline, caption={2do}, #1]{
54 \begin{minipage}{\textwidth-4pt}#2\end{minipage}}}
58 \author{Erlend Kristiansen}
60 \bibliography{bibliography/master-thesis-erlenkr-bibliography}
68 \todoin{\textbf{Remove all todos (including list) before delivery/printing!!!
69 Can be done by removing ``draft'' from documentclass.}}
70 \todoin{Write abstract}
78 The discussions in this report must be seen in the context of object oriented
79 programming languages, and Java in particular, since that is the language in
80 which most of the examples will be given. All though the techniques discussed
81 may be applicable to languages from other paradigms, they will not be the
82 subject of this report.
86 \chapter{What is Refactoring?}
88 This question is best answered by first defining the concept of a
89 \emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects
90 of programming make people want to refactor their code.
92 \section{Defining refactoring}
93 Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a
94 refactoring like this:
97 \emph{Refactoring} (noun): a change made to the internal
98 structure\footnote{The structure observable by the programmer.} of software to
99 make it easier to understand and cheaper to modify without changing its
100 observable behavior.~\cite[p.~53]{refactoring}
103 \noindent This definition assigns additional meaning to the word
104 \emph{refactoring}, beyond the composition of the prefix \emph{re-}, usually
105 meaning something like ``again'' or ``anew'', and the word \emph{factoring},
106 that can mean to isolate the \emph{factors} of something. Here a \emph{factor}
107 would be close to the mathematical definition of something that divides a
108 quantity, without leaving a remainder. Fowler is mixing the \emph{motivation}
109 behind refactoring into his definition. Instead it could be more refined, formed
110 to only consider the \emph{mechanical} and \emph{behavioral} aspects of
111 refactoring. That is to factor the program again, putting it together in a
112 different way than before, while preserving the behavior of the program. An
113 alternative definition could then be:
115 \definition{A \emph{refactoring} is a transformation
116 done to a program without altering its external behavior.}
118 From this we can conclude that a refactoring primarily changes how the
119 \emph{code} of a program is perceived by the \emph{programmer}, and not the
120 \emph{behavior} experienced by any user of the program. Although the logical
121 meaning is preserved, such changes could potentially alter the program's
122 behavior when it comes to performance gain or -penalties. So any logic depending
123 on the performance of a program could make the program behave differently after
126 In the extreme case one could argue that such a thing as \emph{software
127 obfuscation} is refactoring. Software obfuscation is to make source code harder
128 to read and analyze, while preserving its semantics. It could be done composing
129 many, more or less randomly chosen, refactorings. Then the question arise
130 whether it can be called a \emph{composite refactoring}
131 \see{compositeRefactorings} or not? The answer is not obvious. First, there is
132 no way to describe \emph{the} mechanics of software obfuscation, beacause there
133 are infinitely many ways to do that. Second, \emph{obfuscation} can be thought
134 of as \emph{one operation}: Either the code is obfuscated, or it is not. Third,
135 it makes no sense to call software obfuscation \emph{a} refactoring, since it
136 holds different meaning to different people. The last point is important, since
137 one of the motivations behind defining different refactorings is to build up a
138 vocabulary for software professionals to reason and discuss about programs,
139 similar to the motivation behind design patterns\citing{designPatterns}. So for
140 describing \emph{software obfuscation}, it might be more appropriate to define
141 what you do when performing it rather than precisely defining its mechanics in
142 terms of other refactorings.
144 \section{The etymology of 'refactoring'}
145 It is a little difficult to pinpoint the exact origin of the word
146 ``refactoring'', as it seems to have evolved as part of a colloquial
147 terminology, more than a scientific term. There is no authoritative source for a
148 formal definition of it.
150 According to Martin Fowler\citing{etymology-refactoring}, there may also be more
151 than one origin of the word. The most well-known source, when it comes to the
152 origin of \emph{refactoring}, is the Smalltalk\footnote{\emph{Smalltalk},
153 object-oriented, dynamically typed, reflective programming language. See
154 \url{http://www.smalltalk.org}} community and their infamous \emph{Refactoring
155 Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}}
156 described in the article \emph{A Refactoring Tool for
157 Smalltalk}\citing{refactoringBrowser1997}, published in 1997.
158 Allegedly\citing{etymology-refactoring}, the metaphor of factoring programs was
159 also present in the Forth\footnote{\emph{Forth} -- stack-based, extensible
160 programming language, without type-checking. See \url{http://www.forth.org}}
161 community, and the word ``refactoring'' is mentioned in a book by Leo Brodie,
162 called \emph{Thinking Forth}\citing{brodie1984}, first published in
163 1984\footnote{\emph{Thinking Forth} was first published in 1984 by the
164 \emph{Forth Interest Group}. Then it was reprinted in 1994 with minor
165 typographical corrections, before it was transcribed into an electronic edition
166 typeset in \LaTeX\ and published under a Creative Commons licence in 2004. The
167 edition cited here is the 2004 edition, but the content should essentially be as
168 in 1984.}. The exact word is only printed one place~\cite[p.~232]{brodie1984},
169 but the term \emph{factoring} is prominent in the book, that also contains a
170 whole chapter dedicated to (re)factoring, and how to keep the (Forth) code clean
174 \ldots good factoring technique is perhaps the most important skill for a
175 Forth programmer.~\cite[p.~172]{brodie1984}
178 \noindent Brodie also express what \emph{factoring} means to him:
181 Factoring means organizing code into useful fragments. To make a fragment
182 useful, you often must separate reusable parts from non-reusable parts. The
183 reusable parts become new definitions. The non-reusable parts become arguments
184 or parameters to the definitions.~\cite[p.~172]{brodie1984}
187 Fowler claims that the usage of the word \emph{refactoring} did not pass between
188 the \emph{Forth} and \emph{Smalltalk} communities, but that it emerged
189 independently in each of the communities.
191 \section{Motivation -- Why people refactor}
192 There are many reasons why people want to refactor their programs. They can for
193 instance do it to remove duplication, break up long methods or to introduce
194 design patterns\citing{designPatterns} into their software systems. The shared
195 trait for all these are that peoples intentions are to make their programs
196 \emph{better}, in some sense. But what aspects of their programs are becoming
199 As already mentioned, people often refactor to get rid of duplication. Moving
200 identical or similar code into methods, and maybe pushing methods up or down in
201 their class hierarchies. Making template methods for overlapping
202 algorithms/functionality and so on. It is all about gathering what belongs
203 together and putting it all in one place. The resulting code is then easier to
204 maintain. When removing the implicit coupling\footnote{When duplicating code,
205 the code might not be coupled in other ways than that it is supposed to
206 represent the same functionality. So if this functionality is going to change,
207 it might need to change in more than one place, thus creating an implicit
208 coupling between the multiple pieces of code.} between code snippets, the
209 location of a bug is limited to only one place, and new functionality need only
210 to be added to this one place, instead of a number of places people might not
213 A problem you often encounter when programming, is that a program contains a lot
214 of long and hard-to-grasp methods. It can then help to break the methods into
215 smaller ones, using the \ExtractMethod refactoring\citing{refactoring}. Then you
216 may discover something about a program that you were not aware of before;
217 revealing bugs you did not know about or could not find due to the complex
218 structure of your program. \todo{Proof?} Making the methods smaller and giving
219 good names to the new ones clarifies the algorithms and enhances the
220 \emph{understandability} of the program \see{magic_number_seven}. This makes
221 refactoring an excellent method for exploring unknown program code, or code that
222 you had forgotten that you wrote.
224 Most primitive refactorings are simple. Their true power is first revealed when
225 they are combined into larger --- higher level --- refactorings, called
226 \emph{composite refactorings} \see{compositeRefactorings}. Often the goal of
227 such a series of refactorings is a design pattern. Thus the \emph{design} can be
228 evolved throughout the lifetime of a program, as opposed to designing up-front.
229 It is all about being structured and taking small steps to improve a program's
232 Many software design pattern are aimed at lowering the coupling between
233 different classes and different layers of logic. One of the most famous is
234 perhaps the \emph{Model-View-Controller}\citing{designPatterns} pattern. It is
235 aimed at lowering the coupling between the user interface and the business logic
236 and data representation of a program. This also has the added benefit that the
237 business logic could much easier be the target of automated tests, increasing
238 the productivity in the software development process. Refactoring is an
239 important tool on the way to something greater.
241 Another effect of refactoring is that with the increased separation of concerns
242 coming out of many refactorings, the \emph{performance} can be improved. When
243 profiling programs, the problematic parts are narrowed down to smaller parts of
244 the code, which are easier to tune, and optimization can be performed only where
245 needed and in a more effective way.
247 Last, but not least, and this should probably be the best reason to refactor, is
248 to refactor to \emph{facilitate a program change}. If one has managed to keep
249 one's code clean and tidy, and the code is not bloated with design patterns that
250 are not ever going to be needed, then some refactoring might be needed to
251 introduce a design pattern that is appropriate for the change that is going to
254 Refactoring program code --- with a goal in mind --- can give the code itself
255 more value. That is in the form of robustness to bugs, understandability and
256 maintainability. Having robust code is an obvious advantage, but
257 understandability and maintainability are both very important aspects of
258 software development. By incorporating refactoring in the development process,
259 bugs are found faster, new functionality is added more easily and code is easier
260 to understand by the next person exposed to it, which might as well be the
261 person who wrote it. The consequence of this, is that refactoring can increase
262 the average productivity of the development process, and thus also add to the
263 monetary value of a business in the long run. The perspective on productivity
264 and money should also be able to open the eyes of the many nearsighted managers
265 that seldom see beyond the next milestone.
267 \section{The magical number seven}\label{magic_number_seven}
268 The article \emph{The magical number seven, plus or minus two: some limits on
269 our capacity for processing information}\citing{miller1956} by George A.
270 Miller, was published in the journal \emph{Psychological Review} in 1956. It
271 presents evidence that support that the capacity of the number of objects a
272 human being can hold in its working memory is roughly seven, plus or minus two
273 objects. This number varies a bit depending on the nature and complexity of the
274 objects, but is according to Miller ``\ldots never changing so much as to be
277 Miller's article culminates in the section called \emph{Recoding}, a term he
278 borrows from communication theory. The central result in this section is that by
279 recoding information, the capacity of the amount of information that a human can
280 process at a time is increased. By \emph{recoding}, Miller means to group
281 objects together in chunks and give each chunk a new name that it can be
282 remembered by. By organizing objects into patterns of ever growing depth, one
283 can memorize and process a much larger amount of data than if it were to be
284 represented as its basic pieces. This grouping and renaming is analogous to how
285 many refactorings work, by grouping pieces of code and give them a new name.
286 Examples are the fundamental \ExtractMethod and \refactoring{Extract Class}
287 refactorings\citing{refactoring}.
290 \ldots recoding is an extremely powerful weapon for increasing the amount of
291 information that we can deal with.~\cite[p.~95]{miller1956}
294 An example from the article addresses the problem of memorizing a sequence of
295 binary digits. Let us say we have the following sequence\footnote{The example
296 presented here is slightly modified (and shortened) from what is presented in
297 the original article\citing{miller1956}, but it is essentially the same.} of
298 16 binary digits: ``1010001001110011''. Most of us will have a hard time
299 memorizing this sequence by only reading it once or twice. Imagine if we instead
300 translate it to this sequence: ``A273''. If you have a background from computer
301 science, it will be obvious that the latest sequence is the first sequence
302 recoded to be represented by digits with base 16. Most people should be able to
303 memorize this last sequence by only looking at it once.
305 Another result from the Miller article is that when the amount of information a
306 human must interpret increases, it is crucial that the translation from one code
307 to another must be almost automatic for the subject to be able to remember the
308 translation, before \heshe is presented with new information to recode. Thus
309 learning and understanding how to best organize certain kinds of data is
310 essential to efficiently handle that kind of data in the future. This is much
311 like when humans learn to read. First they must learn how to recognize letters.
312 Then they can learn distinct words, and later read sequences of words that form
313 whole sentences. Eventually, most of them will be able to read whole books and
314 briefly retell the important parts of its content. This suggest that the use of
315 design patterns\citing{designPatterns} is a good idea when reasoning about
316 computer programs. With extensive use of design patterns when creating complex
317 program structures, one does not always have to read whole classes of code to
318 comprehend how they function, it may be sufficient to only see the name of a
319 class to almost fully understand its responsibilities.
322 Our language is tremendously useful for repackaging material into a few chunks
323 rich in information.~\cite[p.~95]{miller1956}
326 Without further evidence, these results at least indicate that refactoring
327 source code into smaller units with higher cohesion and, when needed,
328 introducing appropriate design patterns, should aid in the cause of creating
329 computer programs that are easier to maintain and has code that is easier (and
332 \section{Notable contributions to the refactoring literature}
333 \todoin{Update with more contributions}
336 \item[1992] William F. Opdyke submits his doctoral dissertation called
337 \emph{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This
338 work defines a set of refactorings, that are behavior preserving given that
339 their preconditions are met. The dissertation is focused on the automation
341 \item[1999] Martin Fowler et al.: \emph{Refactoring: Improving the Design of
342 Existing Code}\citing{refactoring}. This is maybe the most influential text
343 on refactoring. It bares similarities with Opdykes thesis\citing{opdyke1992}
344 in the way that it provides a catalog of refactorings. But Fowler's book is
345 more about the craft of refactoring, as he focuses on establishing a
346 vocabulary for refactoring, together with the mechanics of different
347 refactorings and when to perform them. His methodology is also founded on
348 the principles of test-driven development.
349 \item[2005] Joshua Kerievsky: \emph{Refactoring to
350 Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's
351 \emph{Refactoring}\citing{refactoring} and the ``Gang of Four'' \emph{Design
352 Patterns}\citing{designPatterns}. It is building on the refactoring
353 catalogue from Fowler's book, but is trying to bridge the gap between
354 \emph{refactoring} and \emph{design patterns} by providing a series of
355 higher-level composite refactorings, that makes code evolve toward or away
356 from certain design patterns. The book is trying to build up the readers
357 intuition around \emph{why} one would want to use a particular design
358 pattern, and not just \emph{how}. The book is encouraging evolutionary
359 design. \See{relationToDesignPatterns}
362 \section{Tool support (for Java)}\label{toolSupport}
363 This section will briefly compare the refatoring support of the three IDEs
364 \emph{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \emph{IntelliJ
365 IDEA}\footnote{The IDE under comparison is the \emph{Community Edition},
366 \url{http://www.jetbrains.com/idea/}} and
367 \emph{NetBeans}\footnote{\url{https://netbeans.org/}}. These are the most
368 popular Java IDEs\citing{javaReport2011}.
370 All three IDEs provide support for the most useful refactorings, like the
371 different extract, move and rename refactorings. In fact, Java-targeted IDEs are
372 known for their good refactoring support, so this did not appear as a big
375 The IDEs seem to have excellent support for the \ExtractMethod refactoring, so
376 at least they have all passed the first refactoring
377 rubicon\citing{fowlerRubicon2001,secondRubicon2012}.
379 Regarding the \MoveMethod refactoring, the \emph{Eclipse} and \emph{IntelliJ}
380 IDEs do the job in very similar manners. In most situations they both do a
381 satisfying job by producing the expected outcome. But they do nothing to check
382 that the result does not break the semantics of the program \see{correctness}.
383 The \emph{NetBeans} IDE implements this refactoring in a somewhat
384 unsophisticated way. For starters, its default destination for the move is
385 itself, although it refuses to perform the refactoring if chosen. But the worst
386 part is, that if moving the method \method{f} of the class \type{C} to the class
387 \type{X}, it will break the code. The result is shown in
388 \myref{lst:moveMethod_NetBeans}.
392 \begin{minted}[samepage]{java}
405 \begin{minted}[samepage]{java}
415 \caption{Moving method \method{f} from \type{C} to \type{X}.}
416 \label{lst:moveMethod_NetBeans}
419 NetBeans will try to make code that call the methods \method{m} and \method{n}
420 of \type{X} by accessing them through \var{c.x}, where \var{c} is a parameter of
421 type \type{C} that is added the method \method{f} when it is moved. (This is
422 seldom the desired outcome of this refactoring, but ironically, this ``feature''
423 keeps NetBeans from breaking the code in the example from \myref{correctness}.)
424 If \var{c.x} for some reason is inaccessible to \type{X}, as in this case, the
425 refactoring breaks the code, and it will not compile. NetBeans presents a
426 preview of the refactoring outcome, but the preview does not catch it if the IDE
427 is about break the program.
429 The IDEs under investigation seems to have fairly good support for primitive
430 refactorings, but what about more complex ones, such as the \refactoring{Extract
431 Class}\citing{refactoring}? The \refactoring{Extract Class} refactoring works by
432 creating a class, for then to move members to that class and access them from
433 the old class via a reference to the new class. \emph{IntelliJ} handles this in
434 a fairly good manner, although, in the case of private methods, it leaves unused
435 methods behind. These are methods that delegate to a field with the type of the
436 new class, but are not used anywhere. \emph{Eclipse} has added (or withdrawn)
437 its own quirk to the Extract Class refactoring, and only allows for
438 \emph{fields} to be moved to a new class, \emph{not methods}. This makes it
439 effectively only extracting a data structure, and calling it
440 \refactoring{Extract Class} is a little misleading. One would often be better
441 off with textual extract and paste than using the Extract Class refactoring in
442 Eclipse. When it comes to \emph{NetBeans}, it does not even seem to have made an
443 attempt on providing this refactoring. (Well, it probably has, but it does not
446 \todoin{Visual Studio (C++/C\#), Smalltalk refactoring browser?,
447 second refactoring rubicon?}
449 \section{The relation to design patterns}\label{relationToDesignPatterns}
451 \emph{Refactoring} and \emph{design patterns} have at least one thing in common,
452 they are both promoted by advocates of \emph{clean code}\citing{cleanCode} as
453 fundamental tools on the road to more maintanable and extendable source code.
456 Design patterns help you determine how to reorganize a design, and they can
457 reduce the amount of refactoring you need to do
458 later.~\cite[p.~353]{designPatterns}
461 Although sometimes associated with
462 over-engineering\citing{kerievsky2005,refactoring}, design patterns are in
463 general assumed to be good for maintainability of source code. That may be
464 because many of them are designed to support the \emph{open/closed principle} of
465 object-oriented programming. The principle was first formulated by Bertrand
466 Meyer, the creator of the Eiffel programming language, like this: ``Modules
467 should be both open and closed.''\citing{meyer1988} It has been popularized,
468 with this as a common version:
471 Software entities (classes, modules, functions, etc.) should be open for
472 extension, but closed for modification.\footnote{See
473 \url{http://c2.com/cgi/wiki?OpenClosedPrinciple} or
474 \url{https://en.wikipedia.org/wiki/Open/closed_principle}}
477 Maintainability is often thought of as the ability to be able to introduce new
478 functionality without having to change too much of the old code. When
479 refactoring, the motivation is often to facilitate adding new functionality. It
480 is about factoring the old code in a way that makes the new functionality being
481 able to benefit from the functionality already residing in a software system,
482 without having to copy old code into new. Then, next time someone shall add new
483 functionality, it is less likely that the old code has to change. Assuming that
484 a design pattern is the best way to get rid of duplication and assist in
485 implementing new functionality, it is reasonable to conclude that a design
486 pattern often is the target of a series of refactorings. Having a repertoire of
487 design patterns can also help in knowing when and how to refactor a program to
488 make it reflect certain desired characteristics.
491 There is a natural relation between patterns and refactorings. Patterns are
492 where you want to be; refactorings are ways to get there from somewhere
493 else.~\cite[p.~107]{refactoring}
496 This quote is wise in many contexts, but it is not always appropriate to say
497 ``Patterns are where you want to be\ldots''. \emph{Sometimes}, patterns are
498 where you want to be, but only because it will benefit your design. It is not
499 true that one should always try to incorporate as many design patterns as
500 possible into a program. It is not like they have intrinsic value. They only add
501 value to a system when they support its design. Otherwise, the use of design
502 patterns may only lead to a program that is more complex than necessary.
505 The overuse of patterns tends to result from being patterns happy. We are
506 \emph{patterns happy} when we become so enamored of patterns that we simply
507 must use them in our code.~\cite[p.~24]{kerievsky2005}
510 This can easily happen when relying largely on up-front design. Then it is
511 natural, in the very beginning, to try to build in all the flexibility that one
512 believes will be necessary throughout the lifetime of a software system.
513 According to Joshua Kerievsky ``That sounds reasonable --- if you happen to be
514 psychic.''~\cite[p.~1]{kerievsky2005} He is advocating what he believes is a
515 better approach: To let software continually evolve. To start with a simple
516 design that meets today's needs, and tackle future needs by refactoring to
517 satisfy them. He believes that this is a more economic approach than investing
518 time and money into a design that inevitably is going to change. By relying on
519 continuously refactoring a system, its design can be made simpler without
520 sacrificing flexibility. To be able to fully rely on this approach, it is of
521 utter importance to have a reliable suit of tests to lean on. \See{testing} This
522 makes the design process more natural and less characterized by difficult
523 decisions that has to be made before proceeding in the process, and that is
524 going to define a project for all of its unforeseeable future.
528 \section{Classification of refactorings}
529 % only interesting refactorings
530 % with 2 detailed examples? One for structured and one for intra-method?
531 % Is replacing Bubblesort with Quick Sort considered a refactoring?
533 \subsection{Structural refactorings}
535 \subsubsection{Primitive refactorings}
538 \explanation{Extract Method}{You have a code fragment that can be grouped
539 together.}{Turn the fragment into a method whose name explains the purpose of
542 \explanation{Inline Method}{A method's body is just as clear as its name.}{Put
543 the method's body into the body of its callers and remove the method.}
545 \explanation{Inline Temp}{You have a temp that is assigned to once with a simple
546 expression, and the temp is getting in the way of other refactorings.}{Replace
547 all references to that temp with the expression}
549 % Moving Features Between Objects
550 \explanation{Move Method}{A method is, or will be, using or used by more
551 features of another class than the class on which it is defined.}{Create a new
552 method with a similar body in the class it uses most. Either turn the old method
553 into a simple delegation, or remove it altogether.}
555 \explanation{Move Field}{A field is, or will be, used by another class more than
556 the class on which it is defined}{Create a new field in the target class, and
557 change all its users.}
560 \explanation{Replace Magic Number with Symbolic Constant}{You have a literal
561 number with a particular meaning.}{Create a constant, name it after the meaning,
562 and replace the number with it.}
564 \explanation{Encapsulate Field}{There is a public field.}{Make it private and
567 \explanation{Replace Type Code with Class}{A class has a numeric type code that
568 does not affect its behavior.}{Replace the number with a new class.}
570 \explanation{Replace Type Code with Subclasses}{You have an immutable type code
571 that affects the behavior of a class.}{Replace the type code with subclasses.}
573 \explanation{Replace Type Code with State/Strategy}{You have a type code that
574 affects the behavior of a class, but you cannot use subclassing.}{Replace the
575 type code with a state object.}
577 % Simplifying Conditional Expressions
578 \explanation{Consolidate Duplicate Conditional Fragments}{The same fragment of
579 code is in all branches of a conditional expression.}{Move it outside of the
582 \explanation{Remove Control Flag}{You have a variable that is acting as a
583 control flag fro a series of boolean expressions.}{Use a break or return
586 \explanation{Replace Nested Conditional with Guard Clauses}{A method has
587 conditional behavior that does not make clear the normal path of
588 execution.}{Use guard clauses for all special cases.}
590 \explanation{Introduce Null Object}{You have repeated checks for a null
591 value.}{Replace the null value with a null object.}
593 \explanation{Introduce Assertion}{A section of code assumes something about the
594 state of the program.}{Make the assumption explicit with an assertion.}
596 % Making Method Calls Simpler
597 \explanation{Rename Method}{The name of a method does not reveal its
598 purpose.}{Change the name of the method}
600 \explanation{Add Parameter}{A method needs more information from its
601 caller.}{Add a parameter for an object that can pass on this information.}
603 \explanation{Remove Parameter}{A parameter is no longer used by the method
606 %\explanation{Parameterize Method}{Several methods do similar things but with
607 %different values contained in the method.}{Create one method that uses a
608 %parameter for the different values.}
610 \explanation{Preserve Whole Object}{You are getting several values from an
611 object and passing these values as parameters in a method call.}{Send the whole
614 \explanation{Remove Setting Method}{A field should be set at creation time and
615 never altered.}{Remove any setting method for that field.}
617 \explanation{Hide Method}{A method is not used by any other class.}{Make the
620 \explanation{Replace Constructor with Factory Method}{You want to do more than
621 simple construction when you create an object}{Replace the constructor with a
624 % Dealing with Generalization
625 \explanation{Pull Up Field}{Two subclasses have the same field.}{Move the field
628 \explanation{Pull Up Method}{You have methods with identical results on
629 subclasses.}{Move them to the superclass.}
631 \explanation{Push Down Method}{Behavior on a superclass is relevant only for
632 some of its subclasses.}{Move it to those subclasses.}
634 \explanation{Push Down Field}{A field is used only by some subclasses.}{Move the
635 field to those subclasses}
637 \explanation{Extract Interface}{Several clients use the same subset of a class's
638 interface, or two classes have part of their interfaces in common.}{Extract the
639 subset into an interface.}
641 \explanation{Replace Inheritance with Delegation}{A subclass uses only part of a
642 superclasses interface or does not want to inherit data.}{Create a field for the
643 superclass, adjust methods to delegate to the superclass, and remove the
646 \explanation{Replace Delegation with Inheritance}{You're using delegation and
647 are often writing many simple delegations for the entire interface}{Make the
648 delegating class a subclass of the delegate.}
650 \subsubsection{Composite refactorings}
653 % \explanation{Replace Method with Method Object}{}{}
655 % Moving Features Between Objects
656 \explanation{Extract Class}{You have one class doing work that should be done by
657 two}{Create a new class and move the relevant fields and methods from the old
658 class into the new class.}
660 \explanation{Inline Class}{A class isn't doing very much.}{Move all its features
661 into another class and delete it.}
663 \explanation{Hide Delegate}{A client is calling a delegate class of an
664 object.}{Create Methods on the server to hide the delegate.}
666 \explanation{Remove Middle Man}{A class is doing to much simple delegation.}{Get
667 the client to call the delegate directly.}
670 \explanation{Replace Data Value with Object}{You have a data item that needs
671 additional data or behavior.}{Turn the data item into an object.}
673 \explanation{Change Value to Reference}{You have a class with many equal
674 instances that you want to replace with a single object.}{Turn the object into a
677 \explanation{Encapsulate Collection}{A method returns a collection}{Make it
678 return a read-only view and provide add/remove methods.}
680 % \explanation{Replace Array with Object}{}{}
682 \explanation{Replace Subclass with Fields}{You have subclasses that vary only in
683 methods that return constant data.}{Change the methods to superclass fields and
684 eliminate the subclasses.}
686 % Simplifying Conditional Expressions
687 \explanation{Decompose Conditional}{You have a complicated conditional
688 (if-then-else) statement.}{Extract methods from the condition, then part, an
691 \explanation{Consolidate Conditional Expression}{You have a sequence of
692 conditional tests with the same result.}{Combine them into a single conditional
693 expression and extract it.}
695 \explanation{Replace Conditional with Polymorphism}{You have a conditional that
696 chooses different behavior depending on the type of an object.}{Move each leg
697 of the conditional to an overriding method in a subclass. Make the original
700 % Making Method Calls Simpler
701 \explanation{Replace Parameter with Method}{An object invokes a method, then
702 passes the result as a parameter for a method. The receiver can also invoke this
703 method.}{Remove the parameter and let the receiver invoke the method.}
705 \explanation{Introduce Parameter Object}{You have a group of parameters that
706 naturally go together.}{Replace them with an object.}
708 % Dealing with Generalization
709 \explanation{Extract Subclass}{A class has features that are used only in some
710 instances.}{Create a subclass for that subset of features.}
712 \explanation{Extract Superclass}{You have two classes with similar
713 features.}{Create a superclass and move the common features to the
716 \explanation{Collapse Hierarchy}{A superclass and subclass are not very
717 different.}{Merge them together.}
719 \explanation{Form Template Method}{You have two methods in subclasses that
720 perform similar steps in the same order, yet the steps are different.}{Get the
721 steps into methods with the same signature, so that the original methods become
722 the same. Then you can pull them up.}
725 \subsection{Functional refactorings}
727 \explanation{Substitute Algorithm}{You want to replace an algorithm with one
728 that is clearer.}{Replace the body of the method with the new algorithm.}
732 \section{The impact on software quality}
734 \subsection{What is software quality?}
735 The term \emph{software quality} has many meanings. It all depends on the
736 context we put it in. If we look at it with the eyes of a software developer, it
737 usually means that the software is easily maintainable and testable, or in other
738 words, that it is \emph{well designed}. This often correlates with the
739 management scale, where \emph{keeping the schedule} and \emph{customer
740 satisfaction} is at the center. From the customers point of view, in addition to
741 good usability, \emph{performance} and \emph{lack of bugs} is always
742 appreciated, measurements that are also shared by the software developer. (In
743 addition, such things as good documentation could be measured, but this is out
744 of the scope of this document.)
746 \subsection{The impact on performance}
748 Refactoring certainly will make software go more slowly\footnote{With todays
749 compiler optimization techniques and performance tuning of e.g. the Java
750 virtual machine, the penalties of object creation and method calls are
751 debatable.}, but it also makes the software more amenable to performance
752 tuning.~\cite[p.~69]{refactoring}
755 \noindent There is a common belief that refactoring compromises performance, due
756 to increased degree of indirection and that polymorphism is slower than
759 In a survey, Demeyer\citing{demeyer2002} disproves this view in the case of
760 polymorphism. He did an experiment on, what he calls, ``Transform Self Type
761 Checks'' where you introduce a new polymorphic method and a new class hierarchy
762 to get rid of a class' type checking of a ``type attribute``. He uses this kind
763 of transformation to represent other ways of replacing conditionals with
764 polymorphism as well. The experiment is performed on the C++ programming
765 language and with three different compilers and platforms. Demeyer concludes
766 that, with compiler optimization turned on, polymorphism beats middle to large
767 sized if-statements and does as well as case-statements. (In accordance with
768 his hypothesis, due to similarities between the way C++ handles polymorphism and
772 The interesting thing about performance is that if you analyze most programs,
773 you find that they waste most of their time in a small fraction of the
774 code.~\cite[p.~70]{refactoring}
777 \noindent So, although an increased amount of method calls could potentially
778 slow down programs, one should avoid premature optimization and sacrificing good
779 design, leaving the performance tuning until after profiling\footnote{For and
780 example of a Java profiler, check out VisualVM:
781 \url{http://visualvm.java.net/}} the software and having isolated the actual
784 \section{Composite refactorings}\label{compositeRefactorings}
785 \todo{motivation, examples, manual vs automated?, what about refactoring in a
786 very large code base?}
787 Generally, when thinking about refactoring, at the mechanical level, there are
788 essentially two kinds of refactorings. There are the \emph{primitive}
789 refactorings, and the \emph{composite} refactorings.
791 \definition{A \emph{primitive refactoring} is a refactoring that cannot be
792 expressed in terms of other refactorings.}
794 \noindent Examples are the \refactoring{Pull Up Field} and \refactoring{Pull Up
795 Method} refactorings\citing{refactoring}, that move members up in their class
798 \definition{A \emph{composite refactoring} is a refactoring that can be
799 expressed in terms of two or more other refactorings.}
801 \noindent An example of a composite refactoring is the \refactoring{Extract
802 Superclass} refactoring\citing{refactoring}. In its simplest form, it is composed
803 of the previously described primitive refactorings, in addition to the
804 \refactoring{Pull Up Constructor Body} refactoring\citing{refactoring}. It works
805 by creating an abstract superclass that the target class(es) inherits from, then
806 by applying \refactoring{Pull Up Field}, \refactoring{Pull Up Method} and
807 \refactoring{Pull Up Constructor Body} on the members that are to be members of
808 the new superclass. For an overview of the \refactoring{Extract Superclass}
809 refactoring, see \myref{fig:extractSuperclass}.
813 \includegraphics[angle=270,width=\linewidth]{extractSuperclassItalic.pdf}
814 \caption{The Extract Superclass refactoring}
815 \label{fig:extractSuperclass}
818 \section{Manual vs. automated refactorings}
819 Refactoring is something every programmer does, even if \heshe does not known
820 the term \emph{refactoring}. Every refinement of source code that does not alter
821 the program's behavior is a refactoring. For small refactorings, such as
822 \ExtractMethod, executing it manually is a manageable task, but is still prone
823 to errors. Getting it right the first time is not easy, considering the method
824 signature and all the other aspects of the refactoring that has to be in place.
826 Take for instance the renaming of classes, methods and fields. For complex
827 programs these refactorings are almost impossible to get right. Attacking them
828 with textual search and replace, or even regular expressions, will fall short on
829 these tasks. Then it is crucial to have proper tool support that can perform
830 them automatically. Tools that can parse source code and thus have semantic
831 knowledge about which occurrences of which names belong to what construct in the
832 program. For even trying to perform one of these complex task manually, one
833 would have to be very confident on the existing test suite \see{testing}.
835 \section{Correctness of refactorings}\label{correctness}
836 For automated refactorings to be truly useful, they must show a high degree of
837 behavior preservation. This last sentence might seem obvious, but there are
838 examples of refactorings in existing tools that break programs. I will now
839 present an example of an \ExtractMethod refactoring followed by a \MoveMethod
840 refactoring that breaks a program in both the \emph{Eclipse} and \emph{IntelliJ}
841 IDEs\footnote{The NetBeans IDE handles this particular situation without
842 altering ther program's beavior, mainly because its Move Method refactoring
843 implementation is a bit rancid in other ways \see{toolSupport}.}. The
844 following piece of code shows the target for the composed refactoring:
846 \begin{minted}[linenos,samepage]{java}
848 public X x = new X();
857 \noindent The next piece of code shows the destination of the refactoring. Note
858 that the method \method{m(C c)} of class \type{C} assigns to the field \var{x}
859 of the argument \var{c} that has type \type{C}:
861 \begin{minted}[samepage]{java}
870 The refactoring sequence works by extracting line 5 and 6 from the original
871 class \type{C} into a method \method{f} with the statements from those lines as
872 its method body. The method is then moved to the class \type{X}. The result is
873 shown in the following two pieces of code:
875 \begin{minted}[linenos,samepage]{java}
877 public X x = new X();
885 \begin{minted}[linenos,samepage]{java}
898 After the refactoring, the method \method{f} of class \type{C} is calling the
899 method \method{f} of class \type{X}, and the program now behaves different than
900 before. (See line 5 of the version of class \type{C} after the refactoring.)
901 Before the refactoring, the methods \method{m} and \method{n} of class \type{X}
902 are called on different object instances (see line 5 and 6 of the original class
903 \type{C}). After, they are called on the same object, and the statement on line
904 3 of class \type{X} (the version after the refactoring) no longer have any
905 effect in our example.
907 The bug introduced in the previous example is of such a nature\footnote{Caused
908 by aliasing. See \url{https://en.wikipedia.org/wiki/Aliasing_(computing)}}
909 that it is very difficult to spot if the refactored code is not covered by
910 tests. It does not generate compilation errors, and will thus only result in
911 a runtime error or corrupted data, which might be hard to detect.
913 \section{Refactoring and the importance of testing}\label{testing}
915 If you want to refactor, the essential precondition is having solid
916 tests.\citing{refactoring}
919 When refactoring, there are roughly three classes of errors that can be made.
920 The first class of errors are the ones that make the code unable to compile.
921 These \emph{compile-time} errors are of the nicer kind. They flash up at the
922 moment they are made (at least when using an IDE), and are usually easy to fix.
923 The second class are the \emph{runtime} errors. Although they take a bit longer
924 to surface, they usually manifest after some time in an illegal argument
925 exception, null pointer exception or similar during the program execution.
926 These kind of errors are a bit harder to handle, but at least they will show,
927 eventually. Then there are the \emph{behavior-changing} errors. These errors are
928 of the worst kind. They do not show up during compilation and they do not turn
929 on a blinking red light during runtime either. The program can seem to work
930 perfectly fine with them in play, but the business logic can be damaged in ways
931 that will only show up over time.
933 For discovering runtime errors and behavior changes when refactoring, it is
934 essential to have good test coverage. Testing in this context means writing
935 automated tests. Manual testing may have its uses, but when refactoring, it is
936 automated unit testing that dominate. For discovering behavior changes it is
937 especially important to have tests that cover potential problems, since these
938 kind of errors does not reveal themselves.
940 Unit testing is not a way to \emph{prove} that a program is correct, but it is a
941 way to make you confindent that it \emph{probably} works as desired. In the
942 context of test driven development (commonly known as TDD), the tests are even a
943 way to define how the program is \emph{supposed} to work. It is then, by
944 definition, working if the tests are passing.
946 If the test coverage for a code base is perfect, then it should, theoretically,
947 be risk-free to perform refactorings on it. This is why automated tests and
948 refactoring are such a great match.
950 \subsection{Testing the code from correctness section}
951 The worst thing that can happen when refactoring is to introduce changes to the
952 behavior of a program, as in the example on \myref{correctness}. This example
953 may be trivial, but the essence is clear. The only problem with the example is
954 that it is not clear how to create automated tests for it, without changing it
957 Unit tests, as they are known from the different xUnit frameworks around, are
958 only suitable to test the \emph{result} of isolated operations. They can not
959 easily (if at all) observe the \emph{history} of a program.
962 \todoin{Write \ldots}
964 Assuming a sequential (non-concurrent) program:
967 tracematch (C c, X x) {
969 call(* X.m(C)) && args(c) && cflow(within(C));
971 call(* X.n()) && target(x) && cflow(within(C));
973 set(C.x) && target(c) && !cflow(m);
981 %\begin{minted}{java}
982 %tracematch (X x1, X x2) {
984 % call(* X.m(C)) && target(x1);
986 % call(* X.n()) && target(x2);
988 % set(C.x) && !cflow(m) && !cflow(n);
992 % { assert x1 != x2; }
996 \section{The project}
997 The aim of this project will be to investigate the relationship between a
998 composite refactoring composed of the \ExtractMethod and \MoveMethod
999 refactorings, and its impact on one or more software metrics.
1001 The composition of \ExtractMethod and \MoveMethod springs naturally out of the
1002 need to move procedures closer to the data they manipulate. This composed
1003 refactoring is not well described in the literature, but it is implemented in at
1004 least one tool called
1005 \emph{CodeRush}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument3519}},
1006 that is an extension for \emph{MS Visual
1007 Studio}\footnote{\url{http://www.visualstudio.com/}}. In CodeRush it is called
1008 \emph{Extract Method to
1009 Type}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument6710}},
1010 but I choose to call it \ExtractAndMoveMethod, since I feel it better
1011 communicates which primitive refactorings it is composed of.
1013 For the metrics, I will at least measure the \emph{Coupling between object
1014 classes} (CBO) metric that is described by Chidamber and Kemerer in their
1015 article \emph{A Metrics Suite for Object Oriented
1016 Design}\citing{metricsSuite1994}.
1018 The project will then consist in implementing the \ExtractAndMoveMethod
1019 refactoring, as well as executing it over a larger code base. Then the effect of
1020 the change must be measured by calculating the chosen software metrics both
1021 before and after the execution. To be able to execute the refactoring
1022 automatically I have to make it analyze code to determine the best selections to
1023 extract into new methods.
1025 \section{Software metrics}
1026 \todoin{Is this the appropriate place to have this section?}
1029 %\chapter{Planning the project}
1037 \section{The problem statement}
1038 \section{Choosing the target language}
1039 Choosing which programming language to use as the target for manipulation is not
1040 a very difficult task. The language has to be an object-oriented programming
1041 language, and it must have existing tool support for refactoring. The
1042 \emph{Java} programming language\footnote{\url{https://www.java.com/}} is the
1043 dominating language when it comes to examples in the literature of refactoring,
1044 and is thus a natural choice. Java is perhaps, currently the most influential
1045 programming language in the world, with its \emph{Java Virtual Machine} that
1046 runs on all of the most popular architectures and also supports\footnote{They
1047 compile to java bytecode.} dozens of other programming languages, with
1048 \emph{Scala}, \emph{Clojure} and \emph{Groovy} as the most prominent ones. Java
1049 is currently the language that every other programming language is compared
1050 against. It is also the primary language of the author of this thesis.
1052 \section{Choosing the tools}
1053 When choosing a tool for manipulating Java, there are certain criterias that
1054 have to be met. First of all, the tool should have some existing refactoring
1055 support that this thesis can build upon. Secondly it should provide some kind of
1056 framework for parsing and analyzing Java source code. Third, it should itself be
1057 open source. This is both because of the need to be able to browse the code for
1058 the existing refactorings that is contained in the tool, and also because open
1059 source projects hold value in them selves. Another important aspect to consider
1060 is that open source projects of a certain size, usually has large communities of
1061 people connected to them, that are commited to answering questions regarding the
1062 use and misuse of the products, that to a large degree is made by the cummunity
1065 There is a certain class of tools that meet these criterias, namely the class of
1066 \emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
1067 proagrams that is ment to support the whole production cycle of a cumputer
1068 program, and the most popular IDEs that support Java, generally have quite good
1069 refactoring support.
1071 The main contenders for this thesis is the \emph{Eclipse IDE}, with the
1072 \emph{Java development tools} (JDT), the \emph{IntelliJ IDEA Community Edition}
1073 and the \emph{NetBeans IDE}. \See{toolSupport} Eclipse and NetBeans are both
1074 free, open source and community driven, while the IntelliJ IDEA has an open
1075 sourced community edition that is free of charge, but also offer an
1076 \emph{Ultimate Edition} with an extended set of features, at additional cost.
1077 All three IDEs supports adding plugins to extend their functionality and tools
1078 that can be used to parse and analyze Java source code. But one of the IDEs
1079 stand out as a favorite, and that is the \emph{Eclipse IDE}. This is the most
1080 popular\citing{javaReport2011} among them and seems to be de facto standard IDE
1081 for Java development regardless of platform.
1084 \chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful
1085 Thinking}\label{ch:jdt_refactorings}
1087 This chapter will deal with some of the design behind refactoring support in
1088 Eclipse, and the JDT in specific. After which it will follow a section about
1089 shortcomings of the refactoring API in terms of composition of refactorings. The
1090 chapter will be concluded with a section telling some of the ways the
1091 implementation of refactorings in the JDT could have worked to facilitate
1092 composition of refactorings.
1095 The refactoring world of Eclipse can in general be separated into two parts: The
1096 language independent part and the part written for a specific programming
1097 language -- the language that is the target of the supported refactorings.
1098 \todo{What about the language specific part?}
1100 \subsection{The Language Toolkit}
1101 The Language Toolkit, or LTK for short, is the framework that is used to
1102 implement refactorings in Eclipse. It is language independent and provides the
1103 abstractions of a refactoring and the change it generates, in the form of the
1104 classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} and
1105 \typewithref{org.eclipse.ltk.core.refactoring}{Change}. (There is also parts of
1106 the LTK that is concerned with user interaction, but they will not be discussed
1107 here, since they are of little value to us and our use of the framework.)
1109 \subsubsection{The Refactoring Class}
1110 The abstract class \type{Refactoring} is the core of the LTK framework. Every
1111 refactoring that is going to be supported by the LTK have to end up creating an
1112 instance of one of its subclasses. The main responsibilities of subclasses of
1113 \type{Refactoring} is to implement template methods for condition checking
1114 (\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkInitialConditions}
1116 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkFinalConditions}),
1118 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{createChange}
1119 method that creates and returns an instance of the \type{Change} class.
1121 If the refactoring shall support that others participate in it when it is
1122 executed, the refactoring has to be a processor-based
1123 refactoring\typeref{org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring}.
1124 It then delegates to its given
1125 \typewithref{org.eclipse.ltk.core.refactoring.participants}{RefactoringProcessor}
1126 for condition checking and change creation.
1128 \subsubsection{The Change Class}
1129 This class is the base class for objects that is responsible for performing the
1130 actual workspace transformations in a refactoring. The main responsibilities for
1131 its subclasses is to implement the
1132 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{perform} and
1133 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{isValid} methods. The
1134 \method{isValid} method verifies that the change object is valid and thus can be
1135 executed by calling its \method{perform} method. The \method{perform} method
1136 performs the desired change and returns an undo change that can be executed to
1137 reverse the effect of the transformation done by its originating change object.
1139 \subsubsection{Executing a Refactoring}\label{executing_refactoring}
1140 The life cycle of a refactoring generally follows two steps after creation:
1141 condition checking and change creation. By letting the refactoring object be
1143 \typewithref{org.eclipse.ltk.core.refactoring}{CheckConditionsOperation} that
1144 in turn is handled by a
1145 \typewithref{org.eclipse.ltk.core.refactoring}{CreateChangeOperation}, it is
1146 assured that the change creation process is managed in a proper manner.
1148 The actual execution of a change object has to follow a detailed life cycle.
1149 This life cycle is honored if the \type{CreateChangeOperation} is handled by a
1150 \typewithref{org.eclipse.ltk.core.refactoring}{PerformChangeOperation}. If also
1151 an undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} is set
1152 for the \type{PerformChangeOperation}, the undo change is added into the undo
1155 \section{Shortcomings}
1156 This section is introduced naturally with a conclusion: The JDT refactoring
1157 implementation does not facilitate composition of refactorings.
1158 \todo{refine}This section will try to explain why, and also identify other
1159 shortcomings of both the usability and the readability of the JDT refactoring
1162 I will begin at the end and work my way toward the composition part of this
1165 \subsection{Absence of Generics in Eclipse Source Code}
1166 This section is not only concerning the JDT refactoring API, but also large
1167 quantities of the Eclipse source code. The code shows a striking absence of the
1168 Java language feature of generics. It is hard to read a class' interface when
1169 methods return objects or takes parameters of raw types such as \type{List} or
1170 \type{Map}. This sometimes results in having to read a lot of source code to
1171 understand what is going on, instead of relying on the available interfaces. In
1172 addition, it results in a lot of ugly code, making the use of typecasting more
1173 of a rule than an exception.
1175 \subsection{Composite Refactorings Will Not Appear as Atomic Actions}
1177 \subsubsection{Missing Flexibility from JDT Refactorings}
1178 The JDT refactorings are not made with composition of refactorings in mind. When
1179 a JDT refactoring is executed, it assumes that all conditions for it to be
1180 applied successfully can be found by reading source files that has been
1181 persisted to disk. They can only operate on the actual source material, and not
1182 (in-memory) copies thereof. This constitutes a major disadvantage when trying to
1183 compose refactorings, since if an exception occur in the middle of a sequence of
1184 refactorings, it can leave the project in a state where the composite
1185 refactoring was executed only partly. It makes it hard to discard the changes
1186 done without monitoring and consulting the undo manager, an approach that is not
1189 \subsubsection{Broken Undo History}
1190 When designing a composed refactoring that is to be performed as a sequence of
1191 refactorings, you would like it to appear as a single change to the workspace.
1192 This implies that you would also like to be able to undo all the changes done by
1193 the refactoring in a single step. This is not the way it appears when a sequence
1194 of JDT refactorings is executed. It leaves the undo history filled up with
1195 individual undo actions corresponding to every single JDT refactoring in the
1196 sequence. This problem is not trivial to handle in Eclipse.
1197 \See{hacking_undo_history}
1199 \section{Wishful Thinking}
1202 \chapter{Composite Refactorings in Eclipse}
1204 \section{A Simple Ad Hoc Model}
1205 As pointed out in \myref{ch:jdt_refactorings}, the Eclipse JDT refactoring model
1206 is not very well suited for making composite refactorings. Therefore a simple
1207 model using changer objects (of type \type{RefaktorChanger}) is used as an
1208 abstraction layer on top of the existing Eclipse refactorings.
1210 \section{The Extract and Move Method Refactoring}
1211 %The Extract and Move Method Refactoring is implemented mainly using these
1214 % \item \type{ExtractAndMoveMethodChanger}
1215 % \item \type{ExtractAndMoveMethodPrefixesExtractor}
1216 % \item \type{Prefix}
1217 % \item \type{PrefixSet}
1220 \subsection{The Building Blocks}
1221 This is a composite refactoring, and hence is built up using several primitive
1222 refactorings. These basic building blocks are, as its name implies, the
1223 \ExtractMethod refactoring\citing{refactoring} and the \MoveMethod
1224 refactoring\citing{refactoring}. In Eclipse, the implementations of these
1225 refactorings are found in the classes
1226 \typewithref{org.eclipse.jdt.internal.corext.refactoring.code}{ExtractMethodRefactoring}
1228 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure}{MoveInstanceMethodProcessor},
1229 where the last class is designed to be used together with the processor-based
1230 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveRefactoring}.
1232 \subsubsection{The ExtractMethodRefactoring Class}
1233 This class is quite simple in its use. The only parameters it requires for
1234 construction is a compilation
1235 unit\typeref{org.eclipse.jdt.core.ICompilationUnit}, the offset into the source
1236 code where the extraction shall start, and the length of the source to be
1237 extracted. Then you have to set the method name for the new method together with
1238 which access modifier that shall be used and some not so interesting parameters.
1240 \subsubsection{The MoveInstanceMethodProcessor Class}
1241 For the Move Method the processor requires a little more advanced input than
1242 the class for the Extract Method. For construction it requires a method
1243 handle\typeref{org.eclipse.jdt.core.IMethod} from the Java Model for the method
1244 that is to be moved. Then the target for the move have to be supplied as the
1245 variable binding from a chosen variable declaration. In addition to this, one
1246 have to set some parameters regarding setters/getters and delegation.
1248 To make a whole refactoring from the processor, one have to construct a
1249 \type{MoveRefactoring} from it.
1251 \subsection{The ExtractAndMoveMethodChanger Class}
1252 The \typewithref{no.uio.ifi.refaktor.changers}{ExtractAndMoveMethodChanger}
1253 class, that is a subclass of the class
1254 \typewithref{no.uio.ifi.refaktor.changers}{RefaktorChanger}, is the class
1255 responsible for composing the \type{ExtractMethodRefactoring} and the
1256 \type{MoveRefactoring}. Its constructor takes a project
1257 handle\typeref{org.eclipse.core.resources.IProject}, the method name for the new
1258 method and a \typewithref{no.uio.ifi.refaktor.utils}{SmartTextSelection}.
1260 A \type{SmartTextSelection} is basically a text
1261 selection\typeref{org.eclipse.jface.text.ITextSelection} object that enforces
1262 the providing of the underlying document during creation. I.e. its
1263 \methodwithref{no.uio.ifi.refaktor.utils.SmartTextSelection}{getDocument} method
1264 will never return \type{null}.
1266 Before extracting the new method, the possible targets for the move operation is
1267 found with the help of an
1268 \typewithref{no.uio.ifi.refaktor.extractors}{ExtractAndMoveMethodPrefixesExtractor}.
1269 The possible targets is computed from the prefixes that the extractor returns
1271 \methodwithref{no.uio.ifi.refaktor.extractors.ExtractAndMoveMethodPrefixesExtractor}{getSafePrefixes}
1272 method. The changer then choose the most suitable target by finding the most
1273 frequent occurring prefix among the safe ones. The target is the type of the
1274 first part of the prefix.
1276 After finding a suitable target, the \type{ExtractAndMoveMethodChanger} first
1277 creates an \type{ExtractMethodRefactoring} and performs it as explained in
1278 \myref{executing_refactoring} about the execution of refactorings. Then it
1279 creates and performs the \type{MoveRefactoring} in the same way, based on the
1280 changes done by the Extract Method refactoring.
1282 \subsection{The ExtractAndMoveMethodPrefixesExtractor Class}
1283 This extractor extracts properties needed for building the Extract and Move
1284 Method refactoring. It searches through the given selection to find safe
1285 prefixes, and those prefixes form a base that can be used to compute possible
1286 targets for the move part of the refactoring. It finds both the candidates, in
1287 the form of prefixes, and the non-candidates, called unfixes. All prefixes (and
1288 unfixes) are represented by a
1289 \typewithref{no.uio.ifi.refaktor.extractors}{Prefix}, and they are collected
1290 into prefix sets.\typeref{no.uio.ifi.refaktor.extractors.PrefixSet}.
1292 The prefixes and unfixes are found by property
1293 collectors\typeref{no.uio.ifi.refaktor.extractors.collectors.PropertyCollector}.
1294 A property collector follows the visitor pattern\citing{designPatterns} and is
1295 of the \typewithref{org.eclipse.jdt.core.dom}{ASTVisitor} type. An
1296 \type{ASTVisitor} visits nodes in an abstract syntax tree that forms the Java
1297 document object model. The tree consists of nodes of type
1298 \typewithref{org.eclipse.jdt.core.do}{ASTNode}.
1300 \subsubsection{The PrefixesCollector}
1301 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{PrefixesCollector}
1302 is of type \type{PropertyCollector}. It visits expression
1303 statements\typeref{org.eclipse.jdt.core.dom.ExpressionStatement} and creates
1304 prefixes from its expressions in the case of method invocations. The prefixes
1305 found is registered with a prefix set, together with all its sub-prefixes.
1306 \todo{Rewrite in the case of changes to the way prefixes are found}
1308 \subsubsection{The UnfixesCollector}
1309 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{UnfixesCollector}
1310 finds unfixes within the selection. An unfix is a name that is assigned to
1311 within the selection. The reason that this cannot be allowed, is that the result
1312 would be an assignment to the \type{this} keyword, which is not valid in Java.
1314 \subsubsection{Computing Safe Prefixes}
1315 A safe prefix is a prefix that does not enclose an unfix. A prefix is enclosing
1316 an unfix if the unfix is in the set of its sub-prefixes. As an example,
1317 \texttt{``a.b''} is enclosing \texttt{``a''}, as is \texttt{``a''}. The safe
1318 prefixes is unified in a \type{PrefixSet} and can be fetched calling the
1319 \method{getSafePrefixes} method of the
1320 \type{ExtractAndMoveMethodPrefixesExtractor}.
1322 \subsection{The Prefix Class}
1324 \subsection{The PrefixSet Class}
1326 \subsection{Hacking the Refactoring Undo
1327 History}\label{hacking_undo_history}
1328 \todo{Where to put this section?}
1330 As an attempt to make multiple subsequent changes to the workspace appear as a
1331 single action (i.e. make the undo changes appear as such), I tried to alter
1332 the undo changes\typeref{org.eclipse.ltk.core.refactoring.Change} in the history
1333 of the refactorings.
1335 My first impulse was to remove the, in this case, last two undo changes from the
1336 undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} for the
1337 Eclipse refactorings, and then add them to a composite
1338 change\typeref{org.eclipse.ltk.core.refactoring.CompositeChange} that could be
1339 added back to the manager. The interface of the undo manager does not offer a
1340 way to remove/pop the last added undo change, so a possible solution could be to
1341 decorate\citing{designPatterns} the undo manager, to intercept and collect the
1342 undo changes before delegating to the \method{addUndo}
1343 method\methodref{org.eclipse.ltk.core.refactoring.IUndoManager}{addUndo} of the
1344 manager. Instead of giving it the intended undo change, a null change could be
1345 given to prevent it from making any changes if run. Then one could let the
1346 collected undo changes form a composite change to be added to the manager.
1348 There is a technical challenge with this approach, and it relates to the undo
1349 manager, and the concrete implementation
1350 UndoManager2\typeref{org.eclipse.ltk.internal.core.refactoring.UndoManager2}.
1351 This implementation is designed in a way that it is not possible to just add an
1352 undo change, you have to do it in the context of an active
1353 operation\typeref{org.eclipse.core.commands.operations.TriggeredOperations}.
1354 One could imagine that it might be possible to trick the undo manager into
1355 believing that you are doing a real change, by executing a refactoring that is
1356 returning a kind of null change that is returning our composite change of undo
1357 refactorings when it is performed.
1359 Apart from the technical problems with this solution, there is a functional
1360 problem: If it all had worked out as planned, this would leave the undo history
1361 in a dirty state, with multiple empty undo operations corresponding to each of
1362 the sequentially executed refactoring operations, followed by a composite undo
1363 change corresponding to an empty change of the workspace for rounding of our
1364 composite refactoring. The solution to this particular problem could be to
1365 intercept the registration of the intermediate changes in the undo manager, and
1366 only register the last empty change.
1368 Unfortunately, not everything works as desired with this solution. The grouping
1369 of the undo changes into the composite change does not make the undo operation
1370 appear as an atomic operation. The undo operation is still split up into
1371 separate undo actions, corresponding to the change done by its originating
1372 refactoring. And in addition, the undo actions has to be performed separate in
1373 all the editors involved. This makes it no solution at all, but a step toward
1376 There might be a solution to this problem, but it remains to be found. The
1377 design of the refactoring undo management is partly to be blamed for this, as it
1378 it is to complex to be easily manipulated.
1383 \chapter{Analyzing Code}
1386 \todoin{Explain what it is, or just how it is structured in Eclipse and how to
1389 \section{Illegal selections}
1391 \subsection{Not all branches end in return}
1393 \subsection{Ambiguous return statement}
1394 This problem occurs when there is either more than one assignment to a local
1395 variable that is used outside of the selection, or there is only one, but there
1396 are also return statements in the selection.
1398 \todoin{Explain why we do not need to consider variables assigned inside
1399 local/anonymous classes. (The referenced variables need to be final and so
1402 \chapter{Eclipse Bugs}
1403 \todoin{Add other things and change headline?}
1405 \section{Eclipse bug 420726: Code is broken when moving a method that is
1406 assigning to the parameter that is also the move destination}
1407 This bug\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=420726}}
1408 was found when analyzing what kinds of names that was to be considered as
1409 \emph{unfixes}.\todo{refer to unfixes}
1411 \subsection{The bug}
1412 The bug emerges when trying to move a method from one class to another, and when
1413 the target for the move (must be a variable, local or field) is both a parameter
1414 variable and also is assigned to within the method body. Eclipse allows this to
1415 happen, although it is the sure path to a compilation error. This is because we
1416 would then have an assignment to a \var{this} expression, which is not allowed
1419 \subsection{The solution}
1420 The solution to this problem is to add all simple names that are assigned to in
1421 a method body to the set of unfixes.
1423 \section{Eclipse bug 429416: IAE when moving method from anonymous class}
1425 discovered\footnote{\url{https://bugs.eclipse.org/bugs/show\_bug.cgi?id=429416}}
1426 this bug during a batch change on the \type{org.eclipse.jdt.ui} project.
1428 \subsection{The bug}
1429 This bug surfaces when trying to use the Move Method refactoring to move a
1430 method from an anonymous class to another class. This happens both for my
1431 simulation as well as in Eclipse, through the user interface. It only occurs
1432 when Eclipse analyses the program and finds it necessary to pass an instance of
1433 the originating class as a parameter to the moved method. I.e. it want to pass a
1434 \var{this} expression. The execution ends in an
1435 \typewithref{java.lang}{IllegalArgumentException} in
1436 \typewithref{org.eclipse.jdt.core.dom}{SimpleName} and its
1437 \method{setIdentifier(String)} method. The simple name is attempted created in
1439 \methodwithref{org.eclipse.jdt.internal.corext.refactoring.structure.\\MoveInstanceMethodProcessor}{createInlinedMethodInvocation}
1440 so the \type{MoveInstanceMethodProcessor} was early a clear suspect.
1442 The \method{createInlinedMethodInvocation} is the method that creates a method
1443 invocation where the previous invocation to the method that was moved was. From
1444 its code it can be read that when a \var{this} expression is going to be passed
1445 in to the invocation, it shall be qualified with the name of the original
1446 method's declaring class, if the declaring class is either an anonymous clas or
1447 a member class. The problem with this, is that an anonymous class does not have
1448 a name, hence the term \emph{anonymous} class! Therefore, when its name, an
1449 empty string, is passed into
1450 \methodwithref{org.eclipse.jdt.core.dom.AST}{newSimpleName} it all ends in an
1451 \type{IllegalArgumentException}.
1453 \subsection{How I solved the problem}
1454 Since the \type{MoveInstanceMethodProcessor} is instantiated in the
1455 \typewithref{no.uio.ifi.refaktor.change.executors}{MoveMethod\-RefactoringExecutor},
1456 and only need to be a
1457 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveProcessor}, I
1458 was able to copy the code for the original move processor and modify it so that
1459 it works better for me. It is now called
1460 \typewithref{no.uio.ifi.refaktor.refactorings.processors}{ModifiedMoveInstanceMethodProcessor}.
1461 The only modification done (in addition to some imports and suppression of
1462 warnings), is in the \method{createInlinedMethodInvocation}. When the declaring
1463 class of the method to move is anonymous, the \var{this} expression in the
1464 parameter list is not qualified with the declaring class' (empty) name.
1466 \chapter{Related Work}
1468 \section{The compositional paradigm of refactoring}
1469 This paradigm builds upon the observation of Vakilian et
1470 al.\citing{vakilian2012}, that of the many automated refactorings existing in
1471 modern IDEs, the simplest ones are dominating the usage statistics. The report
1472 mainly focuses on \emph{Eclipse} as the tool under investigation.
1474 The paradigm is described almost as the opposite of automated composition of
1475 refactorings \see{compositeRefactorings}. It works by providing the programmer
1476 with easily accessible primitive refactorings. These refactorings shall be
1477 accessed via keyboard shortcuts or quick-assist menus\footnote{Think
1478 quick-assist with Ctrl+1 in Eclipse} and be promptly executed, opposed to in the
1479 currently dominating wizard-based refactoring paradigm. They are ment to
1480 stimulate composing smaller refactorings into more complex changes, rather than
1481 doing a large upfront configuration of a wizard-based refactoring, before
1482 previewing and executing it. The compositional paradigm of refactoring is
1483 supposed to give control back to the programmer, by supporting \himher with an
1484 option of performing small rapid changes instead of large changes with a lesser
1485 degree of control. The report authors hope this will lead to fewer unsuccessful
1486 refactorings. It also could lower the bar for understanding the steps of a
1487 larger composite refactoring and thus also help in figuring out what goes wrong
1488 if one should choose to op in on a wizard-based refactoring.
1490 Vakilian and his associates have performed a survey of the effectiveness of the
1491 compositional paradigm versus the wizard-based one. They claim to have found
1492 evidence of that the \emph{compositional paradigm} outperforms the
1493 \emph{wizard-based}. It does so by reducing automation, which seem
1494 counterintuitive. Therefore they ask the question ``What is an appropriate level
1495 of automation?'', and thus questions what they feel is a rush toward more
1496 automation in the software engineering community.