Summary
The weakness of Design Patterns is that the mainline of code may be obscured. "Refactoring to Aspects" may prove to be a better alternative.

Joshua Kerievsky has put together an interesting compilation titled "Refactoring To Patterns". At first glance, I had thought that this piece was more buzzword compliant than of practical value. However, after reading his "Stop Over-Engineering" article, I was prompted to take a more indepth look. Joshua writes:

Once my design skills had improved, I found myself using patterns in a different way: I began refactoring to patterns, instead of using them for up-front design or introducing them too early into my code. My new way of working with patterns emerged from my adoption of Extreme Programming design practices, which helped me avoid both over- and under-engineering.

Therefore, Design Patterns shouldn't be introduced upfront, but rather at a later stage in development. However, this practice points out a serious weakness of Design Patterns, that is the main line of code may be obscured. It's similar to the problems when you optimize your code for performance, it's one of the reasons why you should delay such optimizations.

A long time ago, Jiri Soukup wrote a book entitled "Taming C++". It was an extremely intriguing book. It had several claims about designs that went against conventional wisdom. One claim was that design patterns created too many cyclic dependencies and he proposed an alternative structure that was more manageable. The strategy was to introduce a new class called a "pattern class" that would in essence encapsulate the essence of the Design Pattern.

Fast forward to the 21st century, Jan Hannemann and Gregor Kiczales have put together a compilation of "GoF Design Patterns in Java and AspectJ". For the 23 GoF patterns, using AspectJ, they managed to remove the code-level dependecies from the participants in 17 cases. Aspects reduced the dependencies between its participants, as a side-effect it was not as intrusive as employing Design Patterns.

Although this is still an emerging area of study, refactoring your design to use "pattern classes" or "aspects" may be the appropriate approach to illuminate the main line of code and ultimately may lead to better manageability of complexity.

Talk Back!

Have an opinion? Be the first to post a comment about this weblog entry.

RSS Feed

If you'd like to be notified whenever Carlos Perez adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Carlos E. Perez has been an object-oriented practitioner for over a decade. He holds a Bachelor's Degree in Physics and a Master's Degree in Computer Science from the University of Massachusetts. He has polished his craft while working in IBM's Internet Division and IBM's TJ Watson Research Center in Hawthorne, New York. He now works for a startup 1/100,000th the size of his former employer. He writes about topics covering emerging aspect and object oriented paradigms, loosely coupled architecture, open source projects and Java evangelism.