Refactoring and Design Patterns – Does Order Matter?
Authors
Andreas Weiss
Gemplus GmbH, Software Technology Lab
Otto-Lilienthal-Strasse 36
71034 Boeblingen
Germany
andreas.weiss1@web.de
Manfred Lange
Gemplus GmbH, Software Technology Lab
Otto-Lilienthal-Strass 36
71034 Boeblingen
Germany
Manfred_Lange@acm.org
http://www.manfred-lange.com -orhttp://www.xpexchange.net
Abstract
Refactoring is an important activity of Extreme Programming (XP). On the other hand
there is a wealth of work documented in the form of design patterns. While design
patterns tend to favor higher levels of abstractions – not only for design or
implementation of software, XP promote pragmatic, simplicity-driven solutions, which
can frequently take on an ad-hoc character. In the context of the already available work,
this paper tries to shed some light on the relation between refactoring and design patterns.
Keywords
Refactoring - Design Patterns
Context
Papers and books on patterns contain a huge amount of material, covering many aspects
including but not limited to machine language programming, to analysis, to
organizational issues, to social processes in teams. For the course of this paper we would
like to focus on design patterns.
In order to set the stage, we first define some terms.
Pattern
For the course of this paper we define a pattern as a problem-solution pair in a specific
context, defined by influencing forces.
Design
What, however, is a design pattern? We think that it would be useful to have a definition
of the term “design”.
Refactoring
To do
Samples
“Browser Filter”
-
Evolution of design
Result: application of “Strategy” pattern
“Notes Table”
-
Upfront design versus evolutionary design
Only one class needed
Used pattern:
o Visitor?
o Decorator?
o Adaptor?
“Permissions and Users”
-
start is much simpler than upfront design
o right now only one step is needed
However: how to decide?
Pattern is unknown yet
Refactoring
-
-
-
It is possible to have multiple ways
o How to decide which one to choose, e.g. “Extract Class” versus “Extract
Method”, as Martin Fowler gives no indication on that one.
 Decision criteria
o Do we always end up having the same solution?
As opposed to implementation: the latter is only “making it work”
What is the influence of the programming language on the set of applicable
refactorings?
o Multiple inheritance
o C++ templates
When are we done with merciless refactoring?
o Criteria
 OAOO
 TSTTCPW
 YAGNI
o Can everything be treated to be in maintenance mode?
 Is “Browser Filter” really the ultimate design? Will it be refactored
again?
 “Permissions and Users” sample: Design is just at the beginning.
What kind of patterns will we ultimately have?

-
How can we determine which pattern we should apply, if
we don’t know which requirements (user stories) we will
have tomorrow?
Some big refactorings are just too big, e.g.
o “Tease apart inheritance”
 Works fine with few classes with nice names
 Programmer possibly does not see this possibility, because of the
amount of code/files/methods/classes involved.
Related Work
-
Pattern community
o Existing papers
Martin Fowler: “Is Design Dead?”
Relation Refactoring <-> Design Patterns
-
-
Will patterns be applied in order to refactor code?
Will patterns emerge as a result of refactoring?
o Do they just wait to be discovered?
o Are patterns there because sound refactorings implicitly or unconsciously
use design patterns? Is it just the natural way of removing “bad smells”,
and some people have done this long before the term “refactoring” has
been coined?