Design Patterns in AOP - Jan Hannemann 2002+: "Aspect-Oriented Design Pattern Implementations
Language-dependence of Design Patterns
Software design patterns offer flexible solutions to common software development problems. Each pattern is comprised of a number of parts, including purpose/intent, applicability, structure, and sample implementations. A number of patterns involve crosscutting structures in the relationship between roles in the pattern and classes in each instance of the pattern.
When the software design patterns were first identified, the sample implementations were geared to the current state of the art in object-oriented languages. Since then, aspect-oriented programming has been proposed as a means of modularizing crosscutting concerns in software. Other work has shown that the implementation language affects pattern implementation, which makes it natural to explore the effect of aspect-oriented programming techniques on the implementation of the GoF patterns.
GoF Design Patterns in Java and AspectJ
As an initial experiment we chose to develop and compare Java and AspectJ implementations of the 23 GoF patterns. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Java plus aspects. By focusing on the GoF patterns, we are keeping the purpose, intent, and applicability of 23 well-known patterns, and only allowing the solution structure and solution implementation to change. So we are not discovering new patterns, but simply working out how implementations of the GoF patterns can be handled using a new implementation tool.
For the 23 patterns, we managed to remove the code-level dependencies from the participants in 17 cases. For 12 of these, we developed reusable implementations that can be integrated into software systems as 'library pattern aspects'. The examples illustrate differences in Java and AspectJ implementations
Our results indicate that using AspectJ improves the implementation of many GoF patterns. In some cases this is reflected in a new solution structure with fewer or different participants; in other cases, the only the implementation of the classes in the originally proposed solution changes (for example by moving pattern code from the participants into an aspect) . "