First, I agree with Kirill's assessment on most AOP work going on today. Clearly there is the opportunity for gross misuse of any tool, including AOP.
However, I don't agree with throwing the baby out with the bathwater. AOP is going to go through similar growing pains that any new tool or technology faces. I remember OO 15 years ago. Wow, talk about bad design! It took a long time, a lot of influence from the Smalltalk community, and . C++ was bashed on a regular basis due to "bad code," ignoring the significant amount of "good code" and design that was built with it (anyone remember MFC vs. OWL???).
IMHO, aspects have a place in the software space. They should be incorporated as part of the overall software architecture and design. Yes, that means it can be misused. It also means it can be used to solve problems, especially around those areas that are truly aspects, such as:
- Security
- Validation
- Persistence
- Assertions
Good aspects, IMHO link a good OO design to another. The coupling of a security model with a business model is poor OO design, IMHO (JAAS anyone?). However, if that's the only tool you're presented with, then you have to make do. AOP provides a good tool for decoupling Security, Persistence, etc from application and business models/layers, yet linking them in a concise, easily maintained manner.
I expect over time patterns and anti-patterns will emerge in the AOP space as architects, designers, and developers further understand what AOP is (implementing true aspects) and what it isn't (a easy way to get those pesky logging statements into code).
Designers eventually "got" OO. I expect they will eventually get aspects as well.
No comments:
Post a Comment