OO Refactoring and Design Patterns Research

I teach an undergraduate course on Software Design, and a good part of that course deals with different forms of design patterns and refactorings.  Personally, I am unsatisfied with the 'practical' state of classical design patterns and existing tool support.  Eclipse, for instance, is awful IMO on the refactorings that it offers (the JDTRE -- or JDT Refactoring Engine)  is infested with bugs) and the lack of support to script refactorings.  I was tired of handwaiving descriptions of design patterns and what specific refactorings should do, but don't.  I wanted to change the way OO refactorings and classical design patterns are taught to students.

I think of it this way:  I was in college when students stopped using slide rules and transitioned to hand-held calculators.  Back then, you performed one computation at a time.  I used an HP-45.  It was but a year or so afterwards that the first programmable calculator appeared -- because people obviously wanted to perform a series of well-defined computations repeatedly, and programs were the way to go. Well, it has been known for 10-15 years (see Kerievsky2006, Tokuda and Batory1999) that most, not all, classical design patterns in the Gang-of-Four Text can implemented as refactoring scripts -- a sequence, including loops, of refactorings.  Others have long noted before us that scripting refactorings is an important step forward in IDE capabilities, but nothing much has happened.  Students and programmers do not want to learn a domain-specific languages, program transformation systems, and/or IDE development kits to write refactoring scripts.  Here's where I found teaching and research come together nicely.

We (Jongwook Kim, Danny Dig, and I) have been working on a new technology to add refactoring scripts to IDEs, in particular Eclipse.  Our work is long-term, and below I describe our current (but not future) work on the subject.  R2 and R3 below are now integrated into my undergraduate Software Design and my graduate course on Automated Software Design.
Related to this work is a never-ending list of bugs that we have found in the Eclipse JTDRE.  Why is this important?  Well, if you execute a script and 100s of bugs are introduced into your program (because JTDRE refactorings are not trust-worthy), you're (a) not likely to use scripting, (b) you can't use Eclipse JDTRE to manually introduce a pattern because these same bugs would be introduced, and most likely (c) you won't use Eclipse refactorings period if they're untrustworthy.  Here is our current list of bugs that we've found; as we discover more, we post them here.

Coming Attractions!

Other Refactoring Publications

All our publications on refactorings can be found can be found here.