AOP for Inter-Application Variation!

Today, Dave Ross made some very interesting comments on the CFCDev list based on a suggestion by Adam Haskell which opened my eyes to a whole new family of use cases for leveraging AOP in application design . . .

The topic was raised by Adam who was trying to decide whether to use aspects to implement new business rules for an existing shopping application. At first it seemed to me that he should really just add the rules to his business objects as the business rules clearly belonged within the model and were not cross cutting concerns.

However, when he explained that he’d like to keep the business rules out of the components so he could use the core components in other applications that didn’t have those industry specific business rules, AOP started to look more attractive – tactically if not strategically.

The fallback position for extending components is always sub-classing (inheritance), but in the spirit of favoring composition over inheritance, even though inheritance would not be “wrong” in this case, it was worth exploring other alternatives.

The decorator pattern is often used to extend the functionality of a component, but requires a concrete decorator class to be written for each class that requires decorating.

Dave Ross suggested that AOP could well be an appropriate solution because while the business rules were not a cross cutting concern (they should be implemented by some kind of rules class within the model), the initiation of the business rules (assuming they affected multiple classes) could well be.

Given that the project specific shopping cart clearly IS A shopping cart, I think inheritance might be a simple and appropriate solution, and if the business rules only affect one or two components, writing concrete application specific decorators might be a simpler and hence more maintainable approach than AOP for this particular use case. But for me, looking at AOP as a way of extending/customizing variations of an application (i.e. implementing a software product line – the topic of our next post) was a fascinating and relatively lightweight dynamic alternative to using a code generator to build custom classes for each variation.