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}
8 \usepackage[hidelinks]{hyperref}
10 \usepackage[style=numeric-comp,backend=bibtex]{biblatex}
13 % use 'disable' before printing:
14 \usepackage[]{todonotes}
21 \usepackage{perpage} %the perpage package
22 \MakePerPage{footnote} %the perpage package command
24 \theoremstyle{definition}
25 \newtheorem*{wordDef}{Definition}
27 \graphicspath{ {./figures/} }
29 \newcommand{\citing}[1]{~\cite{#1}}
30 \newcommand{\myref}[1]{\cref{#1} on \cpageref{#1}}
32 \newcommand{\definition}[1]{\begin{wordDef}#1\end{wordDef}}
33 \newcommand{\see}[1]{(see \myref{#1})}
34 \newcommand{\See}[1]{(See \myref{#1}.)}
35 \newcommand{\explanation}[3]{\noindent\textbf{\textit{#1}}\\*\emph{When:}
36 #2\\*\emph{How:} #3\\*[-7px]}
38 \newcommand{\type}[1]{\texttt{\textbf{#1}}}
39 \newcommand{\typeref}[1]{\footnote{\type{#1}}}
40 \newcommand{\typewithref}[2]{\type{#2}\typeref{#1.#2}}
41 \newcommand{\method}[1]{\type{#1}}
42 \newcommand{\methodref}[2]{\footnote{\type{#1}\method{\##2()}}}
43 \newcommand{\methodwithref}[2]{\method{#2}\footnote{\type{#1}\method{\##2()}}}
44 \newcommand{\var}[1]{\type{#1}}
46 \newcommand{\refactoring}[1]{\emph{#1}}
47 \newcommand{\ExtractMethod}{\refactoring{Extract Method}\xspace}
48 \newcommand{\MoveMethod}{\refactoring{Move Method}\xspace}
49 \newcommand{\ExtractAndMoveMethod}{\refactoring{Extract and Move Method}\xspace}
51 \newcommand\todoin[2][]{\todo[inline, caption={2do}, #1]{
52 \begin{minipage}{\textwidth-4pt}#2\end{minipage}}}
56 \author{Erlend Kristiansen}
58 \bibliography{bibliography/master-thesis-erlenkr-bibliography}
66 \todoin{\textbf{Remove all todos (including list) before delivery/printing!!!
67 Can be done by removing ``draft'' from documentclass.}}
68 \todoin{Write abstract}
76 The discussions in this report must be seen in the context of object oriented
77 programming languages, and Java in particular, since that is the language in
78 which most of the examples will be given. All though the techniques discussed
79 may be applicable to languages from other paradigms, they will not be the
80 subject of this report.
84 \chapter{What is Refactoring?}
86 This question is best answered by first defining the concept of a
87 \emph{refactoring}, what it is to \emph{refactor}, and then discuss what aspects
88 of programming make people want to refactor their code.
90 \section{Defining refactoring}
91 Martin Fowler, in his classic book on refactoring\citing{refactoring}, defines a
92 refactoring like this:
95 \emph{Refactoring} (noun): a change made to the internal
96 structure\footnote{The structure observable by the programmer.} of software to
97 make it easier to understand and cheaper to modify without changing its
98 observable behavior.~\cite[p.~53]{refactoring}
101 \noindent This definition assigns additional meaning to the word
102 \emph{refactoring}, beyond the composition of the prefix \emph{re-}, usually
103 meaning something like ``again'' or ``anew'', and the word \emph{factoring},
104 that can mean to isolate the \emph{factors} of something. Here a \emph{factor}
105 would be close to the mathematical definition of something that divides a
106 quantity, without leaving a remainder. Fowler is mixing the \emph{motivation}
107 behind refactoring into his definition. Instead it could be more refined, formed
108 to only consider the \emph{mechanical} and \emph{behavioral} aspects of
109 refactoring. That is to factor the program again, putting it together in a
110 different way than before, while preserving the behavior of the program. An
111 alternative definition could then be:
113 \definition{A \emph{refactoring} is a transformation
114 done to a program without altering its external behavior.}
116 From this we can conclude that a refactoring primarily changes how the
117 \emph{code} of a program is perceived by the \emph{programmer}, and not the
118 \emph{behavior} experienced by any user of the program. Although the logical
119 meaning is preserved, such changes could potentially alter the program's
120 behavior when it comes to performance gain or -penalties. So any logic depending
121 on the performance of a program could make the program behave differently after
124 In the extreme case one could argue that such a thing as \emph{software
125 obfuscation} is refactoring. Software obfuscation is to make source code harder
126 to read and analyze, while preserving its semantics. It could be done composing
127 many, more or less randomly chosen, refactorings. Then the question arise
128 whether it can be called a \emph{composite refactoring}
129 \see{compositeRefactorings} or not? The answer is not obvious. First, there is
130 no way to describe \emph{the} mechanics of software obfuscation, beacause there
131 are infinitely many ways to do that. Second, \emph{obfuscation} can be thought
132 of as \emph{one operation}: Either the code is obfuscated, or it is not. Third,
133 it makes no sense to call software obfuscation \emph{a} refactoring, since it
134 holds different meaning to different people. The last point is important, since
135 one of the motivations behind defining different refactorings is to build up a
136 vocabulary for software professionals to reason and discuss about programs,
137 similar to the motivation behind design patterns\citing{designPatterns}. So for
138 describing \emph{software obfuscation}, it might be more appropriate to define
139 what you do when performing it rather than precisely defining its mechanics in
140 terms of other refactorings.
142 \section{The etymology of 'refactoring'}
143 It is a little difficult to pinpoint the exact origin of the word
144 ``refactoring'', as it seems to have evolved as part of a colloquial
145 terminology, more than a scientific term. There is no authoritative source for a
146 formal definition of it.
148 According to Martin Fowler\citing{etymology-refactoring}, there may also be more
149 than one origin of the word. The most well-known source, when it comes to the
150 origin of \emph{refactoring}, is the Smalltalk\footnote{\emph{Smalltalk},
151 object-oriented, dynamically typed, reflective programming language. See
152 \url{http://www.smalltalk.org}} community and their infamous \emph{Refactoring
153 Browser}\footnote{\url{http://st-www.cs.illinois.edu/users/brant/Refactory/RefactoringBrowser.html}}
154 described in the article \emph{A Refactoring Tool for
155 Smalltalk}\citing{refactoringBrowser1997}, published in 1997.
156 Allegedly\citing{etymology-refactoring}, the metaphor of factoring programs was
157 also present in the Forth\footnote{\emph{Forth} -- stack-based, extensible
158 programming language, without type-checking. See \url{http://www.forth.org}}
159 community, and the word ``refactoring'' is mentioned in a book by Leo Brodie,
160 called \emph{Thinking Forth}\citing{brodie1984}, first published in
161 1984\footnote{\emph{Thinking Forth} was first published in 1984 by the
162 \emph{Forth Interest Group}. Then it was reprinted in 1994 with minor
163 typographical corrections, before it was transcribed into an electronic edition
164 typeset in \LaTeX\ and published under a Creative Commons licence in 2004. The
165 edition cited here is the 2004 edition, but the content should essentially be as
166 in 1984.}. The exact word is only printed one place~\cite[p.~232]{brodie1984},
167 but the term \emph{factoring} is prominent in the book, that also contains a
168 whole chapter dedicated to (re)factoring, and how to keep the (Forth) code clean
172 \ldots good factoring technique is perhaps the most important skill for a
173 Forth programmer.~\cite[p.~172]{brodie1984}
176 \noindent Brodie also express what \emph{factoring} means to him:
179 Factoring means organizing code into useful fragments. To make a fragment
180 useful, you often must separate reusable parts from non-reusable parts. The
181 reusable parts become new definitions. The non-reusable parts become arguments
182 or parameters to the definitions.~\cite[p.~172]{brodie1984}
185 Fowler claims that the usage of the word \emph{refactoring} did not pass between
186 the \emph{Forth} and \emph{Smalltalk} communities, but that it emerged
187 independently in each of the communities.
189 \section{Motivation -- Why people refactor}
190 There are many reasons why people want to refactor their programs. They can for
191 instance do it to remove duplication, break up long methods or to introduce
192 design patterns\citing{designPatterns} into their software systems. The shared
193 trait for all these are that peoples intentions are to make their programs
194 \emph{better}, in some sense. But what aspects of their programs are becoming
197 As already mentioned, people often refactor to get rid of duplication. Moving
198 identical or similar code into methods, and maybe pushing methods up or down in
199 their class hierarchies. Making template methods for overlapping
200 algorithms/functionality and so on. It is all about gathering what belongs
201 together and putting it all in one place. The resulting code is then easier to
202 maintain. When removing the implicit coupling\footnote{When duplicating code,
203 the code might not be coupled in other ways than that it is supposed to
204 represent the same functionality. So if this functionality is going to change,
205 it might need to change in more than one place, thus creating an implicit
206 coupling between the multiple pieces of code.} between code snippets, the
207 location of a bug is limited to only one place, and new functionality need only
208 to be added to this one place, instead of a number of places people might not
211 A problem you often encounter when programming, is that a program contains a lot
212 of long and hard-to-grasp methods. It can then help to break the methods into
213 smaller ones, using the \ExtractMethod refactoring\citing{refactoring}. Then you
214 may discover something about a program that you were not aware of before;
215 revealing bugs you did not know about or could not find due to the complex
216 structure of your program. \todo{Proof?} Making the methods smaller and giving
217 good names to the new ones clarifies the algorithms and enhances the
218 \emph{understandability} of the program \see{magic_number_seven}. This makes
219 refactoring an excellent method for exploring unknown program code, or code that
220 you had forgotten that you wrote.
222 Most primitive refactorings are simple. Their true power is first revealed when
223 they are combined into larger --- higher level --- refactorings, called
224 \emph{composite refactorings} \see{compositeRefactorings}. Often the goal of
225 such a series of refactorings is a design pattern. Thus the \emph{design} can be
226 evolved throughout the lifetime of a program, as opposed to designing up-front.
227 It is all about being structured and taking small steps to improve a program's
230 Many software design pattern are aimed at lowering the coupling between
231 different classes and different layers of logic. One of the most famous is
232 perhaps the \emph{Model-View-Controller}\citing{designPatterns} pattern. It is
233 aimed at lowering the coupling between the user interface and the business logic
234 and data representation of a program. This also has the added benefit that the
235 business logic could much easier be the target of automated tests, increasing
236 the productivity in the software development process. Refactoring is an
237 important tool on the way to something greater.
239 Another effect of refactoring is that with the increased separation of concerns
240 coming out of many refactorings, the \emph{performance} can be improved. When
241 profiling programs, the problematic parts are narrowed down to smaller parts of
242 the code, which are easier to tune, and optimization can be performed only where
243 needed and in a more effective way.
245 Last, but not least, and this should probably be the best reason to refactor, is
246 to refactor to \emph{facilitate a program change}. If one has managed to keep
247 one's code clean and tidy, and the code is not bloated with design patterns that
248 are not ever going to be needed, then some refactoring might be needed to
249 introduce a design pattern that is appropriate for the change that is going to
252 Refactoring program code --- with a goal in mind --- can give the code itself
253 more value. That is in the form of robustness to bugs, understandability and
254 maintainability. Having robust code is an obvious advantage, but
255 understandability and maintainability are both very important aspects of
256 software development. By incorporating refactoring in the development process,
257 bugs are found faster, new functionality is added more easily and code is easier
258 to understand by the next person exposed to it, which might as well be the
259 person who wrote it. The consequence of this, is that refactoring can increase
260 the average productivity of the development process, and thus also add to the
261 monetary value of a business in the long run. The perspective on productivity
262 and money should also be able to open the eyes of the many nearsighted managers
263 that seldom see beyond the next milestone.
265 \section{The magical number seven}\label{magic_number_seven}
266 The article \emph{The magical number seven, plus or minus two: some limits on
267 our capacity for processing information}\citing{miller1956} by George A.
268 Miller, was published in the journal \emph{Psychological Review} in 1956. It
269 presents evidence that support that the capacity of the number of objects a
270 human being can hold in its working memory is roughly seven, plus or minus two
271 objects. This number varies a bit depending on the nature and complexity of the
272 objects, but is according to Miller ``\ldots never changing so much as to be
275 Miller's article culminates in the section called \emph{Recoding}, a term he
276 borrows from communication theory. The central result in this section is that by
277 recoding information, the capacity of the amount of information that a human can
278 process at a time is increased. By \emph{recoding}, Miller means to group
279 objects together in chunks and give each chunk a new name that it can be
280 remembered by. By organizing objects into patterns of ever growing depth, one
281 can memorize and process a much larger amount of data than if it were to be
282 represented as its basic pieces. This grouping and renaming is analogous to how
283 many refactorings work, by grouping pieces of code and give them a new name.
284 Examples are the fundamental \ExtractMethod and \refactoring{Extract Class}
285 refactorings\citing{refactoring}.
288 \ldots recoding is an extremely powerful weapon for increasing the amount of
289 information that we can deal with.~\cite[p.~95]{miller1956}
292 An example from the article addresses the problem of memorizing a sequence of
293 binary digits. Let us say we have the following sequence\footnote{The example
294 presented here is slightly modified (and shortened) from what is presented in
295 the original article\citing{miller1956}, but it is essentially the same.} of
296 16 binary digits: ``1010001001110011''. Most of us will have a hard time
297 memorizing this sequence by only reading it once or twice. Imagine if we instead
298 translate it to this sequence: ``A273''. If you have a background from computer
299 science, it will be obvious that the latest sequence is the first sequence
300 recoded to be represented by digits with base 16. Most people should be able to
301 memorize this last sequence by only looking at it once.
303 Another result from the Miller article is that when the amount of information a
304 human must interpret increases, it is crucial that the translation from one code
305 to another must be almost automatic for the subject to be able to remember the
306 translation, before \heshe is presented with new information to recode. Thus
307 learning and understanding how to best organize certain kinds of data is
308 essential to efficiently handle that kind of data in the future. This is much
309 like when humans learn to read. First they must learn how to recognize letters.
310 Then they can learn distinct words, and later read sequences of words that form
311 whole sentences. Eventually, most of them will be able to read whole books and
312 briefly retell the important parts of its content. This suggest that the use of
313 design patterns\citing{designPatterns} is a good idea when reasoning about
314 computer programs. With extensive use of design patterns when creating complex
315 program structures, one does not always have to read whole classes of code to
316 comprehend how they function, it may be sufficient to only see the name of a
317 class to almost fully understand its responsibilities.
320 Our language is tremendously useful for repackaging material into a few chunks
321 rich in information.~\cite[p.~95]{miller1956}
324 Without further evidence, these results at least indicate that refactoring
325 source code into smaller units with higher cohesion and, when needed,
326 introducing appropriate design patterns, should aid in the cause of creating
327 computer programs that are easier to maintain and has code that is easier (and
330 \section{Notable contributions to the refactoring literature}
331 \todoin{Update with more contributions}
334 \item[1992] William F. Opdyke submits his doctoral dissertation called
335 \emph{Refactoring Object-Oriented Frameworks}\citing{opdyke1992}. This
336 work defines a set of refactorings, that are behavior preserving given that
337 their preconditions are met. The dissertation is focused on the automation
339 \item[1999] Martin Fowler et al.: \emph{Refactoring: Improving the Design of
340 Existing Code}\citing{refactoring}. This is maybe the most influential text
341 on refactoring. It bares similarities with Opdykes thesis\citing{opdyke1992}
342 in the way that it provides a catalog of refactorings. But Fowler's book is
343 more about the craft of refactoring, as he focuses on establishing a
344 vocabulary for refactoring, together with the mechanics of different
345 refactorings and when to perform them. His methodology is also founded on
346 the principles of test-driven development.
347 \item[2005] Joshua Kerievsky: \emph{Refactoring to
348 Patterns}\citing{kerievsky2005}. This book is heavily influenced by Fowler's
349 \emph{Refactoring}\citing{refactoring} and the ``Gang of Four'' \emph{Design
350 Patterns}\citing{designPatterns}. It is building on the refactoring
351 catalogue from Fowler's book, but is trying to bridge the gap between
352 \emph{refactoring} and \emph{design patterns} by providing a series of
353 higher-level composite refactorings, that makes code evolve toward or away
354 from certain design patterns. The book is trying to build up the readers
355 intuition around \emph{why} one would want to use a particular design
356 pattern, and not just \emph{how}. The book is encouraging evolutionary
357 design. \See{relationToDesignPatterns}
360 \section{Tool support}\label{toolSupport}
362 \subsection{Tool support for Java}
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 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 two kinds of errors that can be made. There
920 are errors that make the code unable to compile, and there are the silent
921 errors, only popping up at runtime. Compile-time errors are the nice ones. They
922 flash up at the moment they are made (at least when using an IDE), and are
923 usually easy to fix. The other kind of error is the dangerous one. It is the
924 kind of error introduced in the example of \myref{correctness}. It is an error
925 sneaking into your code without you noticing, maybe. For discovering those kind
926 of errors when refactoring, it is essential to have good test coverage. It is
927 not a way to \emph{prove} that the code is correct, but it is a way to make you
928 confindent that it \emph{probably} works as desired. In the context of test
929 driven development, the tests are even a way to define how the program is
930 supposed to work. It is then, by definition, working if the tests are passing.
932 If the test coverage for a code base is perfect, then it should, theoretically,
933 be risk-free to perform refactorings on it. This is why tests and refactoring
934 are such a great match.
936 \subsection{Testing the code from correctness section}
938 \section{The project}
939 The aim of this project will be to investigate the relationship between a
940 composite refactoring composed of the \ExtractMethod and \MoveMethod
941 refactorings, and its impact on one or more software metrics.
943 The composition of \ExtractMethod and \MoveMethod springs naturally out of the
944 need to move procedures closer to the data they manipulate. This composed
945 refactoring is not well described in the literature, but it is implemented in at
946 least one tool called
947 \emph{CodeRush}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument3519}},
948 that is an extension for \emph{MS Visual
949 Studio}\footnote{\url{http://www.visualstudio.com/}}. In CodeRush it is called
950 \emph{Extract Method to
951 Type}\footnote{\url{https://help.devexpress.com/\#CodeRush/CustomDocument6710}},
952 but I choose to call it \ExtractAndMoveMethod, since I feel it better
953 communicates which primitive refactorings it is composed of.
955 For the metrics, I will at least measure the \emph{Coupling between object
956 classes} (CBO) metric that is described by Chidamber and Kemerer in their
957 article \emph{A Metrics Suite for Object Oriented
958 Design}\citing{metricsSuite1994}.
960 The project will then consist in implementing the \ExtractAndMoveMethod
961 refactoring, as well as executing it over a larger code base. Then the effect of
962 the change must be measured by calculating the chosen software metrics both
963 before and after the execution. To be able to execute the refactoring
964 automatically I have to make it analyze code to determine the best selections to
965 extract into new methods.
967 \section{Software metrics}
968 \todoin{Is this the appropriate place to have this section?}
971 %\chapter{Planning the project}
979 \section{The problem statement}
980 \section{Choosing the target language}
981 Choosing which programming language to use as the target for manipulation is not
982 a very difficult task. The language has to be an object-oriented programming
983 language, and it must have existing tool support for refactoring. The
984 \emph{Java} programming language\footnote{\url{https://www.java.com/}} is the
985 dominating language when it comes to examples in the literature of refactoring,
986 and is thus a natural choice. Java is perhaps, currently the most influential
987 programming language in the world, with its \emph{Java Virtual Machine} that
988 runs on all of the most popular architectures and also supports\footnote{They
989 compile to java bytecode.} dozens of other programming languages, with
990 \emph{Scala}, \emph{Clojure} and \emph{Groovy} as the most prominent ones. Java
991 is currently the language that every other programming language is compared
992 against. It is also the primary language of the author of this thesis.
994 \section{Choosing the tools}
995 When choosing a tool for manipulating Java, there are certain criterias that
996 have to be met. First of all, the tool should have some existing refactoring
997 support that this thesis can build upon. Secondly it should provide some kind of
998 framework for parsing and analyzing Java source code. Third, it should itself be
999 open source. This is both because of the need to be able to browse the code for
1000 the existing refactorings that is contained in the tool, and also because open
1001 source projects hold value in them selves. Another important aspect to consider
1002 is that open source projects of a certain size, usually has large communities of
1003 people connected to them, that are commited to answering questions regarding the
1004 use and misuse of the products, that to a large degree is made by the cummunity
1007 There is a certain class of tools that meet these criterias, namely the class of
1008 \emph{IDEs}\footnote{\emph{Integrated Development Environment}}. These are
1009 proagrams that is ment to support the whole production cycle of a cumputer
1010 program, and the most popular IDEs that support Java, generally have quite good
1011 refactoring support.
1013 The main contenders for this thesis is the \emph{Eclipse IDE}, with the
1014 \emph{Java development tools} (JDT), the \emph{IntelliJ IDEA Community Edition}
1015 and the \emph{NetBeans IDE}. \See{toolSupport} Eclipse and NetBeans are both
1016 free, open source and community driven, while the IntelliJ IDEA has an open
1017 sourced community edition that is free of charge, but also offer an
1018 \emph{Ultimate Edition} with an extended set of features, at additional cost.
1019 All three IDEs supports adding plugins to extend their functionality and tools
1020 that can be used to parse and analyze Java source code. But one of the IDEs
1021 stand out as a favorite, and that is the \emph{Eclipse IDE}. This is the most
1022 popular\citing{javaReport2011} among them and seems to be de facto standard IDE
1023 for Java development regardless of platform.
1026 \chapter{Refactorings in Eclipse JDT: Design, Shortcomings and Wishful
1027 Thinking}\label{ch:jdt_refactorings}
1029 This chapter will deal with some of the design behind refactoring support in
1030 Eclipse, and the JDT in specific. After which it will follow a section about
1031 shortcomings of the refactoring API in terms of composition of refactorings. The
1032 chapter will be concluded with a section telling some of the ways the
1033 implementation of refactorings in the JDT could have worked to facilitate
1034 composition of refactorings.
1037 The refactoring world of Eclipse can in general be separated into two parts: The
1038 language independent part and the part written for a specific programming
1039 language -- the language that is the target of the supported refactorings.
1040 \todo{What about the language specific part?}
1042 \subsection{The Language Toolkit}
1043 The Language Toolkit, or LTK for short, is the framework that is used to
1044 implement refactorings in Eclipse. It is language independent and provides the
1045 abstractions of a refactoring and the change it generates, in the form of the
1046 classes \typewithref{org.eclipse.ltk.core.refactoring}{Refactoring} and
1047 \typewithref{org.eclipse.ltk.core.refactoring}{Change}. (There is also parts of
1048 the LTK that is concerned with user interaction, but they will not be discussed
1049 here, since they are of little value to us and our use of the framework.)
1051 \subsubsection{The Refactoring Class}
1052 The abstract class \type{Refactoring} is the core of the LTK framework. Every
1053 refactoring that is going to be supported by the LTK have to end up creating an
1054 instance of one of its subclasses. The main responsibilities of subclasses of
1055 \type{Refactoring} is to implement template methods for condition checking
1056 (\methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkInitialConditions}
1058 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{checkFinalConditions}),
1060 \methodwithref{org.eclipse.ltk.core.refactoring.Refactoring}{createChange}
1061 method that creates and returns an instance of the \type{Change} class.
1063 If the refactoring shall support that others participate in it when it is
1064 executed, the refactoring has to be a processor-based
1065 refactoring\typeref{org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring}.
1066 It then delegates to its given
1067 \typewithref{org.eclipse.ltk.core.refactoring.participants}{RefactoringProcessor}
1068 for condition checking and change creation.
1070 \subsubsection{The Change Class}
1071 This class is the base class for objects that is responsible for performing the
1072 actual workspace transformations in a refactoring. The main responsibilities for
1073 its subclasses is to implement the
1074 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{perform} and
1075 \methodwithref{org.eclipse.ltk.core.refactoring.Change}{isValid} methods. The
1076 \method{isValid} method verifies that the change object is valid and thus can be
1077 executed by calling its \method{perform} method. The \method{perform} method
1078 performs the desired change and returns an undo change that can be executed to
1079 reverse the effect of the transformation done by its originating change object.
1081 \subsubsection{Executing a Refactoring}\label{executing_refactoring}
1082 The life cycle of a refactoring generally follows two steps after creation:
1083 condition checking and change creation. By letting the refactoring object be
1085 \typewithref{org.eclipse.ltk.core.refactoring}{CheckConditionsOperation} that
1086 in turn is handled by a
1087 \typewithref{org.eclipse.ltk.core.refactoring}{CreateChangeOperation}, it is
1088 assured that the change creation process is managed in a proper manner.
1090 The actual execution of a change object has to follow a detailed life cycle.
1091 This life cycle is honored if the \type{CreateChangeOperation} is handled by a
1092 \typewithref{org.eclipse.ltk.core.refactoring}{PerformChangeOperation}. If also
1093 an undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} is set
1094 for the \type{PerformChangeOperation}, the undo change is added into the undo
1097 \section{Shortcomings}
1098 This section is introduced naturally with a conclusion: The JDT refactoring
1099 implementation does not facilitate composition of refactorings.
1100 \todo{refine}This section will try to explain why, and also identify other
1101 shortcomings of both the usability and the readability of the JDT refactoring
1104 I will begin at the end and work my way toward the composition part of this
1107 \subsection{Absence of Generics in Eclipse Source Code}
1108 This section is not only concerning the JDT refactoring API, but also large
1109 quantities of the Eclipse source code. The code shows a striking absence of the
1110 Java language feature of generics. It is hard to read a class' interface when
1111 methods return objects or takes parameters of raw types such as \type{List} or
1112 \type{Map}. This sometimes results in having to read a lot of source code to
1113 understand what is going on, instead of relying on the available interfaces. In
1114 addition, it results in a lot of ugly code, making the use of typecasting more
1115 of a rule than an exception.
1117 \subsection{Composite Refactorings Will Not Appear as Atomic Actions}
1119 \subsubsection{Missing Flexibility from JDT Refactorings}
1120 The JDT refactorings are not made with composition of refactorings in mind. When
1121 a JDT refactoring is executed, it assumes that all conditions for it to be
1122 applied successfully can be found by reading source files that has been
1123 persisted to disk. They can only operate on the actual source material, and not
1124 (in-memory) copies thereof. This constitutes a major disadvantage when trying to
1125 compose refactorings, since if an exception occur in the middle of a sequence of
1126 refactorings, it can leave the project in a state where the composite
1127 refactoring was executed only partly. It makes it hard to discard the changes
1128 done without monitoring and consulting the undo manager, an approach that is not
1131 \subsubsection{Broken Undo History}
1132 When designing a composed refactoring that is to be performed as a sequence of
1133 refactorings, you would like it to appear as a single change to the workspace.
1134 This implies that you would also like to be able to undo all the changes done by
1135 the refactoring in a single step. This is not the way it appears when a sequence
1136 of JDT refactorings is executed. It leaves the undo history filled up with
1137 individual undo actions corresponding to every single JDT refactoring in the
1138 sequence. This problem is not trivial to handle in Eclipse.
1139 \See{hacking_undo_history}
1141 \section{Wishful Thinking}
1144 \chapter{Composite Refactorings in Eclipse}
1146 \section{A Simple Ad Hoc Model}
1147 As pointed out in \myref{ch:jdt_refactorings}, the Eclipse JDT refactoring model
1148 is not very well suited for making composite refactorings. Therefore a simple
1149 model using changer objects (of type \type{RefaktorChanger}) is used as an
1150 abstraction layer on top of the existing Eclipse refactorings.
1152 \section{The Extract and Move Method Refactoring}
1153 %The Extract and Move Method Refactoring is implemented mainly using these
1156 % \item \type{ExtractAndMoveMethodChanger}
1157 % \item \type{ExtractAndMoveMethodPrefixesExtractor}
1158 % \item \type{Prefix}
1159 % \item \type{PrefixSet}
1162 \subsection{The Building Blocks}
1163 This is a composite refactoring, and hence is built up using several primitive
1164 refactorings. These basic building blocks are, as its name implies, the
1165 \ExtractMethod refactoring\citing{refactoring} and the \MoveMethod
1166 refactoring\citing{refactoring}. In Eclipse, the implementations of these
1167 refactorings are found in the classes
1168 \typewithref{org.eclipse.jdt.internal.corext.refactoring.code}{ExtractMethodRefactoring}
1170 \typewithref{org.eclipse.jdt.internal.corext.refactoring.structure}{MoveInstanceMethodProcessor},
1171 where the last class is designed to be used together with the processor-based
1172 \typewithref{org.eclipse.ltk.core.refactoring.participants}{MoveRefactoring}.
1174 \subsubsection{The ExtractMethodRefactoring Class}
1175 This class is quite simple in its use. The only parameters it requires for
1176 construction is a compilation
1177 unit\typeref{org.eclipse.jdt.core.ICompilationUnit}, the offset into the source
1178 code where the extraction shall start, and the length of the source to be
1179 extracted. Then you have to set the method name for the new method together with
1180 which access modifier that shall be used and some not so interesting parameters.
1182 \subsubsection{The MoveInstanceMethodProcessor Class}
1183 For the Move Method the processor requires a little more advanced input than
1184 the class for the Extract Method. For construction it requires a method
1185 handle\typeref{org.eclipse.jdt.core.IMethod} from the Java Model for the method
1186 that is to be moved. Then the target for the move have to be supplied as the
1187 variable binding from a chosen variable declaration. In addition to this, one
1188 have to set some parameters regarding setters/getters and delegation.
1190 To make a whole refactoring from the processor, one have to construct a
1191 \type{MoveRefactoring} from it.
1193 \subsection{The ExtractAndMoveMethodChanger Class}
1194 The \typewithref{no.uio.ifi.refaktor.changers}{ExtractAndMoveMethodChanger}
1195 class, that is a subclass of the class
1196 \typewithref{no.uio.ifi.refaktor.changers}{RefaktorChanger}, is the class
1197 responsible for composing the \type{ExtractMethodRefactoring} and the
1198 \type{MoveRefactoring}. Its constructor takes a project
1199 handle\typeref{org.eclipse.core.resources.IProject}, the method name for the new
1200 method and a \typewithref{no.uio.ifi.refaktor.utils}{SmartTextSelection}.
1202 A \type{SmartTextSelection} is basically a text
1203 selection\typeref{org.eclipse.jface.text.ITextSelection} object that enforces
1204 the providing of the underlying document during creation. I.e. its
1205 \methodwithref{no.uio.ifi.refaktor.utils.SmartTextSelection}{getDocument} method
1206 will never return \type{null}.
1208 Before extracting the new method, the possible targets for the move operation is
1209 found with the help of an
1210 \typewithref{no.uio.ifi.refaktor.extractors}{ExtractAndMoveMethodPrefixesExtractor}.
1211 The possible targets is computed from the prefixes that the extractor returns
1213 \methodwithref{no.uio.ifi.refaktor.extractors.ExtractAndMoveMethodPrefixesExtractor}{getSafePrefixes}
1214 method. The changer then choose the most suitable target by finding the most
1215 frequent occurring prefix among the safe ones. The target is the type of the
1216 first part of the prefix.
1218 After finding a suitable target, the \type{ExtractAndMoveMethodChanger} first
1219 creates an \type{ExtractMethodRefactoring} and performs it as explained in
1220 \myref{executing_refactoring} about the execution of refactorings. Then it
1221 creates and performs the \type{MoveRefactoring} in the same way, based on the
1222 changes done by the Extract Method refactoring.
1224 \subsection{The ExtractAndMoveMethodPrefixesExtractor Class}
1225 This extractor extracts properties needed for building the Extract and Move
1226 Method refactoring. It searches through the given selection to find safe
1227 prefixes, and those prefixes form a base that can be used to compute possible
1228 targets for the move part of the refactoring. It finds both the candidates, in
1229 the form of prefixes, and the non-candidates, called unfixes. All prefixes (and
1230 unfixes) are represented by a
1231 \typewithref{no.uio.ifi.refaktor.extractors}{Prefix}, and they are collected
1232 into prefix sets.\typeref{no.uio.ifi.refaktor.extractors.PrefixSet}.
1234 The prefixes and unfixes are found by property
1235 collectors\typeref{no.uio.ifi.refaktor.extractors.collectors.PropertyCollector}.
1236 A property collector follows the visitor pattern\citing{designPatterns} and is
1237 of the \typewithref{org.eclipse.jdt.core.dom}{ASTVisitor} type. An
1238 \type{ASTVisitor} visits nodes in an abstract syntax tree that forms the Java
1239 document object model. The tree consists of nodes of type
1240 \typewithref{org.eclipse.jdt.core.do}{ASTNode}.
1242 \subsubsection{The PrefixesCollector}
1243 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{PrefixesCollector}
1244 is of type \type{PropertyCollector}. It visits expression
1245 statements\typeref{org.eclipse.jdt.core.dom.ExpressionStatement} and creates
1246 prefixes from its expressions in the case of method invocations. The prefixes
1247 found is registered with a prefix set, together with all its sub-prefixes.
1248 \todo{Rewrite in the case of changes to the way prefixes are found}
1250 \subsubsection{The UnfixesCollector}
1251 The \typewithref{no.uio.ifi.refaktor.extractors.collectors}{UnfixesCollector}
1252 finds unfixes within the selection. An unfix is a name that is assigned to
1253 within the selection. The reason that this cannot be allowed, is that the result
1254 would be an assignment to the \type{this} keyword, which is not valid in Java.
1256 \subsubsection{Computing Safe Prefixes}
1257 A safe prefix is a prefix that does not enclose an unfix. A prefix is enclosing
1258 an unfix if the unfix is in the set of its sub-prefixes. As an example,
1259 \texttt{``a.b''} is enclosing \texttt{``a''}, as is \texttt{``a''}. The safe
1260 prefixes is unified in a \type{PrefixSet} and can be fetched calling the
1261 \method{getSafePrefixes} method of the
1262 \type{ExtractAndMoveMethodPrefixesExtractor}.
1264 \subsection{The Prefix Class}
1266 \subsection{The PrefixSet Class}
1268 \subsection{Hacking the Refactoring Undo
1269 History}\label{hacking_undo_history}
1270 \todo{Where to put this section?}
1272 As an attempt to make multiple subsequent changes to the workspace appear as a
1273 single action (i.e. make the undo changes appear as such), I tried to alter
1274 the undo changes\typeref{org.eclipse.ltk.core.refactoring.Change} in the history
1275 of the refactorings.
1277 My first impulse was to remove the, in this case, last two undo changes from the
1278 undo manager\typeref{org.eclipse.ltk.core.refactoring.IUndoManager} for the
1279 Eclipse refactorings, and then add them to a composite
1280 change\typeref{org.eclipse.ltk.core.refactoring.CompositeChange} that could be
1281 added back to the manager. The interface of the undo manager does not offer a
1282 way to remove/pop the last added undo change, so a possible solution could be to
1283 decorate\citing{designPatterns} the undo manager, to intercept and collect the
1284 undo changes before delegating to the \method{addUndo}
1285 method\methodref{org.eclipse.ltk.core.refactoring.IUndoManager}{addUndo} of the
1286 manager. Instead of giving it the intended undo change, a null change could be
1287 given to prevent it from making any changes if run. Then one could let the
1288 collected undo changes form a composite change to be added to the manager.
1290 There is a technical challenge with this approach, and it relates to the undo
1291 manager, and the concrete implementation
1292 UndoManager2\typeref{org.eclipse.ltk.internal.core.refactoring.UndoManager2}.
1293 This implementation is designed in a way that it is not possible to just add an
1294 undo change, you have to do it in the context of an active
1295 operation\typeref{org.eclipse.core.commands.operations.TriggeredOperations}.
1296 One could imagine that it might be possible to trick the undo manager into
1297 believing that you are doing a real change, by executing a refactoring that is
1298 returning a kind of null change that is returning our composite change of undo
1299 refactorings when it is performed.
1301 Apart from the technical problems with this solution, there is a functional
1302 problem: If it all had worked out as planned, this would leave the undo history
1303 in a dirty state, with multiple empty undo operations corresponding to each of
1304 the sequentially executed refactoring operations, followed by a composite undo
1305 change corresponding to an empty change of the workspace for rounding of our
1306 composite refactoring. The solution to this particular problem could be to
1307 intercept the registration of the intermediate changes in the undo manager, and
1308 only register the last empty change.
1310 Unfortunately, not everything works as desired with this solution. The grouping
1311 of the undo changes into the composite change does not make the undo operation
1312 appear as an atomic operation. The undo operation is still split up into
1313 separate undo actions, corresponding to the change done by its originating
1314 refactoring. And in addition, the undo actions has to be performed separate in
1315 all the editors involved. This makes it no solution at all, but a step toward
1318 There might be a solution to this problem, but it remains to be found. The
1319 design of the refactoring undo management is partly to be blamed for this, as it
1320 it is to complex to be easily manipulated.
1324 \chapter{Related Work}
1326 \section{The compositional paradigm of refactoring}
1327 This paradigm builds upon the observation of Vakilian et
1328 al.\citing{vakilian2012}, that of the many automated refactorings existing in
1329 modern IDEs, the simplest ones are dominating the usage statistics. The report
1330 mainly focuses on \emph{Eclipse} as the tool under investigation.
1332 The paradigm is described almost as the opposite of automated composition of
1333 refactorings \see{compositeRefactorings}. It works by providing the programmer
1334 with easily accessible primitive refactorings. These refactorings shall be
1335 accessed via keyboard shortcuts or quick-assist menus\footnote{Think
1336 quick-assist with Ctrl+1 in Eclipse} and be promptly executed, opposed to in the
1337 currently dominating wizard-based refactoring paradigm. They are ment to
1338 stimulate composing smaller refactorings into more complex changes, rather than
1339 doing a large upfront configuration of a wizard-based refactoring, before
1340 previewing and executing it. The compositional paradigm of refactoring is
1341 supposed to give control back to the programmer, by supporting \himher with an
1342 option of performing small rapid changes instead of large changes with a lesser
1343 degree of control. The report authors hope this will lead to fewer unsuccessful
1344 refactorings. It also could lower the bar for understanding the steps of a
1345 larger composite refactoring and thus also help in figuring out what goes wrong
1346 if one should choose to op in on a wizard-based refactoring.
1348 Vakilian and his associates have performed a survey of the effectiveness of the
1349 compositional paradigm versus the wizard-based one. They claim to have found
1350 evidence of that the \emph{compositional paradigm} outperforms the
1351 \emph{wizard-based}. It does so by reducing automation, which seem
1352 counterintuitive. Therefore they ask the question ``What is an appropriate level
1353 of automation?'', and thus questions what they feel is a rush toward more
1354 automation in the software engineering community.