Assessing the Quality of Refactoring Patterns forIntroducing Design Patterns
Masatomo Yoshida, Norihiro Yoshida, Katsuro Inoue
Graduate School of Information Science and Technorogy, Osaka University
1-3, Machikaneyama-cho, Toyonaka, Osaka, 560-8531, Japan{mstm-ysd, n-yosida, inoue}@ist.osaka-u.ac.jp
ABSTRACT
Refactoring is a well-known process to improve the code design of object-oriented programs. Recently, several literatures focus on refactoring with introducing design patterns
that are general repeated solutions to common problems insoftware design. For making it easy to perform such refactoring, a lot of refactoring patterns are proposed. Each refactoring pattern includes a description of refactoring opportunities (i.e., when a software system should be performed
refactoring with introducing design patterns) and the corresponding procedure (i.e., how to perform refactoring withintroducing design patterns). However, the usefulness ofeach refactoring pattern is not clearly assessed. This paper
describes our approach to assess the quality of refactoring
patterns for introducing design patterns and also shows theassessment of open source software.

Categories and Subject Descriptors
D.2.7 [Software Engineering]: Distribution, Maitenance,and Enhancement—Restructuring, reverse engineering, andreengineering; D.2.2 [Software Engineering]: Design Tools
and Techniques—Object-oriented design methods; D.3.3 [Programming Languages]: Language Constructs and Features—Patterns

General Terms
Design, Languages, Experimentation

Keywords
Quality assessment, Refactoring pattern, Design pattern

introducing DPs can improve design quality of maintaining
software systems that lack of application of DPs[5, 8]. For
making it easy to perform such refactoring, Kerievsky proposed 27 refactoring patterns[5]. Each refactoring pattern
includes a description of refactoring opportunities (i.e., whena software system should be performed refactoring with introducing DPs) and the corresponding procedure (i.e., how
to perform refactoring with introducing DPs).
However, the quality of each refactoring pattern is not clearly
assessed. We can not determine which refactoring patterns
should be given priority to apply. Also, we do not knowwhether it is easy to apply each refactoring pattern.

P1 How many refactoring opportunities are involved in software systems?
P2 Is it easy to perform refactoring to those opportunities?

In this paper, we propose an approach based on above points
to assess the quality of refactoring patterns introducing DPs.
First of all, we brieﬂy explain about refactoring with introducing DPs. Then we propose a plan for assessing thequality of such refactoring patterns and present an automated tool that identiﬁes opportunities for applying one of
the refactoring patterns described in Kerievsky’s book[5].
Finally, we show a case study of Open Source Software (OSS)
and discuss P1 and P2. In the case study, we identify suchopportunities in OSS by using that automated tool and perform refactoring to those opportunities.

1. INTRODUCTION
Refactoring[2] is the process of changing a software systemin such a way that it does not alter the external behaviorof the code yet improves its internal structure. Recently,
several literatures focus on refactoring with introducing Design Patterns (DPs)[3] that are general repeated solutions
to common problems in software design. Refactoring with2.

REFACTORING WITH INTRODUCINGDESIGN PATTERNSKerievsky made a catalogue of refactorings introducing Design Patterns (DPs)[5]. His catalogue includes 27 pairs of a
description of a refactoring opportunity and the corresponding procedure for performing refactorings introducing a DP.
Here, as an example, we explain the refactoring is called
Introduce Polymorphic Creation with Factory Method described in his catalogue. The refactoring opportunity in his
catalogue is deﬁned as “Classes in a hierarchy implement a
method similarly except for an object creation step”. Similar
method can be called code clone[1, 4] or duplicated code[2].
Code clone is generally considered as one of factors thatmake software maintenance more diﬃcult[1, 4].

junit::framework::TestCase

DOMBuilderTest

XMLBuilderTest+testAddAboveRoot() : void+testAddAboveRoot() : void・・・
builder = new DOMBuilder(“orders”);
・・・

is closely related to the usefulness of a refactoring pattern for the system. Therefore, we assess the numberof refactoring opportunities in a software system. The
assessment requires an automated tool that identiﬁes
opportunities for refactoring. For our case study, we
have developed the tool that identiﬁes opportunitiesfor the refactoring described in section 2. The detailof the tool is introduced in section 4.

・・・
builder = new XMLBuilder(“orders”);
・・・

