Design Patterns And Refactoring

Abstract

A wealth of knowledge has been (and is still being) captured using design patterns. On the other hand we can observe that merciless refactoring leads to the minimal amount of code or in other words to the minimal design.

What Is A Design Pattern?

There are several definitions available, so I do not want to "entertain" you with all of them. As a working model for this article we may use this one: "A design pattern is the description of a design problem and of its solution, which comes with certain benefits and liabilities."

Mental Models

I use the term mental model for how we perceive reality. For instance, if you are working in an asset management department, you will describe a chair using terms such as current value or depreciation. Opposed to that think about the perspective of a person, who is responsible for ergonomics. The latter will probably use terms such as height or the shape of the chair.

The same applies to processes. If we look at design patterns and refactoring, an interesting question is, whether design patterns drive refactoring or whether refactoring is done and design patterns are discovered only by then in the refactoring result.

This is at the core of this article.

Detecting Design Patterns After Refactoring

While working on our projects we have found many cases where we detected design patterns after we had refactored mercilessly. The good thing is that these discoveries increased our confidence in our design.

However, the discovery also made us think. Could it be that we should be able to use existing and documented design patterns? And if so, what does it mean? If we knew a design pattern, does it help us to detect a better refactoring? Or is the only role of design patterns with regards to refactoring, that we can describe our observations?

Do Design Patterns Drive Refactoring?

Whether design patterns drive refactoring is not easy to answer. On the other hand, if you look at the wealth, which is provided by all the literature about design patterns, it would be extremely helpful, if we could find a way.

For now our working model is, that yes, design patterns help. The provide us with a rich set of possible solutions for design decisions at hand. In conjunction with known refactorings, we feel that it is easier to assess the possible impacts (for good and for bad) of a particular refactoring.

Issues

As we sense that there should be a better answer to this whole topic, we have started activities to investigate this problem in more details. It seems important to me, that we also get more people involed from both the design pattern movement and the XP community. One of these activities is a workshop we plan to run at the XP 2002 conference.

Related Work

Martin Fowlers book on refactoring contains more material on this topic. Also, you can find a paper published in the PLOPD 1 book, with related material.

Tips

• Read papers on design patterns. Prefer papers that have been peer-reviewd at a conference of the PLOP series.
• When refactoring try to discover design patterns. If you detect a design pattern assess its benefit, but also their liabilities.