A lot of folks who don’t know enough about AOP (Aspect Oriented Programming) feel that they can achieve the same results by using the decorator pattern. While AOP is similar in concept, there is a lot more that AOP can solve that a decorator pattern would be hard pressed to do. The GOF Decorator pattern requires either that some method be directly called or that the code that is decorated implements some common interface. This works if:
- You have control of the code base and/or architecture
- You only want to decorate a specific base class or interface
The pattern doesn’t work to well when have to start decorating classes that don’t adhere to the aforementioned conditions. You know, when those “new” requirements start trickling in after the the application has launched. And as usual, the requirements don’t quite mesh well with the existing architecture.
Keep in mind that I’m not advocating using AOP to compensate for a crappy architecture, but it sure can help :). But seriously, you can’t think of everything in your design phase. Eventually, someone is going throw you a curve that your design didn’t count on. I recently came across a problem in a reporting application where we needed to find out what some of the intermediate calculations were in order to debug a problem. The application was never designed to write out all of these values, since they would have been discarded anyway. Additionally, modifying the code would have taken a few days and potentially destabilized the code base. I ended up using JBoss AOP (note: not the app server) to write a few interceptors that collected these values. The application ran as normal, but these intermediate calculations were now captured. All was good, and it took me less than a day to implement.
My point is, a decorator pattern isn’t always feasible. I couldn’t retrofit a decorator pattern onto this app to do what I needed to do in such a short time frame. Sure AOP is a decorator in the abstract sense, but you can’t do everything with a decorator that AOP can.
Damnhandy 
Actually, I’ve resisted AOP in my applications, but only because my applications are not so much business logic instensive as UI intensive.
But here’s a question/idea: Could you use AOP to drop an extra layer of logic into an already-developed, already-tested, separately-maintained application that you are re-selling and customizing for each of your clients (Application Service Provider-style)? Sort of how you can write a web filter to run on top of a previously-written web application?
LikeLike
Actually, I’ve resisted AOP in my applications, but only because my applications are not so much business logic instensive as UI intensive.
But here’s a question/idea: Could you use AOP to drop an extra layer of logic into an already-developed, already-tested, separately-maintained application that you are re-selling and customizing for each of your clients (Application Service Provider-style)? Sort of how you can write a web filter to run on top of a previously-written web application?
LikeLike
David: I’m glad you’re watching his spelling too. It takes a damn village.
I vote that he makes a separate Java blog.
LikeLike
David: I’m glad you’re watching his spelling too. It takes a damn village.
I vote that he makes a separate Java blog.
LikeLike
Also, thank you for linking to me. I notice that your wife’s blog is slipping down in the rankings. Hey, I’m a married man!
LikeLike
Um. Perhaps you haven’t gotten a handle on this blogging thing yet. First, you misspelled “feasible,” and then you made the mistake of assuming that anyone cares about this AOP business. Let’s get to the juicy stuff!
LikeLike
Um. Perhaps you haven’t gotten a handle on this blogging thing yet. First, you misspelled “feasible,” and then you made the mistake of assuming that anyone cares about this AOP business. Let’s get to the juicy stuff!
LikeLike