Similar methods (Code clones)• Ease of Refactoring: The major purpose of refactoring is to reduce maintenance cost[2]. Therefore, if
it is too costly to apply a refactoring pattern, it is notdesirable to perform the refactoring[6]. In our plan,
we assess the ease of applying each refactoring pattern. For each performed refactoring, we conﬁrm theperformed procedures other than which are describedin Kerievsky’s book[5].

(a) Before refactoring
junit::framework::TestCase
Factory Method: Creator

AbstractBuilderTest#builder: OutputBuilder#createBuilder(rootName : String) : OutputBuilder+testAddAboveRoot() : void・・・
builder = createBuilder(“orders”);
・・・

4.

Factory Method: ConcreteCreator
DOMBuilderTest

XMLBuilderTest#createBuilder(rootName:String): OutputBuilder#createBuilder(rootName:String): OutputBuilder

return new DOMBuilder(rootName);

return new XMLBuilder(rootName);

AUTOMATION OF IDENTIFYING OPPORTUNITIESFor our case study, we have developed the tool that identiﬁes opportunities for Introduce Polymorphic Creation with
Factory Method described in section 2.

(b) After refactoring
Figure 1: Introduce Polymorphic Creation with Factory Method

Figure 1 shows an example of the refactoring described in hiscatalogue. As shown in Figure 1(a), the targets of the refactoring are test classes DOMBuilderTest and XMLBuilderTest
for DOMBuilder and XMLBuilder, respectively. Because target classes have similar methods except for an object creation step, they imply the opportunity for Introduce Polymorphic Creation with Factory Method. This refactoring iscomprised of following two steps.
Step1 As shown in Figure 1(b), a common superclass (AbstractBuilderTest) for the target classes is introduced,and similar methods in the target classes are merged
into new method in the common superclass.
Step2 A Factory Method[3] is introduced in each of thecommon superclass (AbstractBuilderTest) and the subclasses (DOMBuilderTest and XMLBuilderTest). Factory Method means a method is primarily intended tocreate an object.
Because of removing code duplication and introducing Factory Method, it is easier to add new test class as a subclassof AbstractBuilderTest than before.

3. ASSESSMENT PLAN

According to Kerievsky’s book, to identify code shown in
Figure 1(a), the automated method has to ﬁnd code thatsatisﬁes the following conditions:
C1 Similar methods belong to classes have common parentclasses
C2 Only diﬀerence among similar methods is an object creation step
Figure 1 is a special case of Form Template Method Refactoring[2], thus we presented C1. C2 is presented for introducing Factory Method[3]. The automated tool judges thoseconditions by the steps below.
Step1 Detect similar methods using a code clone detection
tool CCFinder[4].
Step2 Evaluate whether detected methods belong to classes
that have common superclasses and whether they include object creation statements.

5.

CASE STUDY

We present a case study as an example of implementing ourplan. In our case study, we identify Introduce Polymorphic
Creation with Factory Method in Open Source Software byusing the tool described in section 4, and then perform refactoring to those opportunities. The target software systems
are ANTLR, Ant and Azureus which are written in Java.

The aim of our plan is to assess the quality of each refactoring pattern introducing Design Patterns (DPs). In our plan,
we assess the following points for each refactoring pattern.

Table 1 shows the numbers of refactoring opportunities ineach target system. We could conﬁrm that a system, whichis comprised of relatively large number of classes, has a tendency to involve a lot of opportunities.

• Number of Refactoring Opportunities: The number of refactoring opportunities in a software system

Figure 2 shows the performed refactoring in ANTLR. This
refactoring needs for additional procedure other than that

CodeGenerator
CSharpCodeGenerator

CppCodeGenerator#processActionFor
SpecialSymbols(...)#processActionFor
SpecialSymbols(...)

JavaCodeGenerator#processActionFor
SpecialSymbols(...)

・・・
antlr.actions.csharp.ActionLexer lexer =new antlr.actions.csharp.ActionLexer(…);
・・・
・・・
antlr.actions.cpp.ActionLexer lexer =new antlr.actions.cpp.ActionLexer(…);
・・・
・・・
antlr.actions.java.ActionLexer lexer =new antlr.actions.java.ActionLexer(…);
・・・

