In a previous installment I discussed the practice of Refactoring to Patterns.  That is, 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, its 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 had too many cyclic dependencies and he proposed an alternative structure that was more acyclic.  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, they managed to remove the code-level dependecies from the participants in 17 cases.  Aspects reduce the dependencies between its participants, furthermore its not as intrusive as 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. 

::  Comments at Artima ::