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.