Similar Methods(Code Clones)(a) Before refactoring
CodeGenerator#createActionLexer(...): antlr.actions.OOActionLexer#processActionFor
SpecialSymbols(...)
Factory Method:
ConcreteCreator
CSharpCodeGenerator

Factory Method: Creator・・・
antlr.actions.OOActionLexer
lexer = createActionLexer(…);
・・・

CppCodeGenerator

JavaCodeGenerator#createActionLexer(...) #createActionLexer(...) #createActionLexer(...)
return new
antlr.actions.csharp.ActionLexer(…);
return new antlr.actions.cpp.ActionLexer(…);
return new antlr.actions.java.ActionLexer(…);(b) After refactoring
Figure 2: Refactoring in ANTLR

describe in Kerievsky’s book[5]. In Figure 2(a), three typesof the created objects (i.e. antlr.action.csharp.ActionLexer,
antlr.action.cpp.ActionLexer and antlr.action.java.ActionLexer)
do not have any common superclass or superinterface in target source code. In this situation, we can not introduce a
Factory Method in each class because it is not able to determine appropriate return type of each Factory Method. To
break this situation, we created the antlr.action.OOActionLexer
interface as the common superinterface of those types. Then
we introduced a Factory Method (i.e. createActionLexer)that returns antlr.action.OOActionLexer in each class (Figure 2(b)).

6. DISCUSSION
Table 1: The target software systems
Name
LOC #classes #opportunities
ANTLR 2.7.4
47K
285
1
Ant 1.7.0
20K
778
2Azureus 3.0.3.4 538K
2226
14

Each target system has at least one opportunity for Introduce Polymorphic Creation with Factory Method refactoring.
Especially, Azureus has 14 opportunities.
On the other hand, the refactoring is shown in Figure 2
needs for the introduction of new interface other than that
describe in Kerievsky’s book[5]. That is to say, we conﬁrmed
this refactoring pattern has low ease of refactoring if typesof the created objects do not have any common superclassor superinterface in target source code.

7.

CONCLUSION

In this paper, we proposed an approach based on above
points to assess the quality of refactoring patterns introducing DPs. We proposed a plan for assessing the quality ofsuch refactoring patterns and presented an automated toolthat identiﬁes opportunities for applying the Introduce Polymorphic Creation with Factory Method pattern. Also, we
showed a case study of ANTLR, ANT and Azureus, and thendiscussed the quality of the pattern regarding the numberof refactoring opportunities and the ease of refactoring.
We are planning to assess the other refactoring patterns,
such as Replace One/Many Distinctions with Composite andEncapsulate Composite with Builder. We believe that it isable to detect several opportunities for applying the refactoring patterns based on code clone detection or design patterndetection [7, 9].

Acknowledgments
This reseach was supported by JSPS, Grant-in-Aid for Scientiﬁc Research (A) (No.17200001).

8.

REFERENCES[1] B. S. Baker. Finding clones with Dup: Analysis of anexperiment. IEEE Trans. Sofw. Eng., 33(9):608–621,
2007.
[2] M. Fowler. Refactoring: improving the design ofexisting code. Addison Wesley, 1999.
[3] E. Gamma, R. Helm, R. Johnson, and J. M. Vlissides.
Design Patterns: Elements of Reusable Object-OrientedSoftware. Addison Wesley, 1995.
[4] T. Kamiya, S. Kusumoto, and K. Inoue. CCFinder: A
multilinguistic token-based code clone detection system
for large scale source code. IEEE Trans. Sofw. Eng.,
28(7):654–670, 2002.
[5] J. Kerievsky. Refactoring to Patterns. Addison Wesley,2004.
[6] R. Leitch and E. Stroulia. Assessing the maintainability
beneﬁts of design restructuring using dependency
analysis. In Proc. of METRICS 2003, pages 309–322,2003.
[7] J. Niere, W. Schäfer, J. P. Wadsack, L. Wendehals, andJ. Welsh. Towards pattern-based design recovery. InProc. of ICSE 2002, pages 338–348, 2002.
[8] J. Rajesh and D. Janakiram. JIAD: A tool to infer
design patterns in refactoring. In Proc. of PPDP 2004,pages 227–237, 2004.
[9] N. Tsantalis, A. Chatzigeorgiou, G. Stephanides, andS. T. Halkidis. Design pattern detection using similarity
scoring. IEEE Trans. Sofw. Eng., 32(11):896–909, 2006.