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
7 \usepackage{babel,textcomp,csquotes,ifimasterforside,varioref,graphicx}
8 \usepackage[hidelinks]{hyperref}
10 \usepackage[style=numeric-comp,backend=bibtex]{biblatex}
12 \usepackage{todonotes}
19 \usepackage{perpage} %the perpage package
20 \MakePerPage{footnote} %the perpage package command
22 \theoremstyle{definition}
23 \newtheorem*{wordDef}{Definition}
25 \graphicspath{ {./figures/} }
27 \newcommand{\citing}[1]{~\cite{#1}}
28 \newcommand{\myref}[1]{\cref{#1} on \cpageref{#1}}
30 \newcommand{\definition}[1]{\begin{wordDef}#1\end{wordDef}}
31 \newcommand{\see}[1]{(see \myref{#1})}
32 \newcommand{\See}[1]{(See \myref{#1}.)}
33 \newcommand{\explanation}[3]{\noindent\textbf{\textit{#1}}\\*\emph{When:}
34 #2\\*\emph{How:} #3\\*[-7px]}
36 \newcommand{\type}[1]{\texttt{\textbf{#1}}}
37 \newcommand{\typeref}[1]{\footnote{\type{#1}}}
38 \newcommand{\typewithref}[2]{\type{#2}\typeref{#1.#2}}
39 \newcommand{\method}[1]{\type{#1}}
40 \newcommand{\methodref}[2]{\footnote{\type{#1}\method{\##2()}}}
41 \newcommand{\methodwithref}[2]{\method{#2}\footnote{\type{#1}\method{\##2()}}}
42 \newcommand{\var}[1]{\type{#1}}
44 \newcommand{\refactoring}[1]{\emph{#1}}
45 \newcommand{\ExtractMethod}{\refactoring{Extract Method}\xspace}
46 \newcommand{\MoveMethod}{\refactoring{Move Method}\xspace}
48 \newcommand\todoin[2][]{\todo[inline, caption={2do}, #1]{
49 \begin{minipage}{\textwidth-4pt}#2\end{minipage}}}
53 \author{Erlend Kristiansen}
55 \bibliography{bibliography/master-thesis-erlenkr-bibliography}
63 \todoin{\textbf{Remove all todos (including list) before delivery/printing!!!}}
64 \todoin{Write abstract}
72 The discussions in this report must be seen in the context of object oriented
73 programming languages, and Java in particular, since that is the language in
74 which most of the examples will be given. All though the techniques discussed
75 may be applicable to languages from other paradigms, they will not be the
76 subject of this report.
80 \chapter{What is Refactoring?}
82 This question is best answered by first defining the concept of a
83 \emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects
84 of programming make people want to refactor their code.
86 \section{Defining refactoring}
87 Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a
88 refactoring like this:
91 \emph{Refactoring} (noun): a change made to the internal
92 structure\footnote{The structure observable by the programmer.} of software to
93 make it easier to understand and cheaper to modify without changing its
94 observable behavior.~\cite[p.~53]{refactoring}
97 \noindent This definition assigns additional meaning to the word
98 \emph{refactoring}, beyond the composition of the prefix \emph{re-}, usually
99 meaning something like ``again'' or ``anew'', and the word \emph{factoring},
100 that can mean to isolate the \emph{factors} of something. Here a \emph{factor}
101 would be close to the mathematical definition of something that divides a
102 quantity, without leaving a remainder. Fowler is mixing the \emph{motivation}
103 behind refactoring into his definition. Instead it could be more refined, formed
104 to only consider the \emph{mechanical} and \emph{behavioral} aspects of
105 refactoring. That is to factor the program again, putting it together in a
106 different way than before, while preserving the behavior of the program. An
107 alternative definition could then be:
109 \definition{A \emph{refactoring} is a transformation
110 done to a program without altering its external behavior.}
112 From this we can conclude that a refactoring primarily changes how the
113 \emph{code} of a program is perceived by the \emph{programmer}, and not the
114 \emph{behavior} experienced by any user of the program. Although the logical
115 meaning is preserved, such changes could potentially alter the program's
116 behavior when it comes to performance gain or -penalties. So any logic depending
117 on the performance of a program could make the program behave differently after
120 In the extreme case one could argue that such a thing as \emph{software
121 obfuscation} is to refactor. If we where to define it as a refactoring, it could
122 be defined as a composite refactoring \see{compositeRefactorings}, consisting
123 of, for instance, a series of rename refactorings. (But it could of course be
124 much more complex, and the mechanics of it would not exactly be carved in
125 stone.) To perform some serious obfuscation one would also take advantage of
126 techniques not found among established refactorings, such as removing
127 whitespace. This might not even generate a different syntax tree for languages
128 not sensitive to whitespace, placing it in the gray area of what kind of
129 transformations is to be considered refactorings.
131 \section{The etymology of 'refactoring'}
132 It is a little difficult to pinpoint the exact origin of the word
133 ``refactoring'', as it seems to have evolved as part of a colloquial
134 terminology, more than a scientific term. There is no authoritative source for a
135 formal definition of it.
137 According to Martin Fowler\citing{etymology-refactoring}, there may also be more
138 than one origin of the word. The most well-known source, when it comes to the
139 origin of \emph{refactoring}, is the Smalltalk\footnote{\emph{Smalltalk},
140 object-oriented, dynamically typed, reflective programming language. See
141 \url{http://www.smalltalk.org}} community and their infamous \emph{Refactoring
142 Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}}
143 described in the article \emph{A Refactoring Tool for
144 Smalltalk}\citing{refactoringBrowser1997}, published in 1997.
145 Allegedly\citing{etymology-refactoring}, the metaphor of factoring programs was
146 also present in the Forth\footnote{\emph{Forth} -- stack-based, extensible
147 programming language, without type-checking. See \url{http://www.forth.org}}
148 community, and the word ``refactoring'' is mentioned in a book by Leo Brodie,
149 called \emph{Thinking Forth}\citing{brodie1984}, first published in
150 1984\footnote{\emph{Thinking Forth} was first published in 1984 by the
151 \emph{Forth Interest Group}. Then it was reprinted in 1994 with minor
152 typographical corrections, before it was transcribed into an electronic edition
153 typeset in \LaTeX\ and published under a Creative Commons licence in 2004. The
154 edition cited here is the 2004 edition, but the content should essentially be as
155 in 1984.}. The exact word is only printed one place~\cite[p.~232]{brodie1984},
156 but the term \emph{factoring} is prominent in the book, that also contains a
157 whole chapter dedicated to (re)factoring, and how to keep the (Forth) code clean
161 \ldots good factoring technique is perhaps the most important skill for a
162 Forth programmer.~\cite[p.~172]{brodie1984}
165 \noindent Brodie also express what \emph{factoring} means to him:
168 Factoring means organizing code into useful fragments. To make a fragment
169 useful, you often must separate reusable parts from non-reusable parts. The
170 reusable parts become new definitions. The non-reusable parts become arguments
171 or parameters to the definitions.~\cite[p.~172]{brodie1984}
174 Fowler claims that the usage of the word \emph{refactoring} did not pass between
175 the \emph{Forth} and \emph{Smalltalk} communities, but that it emerged
176 independently in each of the communities.
178 \section{Motivation -- Why people refactor}
179 To get a grasp of what refactoring is all about, we can try to answer this
180 question: \emph{Why do people refactor?} Possible answers could include: ``To
181 remove duplication'' or ``to break up long methods''. Practitioners of the art
182 of Design Patterns\citing{designPatterns} could say that they do it to introduce
183 a long-needed pattern into their program's design. So it is safe to say that
184 peoples' intentions are to make their programs \emph{better} in some sense. But
185 what aspects of the programs are becoming improved?
187 As already mentioned, people often refactor to get rid of duplication. Moving
188 identical or similar code into methods, and maybe pushing methods up or down in
189 their class hierarchies. Making template methods for overlapping
190 algorithms/functionality and so on. It is all about gathering what belongs
191 together and putting it all in one place. The resulting code is then easier to
192 maintain. When removing the implicit coupling\footnote{When duplicating code,
193 the code might not be coupled in other ways than that it is supposed to
194 represent the same functionality. So if this functionality is going to change,
195 it might need to change in more than one place, thus creating an implicit
196 coupling between the multiple pieces of code.} between code snippets, the
197 location of a bug is limited to only one place, and new functionality need only
198 to be added to this one place, instead of a number of places people might not
201 A problem you often encounter when programming, is that a program contains a lot
202 of long and hard-to-grasp methods. It can then help to break the methods into
203 smaller ones, using the \ExtractMethod refactoring\citing{refactoring}. Then you
204 may discover something about a program that you were not aware of before;
205 revealing bugs you did not know about or could not find due to the complex
206 structure of your program. \todo{Proof?} Making the methods smaller and giving
207 good names to the new ones clarifies the algorithms and enhances the
208 \emph{understandability} of the program \see{magic_number_seven}. This makes
209 refactoring an excellent method for exploring unknown program code, or code that
210 you had forgotten that you wrote.
212 Most primitive refactorings are simple. Their true power is first revealed when
213 they are combined into larger --- higher level --- refactorings, called
214 \emph{composite refactorings} \see{compositeRefactorings}. Often the goal of
215 such a series of refactorings is a design pattern. Thus the \emph{design} can be
216 evolved throughout the lifetime of a program, as opposed to designing up-front.
217 It is all about being structured and taking small steps to improve a program's
220 Many software design pattern are aimed at lowering the coupling between
221 different classes and different layers of logic. One of the most famous is
222 perhaps the \emph{Model-View-Controller}\citing{designPatterns} pattern, or
223 \emph{MVC} for short. It is aimed at lowering the coupling between the user
224 interface and the business logic and data representation of a program. This also
225 has the added benefit that the business logic could much easier be the target of
226 automated tests, increasing the productivity in the software development
227 process. Refactoring is an important tool on the way to something greater.
229 Another effect of refactoring is that with the increased separation of concerns
230 coming out of many refactorings, the \emph{performance} can be improved. When
231 profiling programs, the problematic parts are narrowed down to smaller parts of
232 the code, which are easier to tune, and optimization can be performed only where
233 needed and in a more effective way.
235 Last, but not least, and this should probably be the best reason to refactor, is
236 to refactor to \emph{facilitate a program change}. If one has managed to keep
237 one's code clean and tidy, and the code is not bloated with design patterns that
238 are not ever going to be needed, then some refactoring might be needed to
239 introduce a design pattern that is appropriate for the change that is going to
242 Refactoring program code --- with a goal in mind --- can give the code itself
243 more value. That is in the form of robustness to bugs, understandability and
244 maintainability. Having robust code is an obvious advantage, but
245 understandability and maintainability are both very important aspects of
246 software development. By incorporating refactoring in the development process,
247 bugs are found faster, new functionality is added more easily and code is easier
248 to understand by the next person exposed to it, which might as well be the
249 person who wrote it. The consequence of this, is that refactoring can increase
250 the average productivity of the development process, and thus also add to the
251 monetary value of a business in the long run. The perspective on productivity
252 and money should also be able to open the eyes of the many nearsighted managers
253 that seldom see beyond the next milestone.
255 \section{The magical number seven}\label{magic_number_seven}
256 The article \emph{The magical number seven, plus or minus two: some limits on
257 our capacity for processing information}\citing{miller1956} by George A.
258 Miller, was published in the journal \emph{Psychological Review} in 1956. It
259 presents evidence that support that the capacity of the number of objects a
260 human being can hold in its working memory is roughly seven, plus or minus two
261 objects. This number varies a bit depending on the nature and complexity of the
262 objects, but is according to Miller ``\ldots never changing so much as to be
265 Miller's article culminates in the section called \emph{Recoding}, a term he
266 borrows from communication theory. The central result in this section is that by
267 recoding information, the capacity of the amount of information that a human can
268 process at a time is increased. By \emph{recoding}, Miller means to group
269 objects together in chunks and give each chunk a new name that it can be
270 remembered by. By organizing objects into patterns of ever growing depth, one
271 can memorize and process a much larger amount of data than if it were to be
272 represented as its basic pieces. This grouping and renaming is analogous to how
273 many refactorings work, by grouping pieces of code and give them a new name.
274 Examples are the fundamental \ExtractMethod and \refactoring{Extract Class}
275 refactorings\citing{refactoring}.
278 \ldots recoding is an extremely powerful weapon for increasing the amount of
279 information that we can deal with.~\cite[p.~95]{miller1956}
282 An example from the article addresses the problem of memorizing a sequence of
283 binary digits. Let us say we have the following sequence\footnote{The example
284 presented here is slightly modified (and shortened) from what is presented in
285 the original article\citing{miller1956}, but it is essentially the same.} of
286 16 binary digits: ``1010001001110011''. Most of us will have a hard time
287 memorizing this sequence by only reading it once or twice. Imagine if we instead
288 translate it to this sequence: ``A273''. If you have a background from computer
289 science, it will be obvious that the latest sequence is the first sequence
290 recoded to be represented by digits with base 16. Most people should be able to
291 memorize this last sequence by only looking at it once.
293 Another result from the Miller article is that when the amount of information a
294 human must interpret increases, it is crucial that the translation from one code
295 to another must be almost automatic for the subject to be able to remember the
296 translation, before \heshe is presented with new information to recode. Thus
297 learning and understanding how to best organize certain kinds of data is
298 essential to efficiently handle that kind of data in the future. This is much
299 like when humans learn to read. First they must learn how to recognize letters.
300 Then they can learn distinct words, and later read sequences of words that form
301 whole sentences. Eventually, most of them will be able to read whole books and
302 briefly retell the important parts of its content. This suggest that the use of
303 design patterns\citing{designPatterns} is a good idea when reasoning about
304 computer programs. With extensive use of design patterns when creating complex
305 program structures, one does not always have to read whole classes of code to
306 comprehend how they function, it may be sufficient to only see the name of a
307 class to almost fully understand its responsibilities.
310 Our language is tremendously useful for repackaging material into a few chunks
311 rich in information.~\cite[p.~95]{miller1956}
314 Without further evidence, these results at least indicate that refactoring
315 source code into smaller units with higher cohesion and, when needed,
316 introducing appropriate design patterns, should aid in the cause of creating
317 computer programs that are easier to maintain and has code that is easier (and
320 \section{Notable contributions to the refactoring literature}
321 \todoin{Update with more contributions}
324 \item[1992] William F. Opdyke submits his doctoral dissertation called
325 \emph{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This
326 work defines a set of refactorings, that are behavior preserving given that
327 their preconditions are met. The dissertation is focused on the automation
329 \item[1999] Martin Fowler et al.: \emph{Refactoring: Improving the Design of
330 Existing Code}\citing{refactoring}. This is maybe the most influential text
331 on refactoring. It bares similarities with Opdykes thesis\citing{opdyke1992}
332 in the way that it provides a catalog of refactorings. But Fowler's book is
333 more about the craft of refactoring, as he focuses on establishing a
334 vocabulary for refactoring, together with the mechanics of different
335 refactorings and when to perform them. His methodology is also founded on
336 the principles of test-driven development.
337 \item[2005] Joshua Kerievsky: \emph{Refactoring to
338 Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's
339 \emph{Refactoring}\citing{refactoring} and the ``Gang of Four'' \emph{Design
340 Patterns}\citing{designPatterns}. It is building on the refactoring
341 catalogue from Fowler's book, but is trying to bridge the gap between
342 \emph{refactoring} and \emph{design patterns} by providing a series of
343 higher-level composite refactorings, that makes code evolve toward or away
344 from certain design patterns. The book is trying to build up the readers
345 intuition around \emph{why} one would want to use a particular design
346 pattern, and not just \emph{how}. The book is encouraging evolutionary
347 design. \See{relationToDesignPatterns}
350 \section{Tool support}\label{toolSupport}
352 \subsection{Tool support for Java}
353 This section will briefly compare the refatoring support of the three IDEs
354 \emph{Eclipse}\footnote{\url{http://www.eclipse.org/}}, \emph{IntelliJ
355 IDEA}\footnote{The IDE under comparison is the \emph{Community Edition},
356 \url{http://www.jetbrains.com/idea/}} and
357 \emph{NetBeans}\footnote{\url{https://netbeans.org/}}. These are the most
358 popular Java IDEs\citing{javaReport2011}.
360 All three IDEs provide support for the most useful refactorings, like the
361 different extract, move and rename refactorings. In fact, Java-targeted IDEs are
362 known for their good refactoring support, so this did not appear as a big
365 The IDEs seem to have excellent support for the \ExtractMethod refactoring, so
366 at least they have all passed the first refactoring
367 rubicon\citing{fowlerRubicon2001,secondRubicon2012}.
369 Regarding the \MoveMethod refactoring, the \emph{Eclipse} and \emph{IntelliJ}
370 IDEs do the job in very similar manners. In most situations they both do a
371 satisfying job by producing the expected outcome. But they do nothing to check
372 that the result does not break the semantics of the program \see{correctness}.
373 The \emph{NetBeans} IDE implements this refactoring in a somewhat
374 unsophisticated way. For starters, its default destination for the move is
375 itself, although it refuses to perform the refactoring if chosen. But the worst
376 part is, that if moving the method \method{f} of the class \type{C} to the class
377 \type{X}, it will break the code. The result is shown in
378 \myref{lst:moveMethod_NetBeans}.
382 \begin{minted}[samepage]{java}
395 \begin{minted}[samepage]{java}
405 \caption{Moving method \method{f} from \type{C} to \type{X}.}
406 \label{lst:moveMethod_NetBeans}
409 NetBeans will try to make code that call the methods \method{m} and \method{n}
410 of \type{X} by accessing them through \var{c.x}, where \var{c} is a parameter of
411 type \type{C} that is added the method \method{f} when it is moved. (This is
412 seldom the desired outcome of this refactoring, but ironically, this ``feature''
413 keeps NetBeans from breaking the code in the example from \myref{correctness}.)
414 If \var{c.x} for some reason is inaccessible to \type{X}, as in this case, the
415 refactoring breaks the code, and it will not compile. NetBeans presents a
416 preview of the refactoring outcome, but the preview does not catch it if the IDE
417 is about break the program.
419 The IDEs under investigation seems to have fairly good support for primitive
420 refactorings, but what about more complex ones, such as the \refactoring{Extract
421 Class}\citing{refactoring}? The \refactoring{Extract Class} refactoring works by
422 creating a class, for then to move members to that class and access them from
423 the old class via a reference to the new class. \emph{IntelliJ} handles this in
424 a fairly good manner, although, in the case of private methods, it leaves unused
425 methods behind. These are methods that delegate to a field with the type of the
426 new class, but are not used anywhere. \emph{Eclipse} has added (or withdrawn)
427 its own quirk to the Extract Class refactoring, and only allows for
428 \emph{fields} to be moved to a new class, \emph{not methods}. This makes it
429 effectively only extracting a data structure, and calling it
430 \refactoring{Extract Class} is a little misleading. One would often be better
431 off with textual extract and paste than using the Extract Class refactoring in
432 Eclipse. When it comes to \emph{NetBeans}, it does not even seem to have made an
433 attempt on providing this refactoring. (Well, it probably has, but it does not
436 \todoin{Visual Studio (C++/C\#), Smalltalk refactoring browser?,
437 second refactoring rubicon?}
439 \section{The relation to design patterns}\label{relationToDesignPatterns}
441 \emph{Refactoring} and \emph{design patterns} have at least one thing in common,
442 they are both promoted by advocates of \emph{clean code}\citing{cleanCode} as
443 fundamental tools on the road to more maintanable and extendable source code.
446 Design patterns help you determine how to reorganize a design, and they can
447 reduce the amount of refactoring you need to do
448 later.~\cite[p.~353]{designPatterns}
451 Although sometimes associated with
452 over-engineering\citing{kerievsky2005,refactoring}, design patterns are in
453 general assumed to be good for maintainability of source code. That may be
454 because many of them are designed to support the \emph{open/closed principle} of
455 object-oriented programming. The principle was first formulated by Bertrand
456 Meyer, the creator of the Eiffel programming language, like this: ``Modules
457 should be both open and closed.''\citing{meyer1988} It has been popularized,
458 with this as a common version:
461 Software entities (classes, modules, functions, etc.) should be open for
462 extension, but closed for modification.\footnote{See
463 \url{http://c2.com/cgi/wiki?OpenClosedPrinciple} or
464 \url{https://en.wikipedia.org/wiki/Open/closed_principle}}
467 Maintainability is often thought of as the ability to be able to introduce new
468 functionality without having to change too much of the old code. When
469 refactoring, the motivation is often to facilitate adding new functionality. It
470 is about factoring the old code in a way that makes the new functionality being
471 able to benefit from the functionality already residing in a software system,
472 without having to copy old code into new. Then, next time someone shall add new
473 functionality, it is less likely that the old code has to change. Assuming that
474 a design pattern is the best way to get rid of duplication and assist in
475 implementing new functionality, it is reasonable to conclude that a design
476 pattern often is the target of a series of refactorings. Having a repertoire of
477 design patterns can also help in knowing when and how to refactor a program to
478 make it reflect certain desired characteristics.
481 There is a natural relation between patterns and refactorings. Patterns are
482 where you want to be; refactorings are ways to get there from somewhere
483 else.~\cite[p.~107]{refactoring}
486 This quote is wise in many contexts, but it is not always appropriate to say
487 ``Patterns are where you want to be\ldots''. \emph{Sometimes}, patterns are
488 where you want to be, but only because it will benefit your design. It is not
489 true that one should always try to incorporate as many design patterns as
490 possible into a program. It is not like they have intrinsic value. They only add
491 value to a system when they support its design. Otherwise, the use of design
492 patterns may only lead to a program that is more complex than necessary.
495 The overuse of patterns tends to result from being patterns happy. We are
496 \emph{patterns happy} when we become so enamored of patterns that we simply
497 must use them in our code.~\cite[p.~24]{kerievsky2005}
500 This can easily happen when relying largely on up-front design. Then it is
501 natural, in the very beginning, to try to build in all the flexibility that one
502 believes will be necessary throughout the lifetime of a software system.
503 According to Joshua Kerievsky ``That sounds reasonable --- if you happen to be
504 psychic.''~\cite[p.~1]{kerievsky2005} He is advocating what he believes is a
505 better approach: To let software continually evolve. To start with a simple
506 design that meets today's needs, and tackle future needs by refactoring to
507 satisfy them. He believes that this is a more economic approach than investing
508 time and money into a design that inevitably is going to change. By relying on
509 continuously refactoring a system, its design can be made simpler without
510 sacrificing flexibility. To be able to fully rely on this approach, it is of
511 utter importance to have a reliable suit of tests to lean on. \See{testing} This
512 makes the design process more natural and less characterized by difficult
513 decisions that has to be made before proceeding in the process, and that is
514 going to define a project for all of its unforeseeable future.
518 \section{Classification of refactorings}
519 % only interesting refactorings
520 % with 2 detailed examples? One for structured and one for intra-method?
521 % Is replacing Bubblesort with Quick Sort considered a refactoring?
523 \subsection{Structural refactorings}
525 \subsubsection{Primitive refactorings}
528 \explanation{Extract Method}{You have a code fragment that can be grouped
529 together.}{Turn the fragment into a method whose name explains the purpose of
532 \explanation{Inline Method}{A method's body is just as clear as its name.}{Put
533 the method's body into the body of its callers and remove the method.}
535 \explanation{Inline Temp}{You have a temp that is assigned to once with a simple
536 expression, and the temp is getting in the way of other refactorings.}{Replace
537 all references to that temp with the expression}
539 % Moving Features Between Objects
540 \explanation{Move Method}{A method is, or will be, using or used by more
541 features of another class than the class on which it is defined.}{Create a new
542 method with a similar body in the class it uses most. Either turn the old method
543 into a simple delegation, or remove it altogether.}
545 \explanation{Move Field}{A field is, or will be, used by another class more than
546 the class on which it is defined}{Create a new field in the target class, and
547 change all its users.}
550 \explanation{Replace Magic Number with Symbolic Constant}{You have a literal
551 number with a particular meaning.}{Create a constant, name it after the meaning,
552 and replace the number with it.}
554 \explanation{Encapsulate Field}{There is a public field.}{Make it private and
557 \explanation{Replace Type Code with Class}{A class has a numeric type code that
558 does not affect its behavior.}{Replace the number with a new class.}
560 \explanation{Replace Type Code with Subclasses}{You have an immutable type code
561 that affects the behavior of a class.}{Replace the type code with subclasses.}
563 \explanation{Replace Type Code with State/Strategy}{You have a type code that
564 affects the behavior of a class, but you cannot use subclassing.}{Replace the
565 type code with a state object.}
567 % Simplifying Conditional Expressions
568 \explanation{Consolidate Duplicate Conditional Fragments}{The same fragment of
569 code is in all branches of a conditional expression.}{Move it outside of the
572 \explanation{Remove Control Flag}{You have a variable that is acting as a
573 control flag fro a series of boolean expressions.}{Use a break or return
576 \explanation{Replace Nested Conditional with Guard Clauses}{A method has
577 conditional behavior that does not make clear the normal path of
578 execution.}{Use guard clauses for all special cases.}
580 \explanation{Introduce Null Object}{You have repeated checks for a null
581 value.}{Replace the null value with a null object.}
583 \explanation{Introduce Assertion}{A section of code assumes something about the
584 state of the program.}{Make the assumption explicit with an assertion.}
586 % Making Method Calls Simpler
587 \explanation{Rename Method}{The name of a method does not reveal its
588 purpose.}{Change the name of the method}
590 \explanation{Add Parameter}{A method needs more information from its
591 caller.}{Add a parameter for an object that can pass on this information.}
593 \explanation{Remove Parameter}{A parameter is no longer used by the method
596 %\explanation{Parameterize Method}{Several methods do similar things but with
597 %different values contained in the method.}{Create one method that uses a
598 %parameter for the different values.}
600 \explanation{Preserve Whole Object}{You are getting several values from an
601 object and passing these values as parameters in a method call.}{Send the whole
604 \explanation{Remove Setting Method}{A field should be set at creation time and
605 never altered.}{Remove any setting method for that field.}
607 \explanation{Hide Method}{A method is not used by any other class.}{Make the
610 \explanation{Replace Constructor with Factory Method}{You want to do more than
611 simple construction when you create an object}{Replace the constructor with a
614 % Dealing with Generalization
615 \explanation{Pull Up Field}{Two subclasses have the same field.}{Move the field
618 \explanation{Pull Up Method}{You have methods with identical results on
619 subclasses.}{Move them to the superclass.}
621 \explanation{Push Down Method}{Behavior on a superclass is relevant only for
622 some of its subclasses.}{Move it to those subclasses.}
624 \explanation{Push Down Field}{A field is used only by some subclasses.}{Move the
625 field to those subclasses}
627 \explanation{Extract Interface}{Several clients use the same subset of a class's
628 interface, or two classes have part of their interfaces in common.}{Extract the
629 subset into an interface.}
631 \explanation{Replace Inheritance with Delegation}{A subclass uses only part of a
632 superclasses interface or does not want to inherit data.}{Create a field for the
633 superclass, adjust methods to delegate to the superclass, and remove the
636 \explanation{Replace Delegation with Inheritance}{You're using delegation and
637 are often writing many simple delegations for the entire interface}{Make the
638 delegating class a subclass of the delegate.}
640 \subsubsection{Composite refactorings}
643 % \explanation{Replace Method with Method Object}{}{}
645 % Moving Features Between Objects
646 \explanation{Extract Class}{You have one class doing work that should be done by
647 two}{Create a new class and move the relevant fields and methods from the old
648 class into the new class.}
650 \explanation{Inline Class}{A class isn't doing very much.}{Move all its features
651 into another class and delete it.}
653 \explanation{Hide Delegate}{A client is calling a delegate class of an
654 object.}{Create Methods on the server to hide the delegate.}
656 \explanation{Remove Middle Man}{A class is doing to much simple delegation.}{Get
657 the client to call the delegate directly.}
660 \explanation{Replace Data Value with Object}{You have a data item that needs
661 additional data or behavior.}{Turn the data item into an object.}
663 \explanation{Change Value to Reference}{You have a class with many equal
664 instances that you want to replace with a single object.}{Turn the object into a
667 \explanation{Encapsulate Collection}{A method returns a collection}{Make it
668 return a read-only view and provide add/remove methods.}
670 % \explanation{Replace Array with Object}{}{}
672 \explanation{Replace Subclass with Fields}{You have subclasses that vary only in
673 methods that return constant data.}{Change the methods to superclass fields and
674 eliminate the subclasses.}
676 % Simplifying Conditional Expressions
677 \explanation{Decompose Conditional}{You have a complicated conditional
678 (if-then-else) statement.}{Extract methods from the condition, then part, an
681 \explanation{Consolidate Conditional Expression}{You have a sequence of
682 conditional tests with the same result.}{Combine them into a single conditional
683 expression and extract it.}
685 \explanation{Replace Conditional with Polymorphism}{You have a conditional that
686 chooses different behavior depending on the type of an object.}{Move each leg
687 of the conditional to an overriding method in a subclass. Make the original
690 % Making Method Calls Simpler
691 \explanation{Replace Parameter with Method}{An object invokes a method, then
692 passes the result as a parameter for a method. The receiver can also invoke this
693 method.}{Remove the parameter and let the receiver invoke the method.}
695 \explanation{Introduce Parameter Object}{You have a group of parameters that
696 naturally go together.}{Replace them with an object.}
698 % Dealing with Generalization
699 \explanation{Extract Subclass}{A class has features that are used only in some
700 instances.}{Create a subclass for that subset of features.}
702 \explanation{Extract Superclass}{You have two classes with similar
703 features.}{Create a superclass and move the common features to the
706 \explanation{Collapse Hierarchy}{A superclass and subclass are not very
707 different.}{Merge them together.}
709 \explanation{Form Template Method}{You have two methods in subclasses that
710 perform similar steps in the same order, yet the steps are different.}{Get the
711 steps into methods with the same signature, so that the original methods become
712 the same. Then you can pull them up.}
715 \subsection{Functional refactorings}
717 \explanation{Substitute Algorithm}{You want to replace an algorithm with one
718 that is clearer.}{Replace the body of the method with the new algorithm.}
722 \section{The impact on software quality}
724 \subsection{What is software quality?}
725 The term \emph{software quality} has many meanings. It all depends on the
726 context we put it in. If we look at it with the eyes of a software developer, it
727 usually means that the software is easily maintainable and testable, or in other
728 words, that it is \emph{well designed}. This often correlates with the
729 management scale, where \emph{keeping the schedule} and \emph{customer
730 satisfaction} is at the center. From the customers point of view, in addition to
731 good usability, \emph{performance} and \emph{lack of bugs} is always
732 appreciated, measurements that are also shared by the software developer. (In
733 addition, such things as good documentation could be measured, but this is out
734 of the scope of this document.)
736 \subsection{The impact on performance}
738 Refactoring certainly will make software go more slowly\footnote{With todays
739 compiler optimization techniques and performance tuning of e.g. the Java
740 virtual machine, the penalties of object creation and method calls are
741 debatable.}, but it also makes the software more amenable to performance
742 tuning.~\cite[p.~69]{refactoring}
745 \noindent There is a common belief that refactoring compromises performance, due
746 to increased degree of indirection and that polymorphism is slower than
749 In a survey, Demeyer\citing{demeyer2002} disproves this view in the case of
750 polymorphism. He did an experiment on, what he calls, ``Transform Self Type
751 Checks'' where you introduce a new polymorphic method and a new class hierarchy
752 to get rid of a class' type checking of a ``type attribute``. He uses this kind
753 of transformation to represent other ways of replacing conditionals with
754 polymorphism as well. The experiment is performed on the C++ programming
755 language and with three different compilers and platforms. Demeyer concludes
756 that, with compiler optimization turned on, polymorphism beats middle to large
757 sized if-statements and does as well as case-statements. (In accordance with
758 his hypothesis, due to similarities between the way C++ handles polymorphism and
762 The interesting thing about performance is that if you analyze most programs,
763 you find that they waste most of their time in a small fraction of the
764 code.~\cite[p.~70]{refactoring}
767 \noindent So, although an increased amount of method calls could potentially
768 slow down programs, one should avoid premature optimization and sacrificing good
769 design, leaving the performance tuning until after profiling\footnote{For and
770 example of a Java profiler, check out VisualVM:
771 \url{http://visualvm.java.net/}} the software and having isolated the actual
774 \section{Composite refactorings}\label{compositeRefactorings}
775 \todo{motivation, examples, manual vs automated?, what about refactoring in a
776 very large code base?}
777 Generally, when thinking about refactoring, at the mechanical level, there are
778 essentially two kinds of refactorings. There are the \emph{primitive}
779 refactorings, and the \emph{composite} refactorings.
781 \definition{A \emph{primitive refactoring} is a refactoring that cannot be
782 expressed in terms of other refactorings.}
784 \noindent Examples are the \refactoring{Pull Up Field} and \refactoring{Pull Up
785 Method} refactorings\citing{refactoring}, that move members up in their class
788 \definition{A \emph{composite refactoring} is a refactoring that can be
789 expressed in terms of two or more other refactorings.}
791 \noindent An example of a composite refactoring is the \refactoring{Extract
792 Superclass} refactoring\citing{refactoring}. In its simplest form, it is composed
793 of the previously described primitive refactorings, in addition to the
794 \refactoring{Pull Up Constructor Body} refactoring\citing{refactoring}. It works
795 by creating an abstract superclass that the target class(es) inherits from, then
796 by applying \refactoring{Pull Up Field}, \refactoring{Pull Up Method} and
797 \refactoring{Pull Up Constructor Body} on the members that are to be members of
798 the new superclass. For an overview of the \refactoring{Extract Superclass}
799 refactoring, see \myref{fig:extractSuperclass}.
803 \includegraphics[angle=270,width=\linewidth]{extractSuperclassItalic.pdf}
804 \caption{The Extract Superclass refactoring}
805 \label{fig:extractSuperclass}
808 \section{Manual vs. automated refactorings}
809 Refactoring is something every programmer does, even if \heshe does not known
810 the term \emph{refactoring}. Every refinement of source code that does not alter
811 the program's behavior is a refactoring. For small refactorings, such as
812 \ExtractMethod, executing it manually is a manageable task, but is still prone
813 to errors. Getting it right the first time is not easy, considering the method
814 signature and all the other aspects of the refactoring that has to be in place.
816 Take for instance the renaming of classes, methods and fields. For complex
817 programs these refactorings are almost impossible to get right. Attacking them
818 with textual search and replace, or even regular expressions, will fall short on
819 these tasks. Then it is crucial to have proper tool support that can perform
820 them automatically. Tools that can parse source code and thus have semantic
821 knowledge about which occurrences of which names belong to what construct in the
822 program. For even trying to perform one of these complex task manually, one
823 would have to be very confident on the existing test suite \see{testing}.
825 \section{Correctness of refactorings}\label{correctness}
826 For automated refactorings to be truly useful, they must show a high degree of
827 behavior preservation. This last sentence might seem obvious, but there are
828 examples of refactorings in existing tools that break programs. I will now
829 present an example of an \ExtractMethod refactoring followed by a \MoveMethod
830 refactoring that breaks a program in both the \emph{Eclipse} and \emph{IntelliJ}
831 IDEs\footnote{The NetBeans IDE handles this particular situation without
832 altering ther program's beavior, mainly because its Move Method refactoring
833 implementation is a bit rancid in other ways \see{toolSupport}.}. The
834 following piece of code shows the target for the composed refactoring:
836 \begin{minted}[linenos,samepage]{java}
838 public X x = new X();
847 \noindent The next piece of code shows the destination of the refactoring. Note
848 that the method \method{m(C c)} of class \type{C} assigns to the field \var{x}
849 of the argument \var{c} that has type \type{C}:
851 \begin{minted}[samepage]{java}
860 The refactoring sequence works by extracting line 5 and 6 from the original
861 class \type{C} into a method \method{f} with the statements from those lines as
862 its method body. The method is then moved to the class \type{X}. The result is
863 shown in the following two pieces of code:
865 \begin{minted}[linenos,samepage]{java}
867 public X x = new X();
875 \begin{minted}[linenos,samepage]{java}
888 After the refactoring, the method \method{f} of class \type{C} is calling the
889 method \method{f} of class \type{X}, and the program now behaves different than
890 before. (See line 5 of the version of class \type{C} after the refactoring.)
891 Before the refactoring, the methods \method{m} and \method{n} of class \type{X}
892 are called on different object instances (see line 5 and 6 of the original class
893 \type{C}). After, they are called on the same object, and the statement on line
894 3 of class \type{X} (the version after the refactoring) no longer have any
895 effect in our example.
897 The bug introduced in the previous example is of such a nature\footnote{Caused
898 by aliasing. See \url{https://en.wikipedia.org/wiki/Aliasing_(computing)}}
899 that it is very difficult to spot if the refactored code is not covered by
900 tests. It does not generate compilation errors, and will thus only result in
901 a runtime error or corrupted data, which might be hard to detect.
903 \section{Refactoring and testing}\label{testing}
905 If you want to refactor, the essential precondition is having solid
906 tests.\citing{refactoring}
909 When refactoring, there are roughly two kinds of errors that can be made. There
910 are errors that make the code unable to compile, and there are the silent
911 errors, only popping up at runtime. Compile-time errors are the nice ones. They
912 flash up at the moment they are made (at least when using an IDE), and are
913 usually easy to fix. The other kind of error is the dangerous one. It is the
914 kind of error introduced in the example of \myref{correctness}. It is an error
915 sneaking into your code without you noticing, maybe. For discovering those kind
916 of errors when refactoring, it is essential to have good test coverage. It is
917 not a way to \emph{prove} that the code is correct, but it is a way to make you
918 confindent that it \emph{probably} works as desired. In the context of test
919 driven development, the tests are even a way to define how the program is
920 supposed to work. It is then, by definition, working if the tests are passing.
922 If the test coverage for a code base is perfect, then it should, theoretically,
923 be risk-free to perform refactorings on it. This is why tests and refactoring
924 are such a great match.
926 \section{Software metrics}
927 \todoin{Is this the appropriate place to have this section?}
930 %\chapter{Planning the project}
938 \section{The problem statement}
939 \section{Choosing the target language}
940 Choosing which programming language to use as the target for manipulation is not
941 a very difficult task. The language has to be an object-oriented programming
942 language, and it must have existing tool support for refactoring. The
943 \emph{Java} programming language\footnote{\url{https://www.java.com/}} is the
944 dominating language when it comes to examples in the literature of refactoring,
945 and is thus a natural choice. Java is perhaps, currently the most influential
946 programming language in the world, with its \emph{Java Virtual Machine} that
947 runs on all of the most popular architectures and also supports\footnote{They
948 compile to java bytecode.} dozens of other programming languages, with
949 \emph{Scala}, \emph{Clojure} and \emph{Groovy} as the most prominent ones. Java
950 is currently the language that every other programming language is compared
951 against. It is also the primary language of the author of this thesis.
953 \section{Choosing the tools}
954 When choosing a tool for manipulating Java, there are certain criterias that
955 have to be met. First of all, the tool should have some existing refactoring
956 support that this thesis can build upon. Secondly it should provide some kind of
957 framework for parsing and analyzing Java source code. Third, it should itself be
958 open source. This is both because of the need to be able to browse the code for
959 the existing refactorings that is contained in the tool, and also because open
960 source projects hold value in them selves. Another important aspect to consider
961 is that open source projects of a certain size, usually has large communities of
962 people connected to them, that are commited to answering questions regarding the
963 use and misuse of the products, that to a large degree is made by the cummunity
966 There is a certain class of tools that meet these criterias, namely the class of
967 \emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
968 proagrams that is ment to support the whole production cycle of a cumputer
969 program, and the most popular IDEs that support Java, generally have quite good
972 The main contenders for this thesis is the \emph{Eclipse IDE}, with the
973 \emph{Java development tools} (JDT), the \emph{IntelliJ IDEA Community Edition}
974 and the \emph{NetBeans IDE}. \See{toolSupport} Eclipse and NetBeans are both
975 free, open source and community driven, while the IntelliJ IDEA has an open
976 sourced community edition that is free of charge, but also offer an
977 \emph{Ultimate Edition} with an extended set of features, at additional cost.
978 All three IDEs supports adding plugins to extend their functionality and tools
979 that can be used to parse and analyze Java source code. But one of the IDEs
980 stand out as a favorite, and that is the \emph{Eclipse IDE}. This is the most
981 popular\citing{javaReport2011} among them and seems to be de facto standard IDE
982 for Java development regardless of platform.
985 \chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful
986 Thinking}\label{ch:jdt_refactorings}
988 This chapter will deal with some of the design behind refactoring support in
989 Eclipse, and the JDT in specific. After which it will follow a section about
990 shortcomings of the refactoring API in terms of composition of refactorings. The
991 chapter will be concluded with a section telling some of the ways the
992 implementation of refactorings in the JDT could have worked to facilitate
993 composition of refactorings.
996 The refactoring world of Eclipse can in general be separated into two parts: The
997 language independent part and the part written for a specific programming
998 language -- the language that is the target of the supported refactorings.
999 \todo{What about the language specific part?}
1001 \subsection{The Language Toolkit}
1002 The Language Toolkit, or LTK for short, is the framework that is used to
1003 implement refactorings in Eclipse. It is language independent and provides the
1004 abstractions of a refactoring and the change it generates, in the form of the
1005 classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} and
1006 \typewithref{org.eclipse.ltk.core.refactoring}{Change}. (There is also parts of
1007 the LTK that is concerned with user interaction, but they will not be discussed
1008 here, since they are of little value to us and our use of the framework.)
1010 \subsubsection{The Refactoring Class}
1011 The abstract class \type{Refactoring} is the core of the LTK framework. Every
1012 refactoring that is going to be supported by the LTK have to end up creating an
1013 instance of one of its subclasses. The main responsibilities of subclasses of
1014 \type{Refactoring} is to implement template methods for condition checking
1015 (\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkInitialConditions}
1017 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkFinalConditions}),
1019 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{createChange}
1020 method that creates and returns an instance of the \type{Change} class.
1022 If the refactoring shall support that others participate in it when it is
1023 executed, the refactoring has to be a processor-based
1024 refactoring\typeref{org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring}.
1025 It then delegates to its given
1026 \typewithref{org.eclipse.ltk.core.refactoring.participants}{RefactoringProcessor}
1027 for condition checking and change creation.
1029 \subsubsection{The Change Class}
1030 This class is the base class for objects that is responsible for performing the
1031 actual workspace transformations in a refactoring. The main responsibilities for
1032 its subclasses is to implement the
1033 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{perform} and
1034 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{isValid} methods. The
1035 \method{isValid} method verifies that the change object is valid and thus can be
1036 executed by calling its \method{perform} method. The \method{perform} method
1037 performs the desired change and returns an undo change that can be executed to
1038 reverse the effect of the transformation done by its originating change object.
1040 \subsubsection{Executing a Refactoring}\label{executing_refactoring}
1041 The life cycle of a refactoring generally follows two steps after creation:
1042 condition checking and change creation. By letting the refactoring object be
1044 \typewithref{org.eclipse.ltk.core.refactoring}{CheckConditionsOperation} that
1045 in turn is handled by a
1046 \typewithref{org.eclipse.ltk.core.refactoring}{CreateChangeOperation}, it is
1047 assured that the change creation process is managed in a proper manner.
1049 The actual execution of a change object has to follow a detailed life cycle.
1050 This life cycle is honored if the \type{CreateChangeOperation} is handled by a
1051 \typewithref{org.eclipse.ltk.core.refactoring}{PerformChangeOperation}. If also
1052 an undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} is set
1053 for the \type{PerformChangeOperation}, the undo change is added into the undo
1056 \section{Shortcomings}
1057 This section is introduced naturally with a conclusion: The JDT refactoring
1058 implementation does not facilitate composition of refactorings.
1059 \todo{refine}This section will try to explain why, and also identify other
1060 shortcomings of both the usability and the readability of the JDT refactoring
1063 I will begin at the end and work my way toward the composition part of this
1066 \subsection{Absence of Generics in Eclipse Source Code}
1067 This section is not only concerning the JDT refactoring API, but also large
1068 quantities of the Eclipse source code. The code shows a striking absence of the
1069 Java language feature of generics. It is hard to read a class' interface when
1070 methods return objects or takes parameters of raw types such as \type{List} or
1071 \type{Map}. This sometimes results in having to read a lot of source code to
1072 understand what is going on, instead of relying on the available interfaces. In
1073 addition, it results in a lot of ugly code, making the use of typecasting more
1074 of a rule than an exception.
1076 \subsection{Composite Refactorings Will Not Appear as Atomic Actions}
1078 \subsubsection{Missing Flexibility from JDT Refactorings}
1079 The JDT refactorings are not made with composition of refactorings in mind. When
1080 a JDT refactoring is executed, it assumes that all conditions for it to be
1081 applied successfully can be found by reading source files that has been
1082 persisted to disk. They can only operate on the actual source material, and not
1083 (in-memory) copies thereof. This constitutes a major disadvantage when trying to
1084 compose refactorings, since if an exception occur in the middle of a sequence of
1085 refactorings, it can leave the project in a state where the composite
1086 refactoring was executed only partly. It makes it hard to discard the changes
1087 done without monitoring and consulting the undo manager, an approach that is not
1090 \subsubsection{Broken Undo History}
1091 When designing a composed refactoring that is to be performed as a sequence of
1092 refactorings, you would like it to appear as a single change to the workspace.
1093 This implies that you would also like to be able to undo all the changes done by
1094 the refactoring in a single step. This is not the way it appears when a sequence
1095 of JDT refactorings is executed. It leaves the undo history filled up with
1096 individual undo actions corresponding to every single JDT refactoring in the
1097 sequence. This problem is not trivial to handle in Eclipse.
1098 \See{hacking_undo_history}
1100 \section{Wishful Thinking}
1103 \chapter{Composite Refactorings in Eclipse}
1105 \section{A Simple Ad Hoc Model}
1106 As pointed out in \myref{ch:jdt_refactorings}, the Eclipse JDT refactoring model
1107 is not very well suited for making composite refactorings. Therefore a simple
1108 model using changer objects (of type \type{RefaktorChanger}) is used as an
1109 abstraction layer on top of the existing Eclipse refactorings.
1111 \section{The Extract and Move Method Refactoring}
1112 %The Extract and Move Method Refactoring is implemented mainly using these
1115 % \item \type{ExtractAndMoveMethodChanger}
1116 % \item \type{ExtractAndMoveMethodPrefixesExtractor}
1117 % \item \type{Prefix}
1118 % \item \type{PrefixSet}
1121 \subsection{The Building Blocks}
1122 This is a composite refactoring, and hence is built up using several primitive
1123 refactorings. These basic building blocks are, as its name implies, the
1124 \ExtractMethod refactoring\citing{refactoring} and the \MoveMethod
1125 refactoring\citing{refactoring}. In Eclipse, the implementations of these
1126 refactorings are found in the classes
1127 \typewithref{org.eclipse.jdt.internal.corext.refactoring.code}{ExtractMethodRefactoring}
1129 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure}{MoveInstanceMethodProcessor},
1130 where the last class is designed to be used together with the processor-based
1131 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveRefactoring}.
1133 \subsubsection{The ExtractMethodRefactoring Class}
1134 This class is quite simple in its use. The only parameters it requires for
1135 construction is a compilation
1136 unit\typeref{org.eclipse.jdt.core.ICompilationUnit}, the offset into the source
1137 code where the extraction shall start, and the length of the source to be
1138 extracted. Then you have to set the method name for the new method together with
1139 which access modifier that shall be used and some not so interesting parameters.
1141 \subsubsection{The MoveInstanceMethodProcessor Class}
1142 For the Move Method the processor requires a little more advanced input than
1143 the class for the Extract Method. For construction it requires a method
1144 handle\typeref{org.eclipse.jdt.core.IMethod} from the Java Model for the method
1145 that is to be moved. Then the target for the move have to be supplied as the
1146 variable binding from a chosen variable declaration. In addition to this, one
1147 have to set some parameters regarding setters/getters and delegation.
1149 To make a whole refactoring from the processor, one have to construct a
1150 \type{MoveRefactoring} from it.
1152 \subsection{The ExtractAndMoveMethodChanger Class}
1153 The \typewithref{no.uio.ifi.refaktor.changers}{ExtractAndMoveMethodChanger}
1154 class, that is a subclass of the class
1155 \typewithref{no.uio.ifi.refaktor.changers}{RefaktorChanger}, is the class
1156 responsible for composing the \type{ExtractMethodRefactoring} and the
1157 \type{MoveRefactoring}. Its constructor takes a project
1158 handle\typeref{org.eclipse.core.resources.IProject}, the method name for the new
1159 method and a \typewithref{no.uio.ifi.refaktor.utils}{SmartTextSelection}.
1161 A \type{SmartTextSelection} is basically a text
1162 selection\typeref{org.eclipse.jface.text.ITextSelection} object that enforces
1163 the providing of the underlying document during creation. I.e. its
1164 \methodwithref{no.uio.ifi.refaktor.utils.SmartTextSelection}{getDocument} method
1165 will never return \type{null}.
1167 Before extracting the new method, the possible targets for the move operation is
1168 found with the help of an
1169 \typewithref{no.uio.ifi.refaktor.extractors}{ExtractAndMoveMethodPrefixesExtractor}.
1170 The possible targets is computed from the prefixes that the extractor returns
1172 \methodwithref{no.uio.ifi.refaktor.extractors.ExtractAndMoveMethodPrefixesExtractor}{getSafePrefixes}
1173 method. The changer then choose the most suitable target by finding the most
1174 frequent occurring prefix among the safe ones. The target is the type of the
1175 first part of the prefix.
1177 After finding a suitable target, the \type{ExtractAndMoveMethodChanger} first
1178 creates an \type{ExtractMethodRefactoring} and performs it as explained in
1179 \myref{executing_refactoring} about the execution of refactorings. Then it
1180 creates and performs the \type{MoveRefactoring} in the same way, based on the
1181 changes done by the Extract Method refactoring.
1183 \subsection{The ExtractAndMoveMethodPrefixesExtractor Class}
1184 This extractor extracts properties needed for building the Extract and Move
1185 Method refactoring. It searches through the given selection to find safe
1186 prefixes, and those prefixes form a base that can be used to compute possible
1187 targets for the move part of the refactoring. It finds both the candidates, in
1188 the form of prefixes, and the non-candidates, called unfixes. All prefixes (and
1189 unfixes) are represented by a
1190 \typewithref{no.uio.ifi.refaktor.extractors}{Prefix}, and they are collected
1191 into prefix sets.\typeref{no.uio.ifi.refaktor.extractors.PrefixSet}.
1193 The prefixes and unfixes are found by property
1194 collectors\typeref{no.uio.ifi.refaktor.extractors.collectors.PropertyCollector}.
1195 A property collector follows the visitor pattern\citing{designPatterns} and is
1196 of the \typewithref{org.eclipse.jdt.core.dom}{ASTVisitor} type. An
1197 \type{ASTVisitor} visits nodes in an abstract syntax tree that forms the Java
1198 document object model. The tree consists of nodes of type
1199 \typewithref{org.eclipse.jdt.core.do}{ASTNode}.
1201 \subsubsection{The PrefixesCollector}
1202 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{PrefixesCollector}
1203 is of type \type{PropertyCollector}. It visits expression
1204 statements\typeref{org.eclipse.jdt.core.dom.ExpressionStatement} and creates
1205 prefixes from its expressions in the case of method invocations. The prefixes
1206 found is registered with a prefix set, together with all its sub-prefixes.
1207 \todo{Rewrite in the case of changes to the way prefixes are found}
1209 \subsubsection{The UnfixesCollector}
1210 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{UnfixesCollector}
1211 finds unfixes within the selection. An unfix is a name that is assigned to
1212 within the selection. The reason that this cannot be allowed, is that the result
1213 would be an assignment to the \type{this} keyword, which is not valid in Java.
1215 \subsubsection{Computing Safe Prefixes}
1216 A safe prefix is a prefix that does not enclose an unfix. A prefix is enclosing
1217 an unfix if the unfix is in the set of its sub-prefixes. As an example,
1218 \texttt{``a.b''} is enclosing \texttt{``a''}, as is \texttt{``a''}. The safe
1219 prefixes is unified in a \type{PrefixSet} and can be fetched calling the
1220 \method{getSafePrefixes} method of the
1221 \type{ExtractAndMoveMethodPrefixesExtractor}.
1223 \subsection{The Prefix Class}
1225 \subsection{The PrefixSet Class}
1227 \subsection{Hacking the Refactoring Undo
1228 History}\label{hacking_undo_history}
1229 \todo{Where to put this section?}
1231 As an attempt to make multiple subsequent changes to the workspace appear as a
1232 single action (i.e. make the undo changes appear as such), I tried to alter
1233 the undo changes\typeref{org.eclipse.ltk.core.refactoring.Change} in the history
1234 of the refactorings.
1236 My first impulse was to remove the, in this case, last two undo changes from the
1237 undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} for the
1238 Eclipse refactorings, and then add them to a composite
1239 change\typeref{org.eclipse.ltk.core.refactoring.CompositeChange} that could be
1240 added back to the manager. The interface of the undo manager does not offer a
1241 way to remove/pop the last added undo change, so a possible solution could be to
1242 decorate\citing{designPatterns} the undo manager, to intercept and collect the
1243 undo changes before delegating to the \method{addUndo}
1244 method\methodref{org.eclipse.ltk.core.refactoring.IUndoManager}{addUndo} of the
1245 manager. Instead of giving it the intended undo change, a null change could be
1246 given to prevent it from making any changes if run. Then one could let the
1247 collected undo changes form a composite change to be added to the manager.
1249 There is a technical challenge with this approach, and it relates to the undo
1250 manager, and the concrete implementation
1251 UndoManager2\typeref{org.eclipse.ltk.internal.core.refactoring.UndoManager2}.
1252 This implementation is designed in a way that it is not possible to just add an
1253 undo change, you have to do it in the context of an active
1254 operation\typeref{org.eclipse.core.commands.operations.TriggeredOperations}.
1255 One could imagine that it might be possible to trick the undo manager into
1256 believing that you are doing a real change, by executing a refactoring that is
1257 returning a kind of null change that is returning our composite change of undo
1258 refactorings when it is performed.
1260 Apart from the technical problems with this solution, there is a functional
1261 problem: If it all had worked out as planned, this would leave the undo history
1262 in a dirty state, with multiple empty undo operations corresponding to each of
1263 the sequentially executed refactoring operations, followed by a composite undo
1264 change corresponding to an empty change of the workspace for rounding of our
1265 composite refactoring. The solution to this particular problem could be to
1266 intercept the registration of the intermediate changes in the undo manager, and
1267 only register the last empty change.
1269 Unfortunately, not everything works as desired with this solution. The grouping
1270 of the undo changes into the composite change does not make the undo operation
1271 appear as an atomic operation. The undo operation is still split up into
1272 separate undo actions, corresponding to the change done by its originating
1273 refactoring. And in addition, the undo actions has to be performed separate in
1274 all the editors involved. This makes it no solution at all, but a step toward
1277 There might be a solution to this problem, but it remains to be found. The
1278 design of the refactoring undo management is partly to be blamed for this, as it
1279 it is to complex to be easily manipulated.
1283 \chapter{Related Work}
1285 \section{The compositional paradigm of refactoring}
1286 This paradigm builds upon the observation of Vakilian et
1287 al.\citing{vakilian2012}, that of the many automated refactorings existing in
1288 modern IDEs, the simplest ones are dominating the usage statistics. The report
1289 mainly focuses on \emph{Eclipse} as the tool under investigation.
1291 The paradigm is described almost as the opposite of automated composition of
1292 refactorings \see{compositeRefactorings}. It works by providing the programmer
1293 with easily accessible primitive refactorings. These refactorings shall be
1294 accessed via keyboard shortcuts or quick-assist menus\footnote{Think
1295 quick-assist with Ctrl+1 in Eclipse} and be promptly executed, opposed to in the
1296 currently dominating wizard-based refactoring paradigm. They are ment to
1297 stimulate composing smaller refactorings into more complex changes, rather than
1298 doing a large upfront configuration of a wizard-based refactoring, before
1299 previewing and executing it. The compositional paradigm of refactoring is
1300 supposed to give control back to the programmer, by supporting \himher with an
1301 option of performing small rapid changes instead of large changes with a lesser
1302 degree of control. The report authors hope this will lead to fewer unsuccessful
1303 refactorings. It also could lower the bar for understanding the steps of a
1304 larger composite refactoring and thus also help in figuring out what goes wrong
1305 if one should choose to op in on a wizard-based refactoring.
1307 Vakilian and his associates have performed a survey of the effectiveness of the
1308 compositional paradigm versus the wizard-based one. They claim to have found
1309 evidence of that the \emph{compositional paradigm} outperforms the
1310 \emph{wizard-based}. It does so by reducing automation, which seem
1311 counterintuitive. Therefore they ask the question ``What is an appropriate level
1312 of automation?'', and thus questions what they feel is a rush toward more
1313 automation in the software engineering community.