One concrete use of AOP that I've seen that actually makes a lot of sense is Spring's declarative transactions. They are implemented using AOP so, for example all of your DAOs can be configured to be transactional.
On Jul 23, 3:56 am, Jess Holle <[email protected]> wrote: > I don't actually have any flames for the Posse's AOP response, but Dick > predicted flames, so I had to put that in the subject :-) > > My own take is that unbridled AOP defies all normal programmer > understanding. As one or more of the Posse said, looking at the code > and finding it doing something quite different is far too magical. This > defies comprehension, maintenance, and troubleshooting. > > There certainly /were /use cases for AOP, but many of these have been > tackled by libraries/frameworks that use AOP but do so in a bridled > fashion where a combination of annotations and > limited/restrained/controlled magic make the results predictable and > comprehensible. > > Use cases for raw AOP, as opposed to AOP tamed and targeted by a > library/framework, are very limited. They do exist, but fall into > categories like dynamic troubleshooting, rather than architecting > software. For instance, if you need to add logging (that no one foresaw > the need for) to a production system without changing any existing class > files, AOP and load-time weaving can be just the ticket. Of course even > there btrace seems like a more targeted and controlled than raw AOP > solutions like AspectJ -- though AspectJ certainly works here. > Similarly, while one could use raw AOP for mocking in unit tests, > jmockit is more targeted, controlled and high-level. > > So what is AOP good for? It's a powerful tool for building certain > types of library/framework capabilities. Also there are those rare > cases where you want to make a set of magical changes across a set of > classes where you don't need or want this exposed for comprehension, > maintenance, or troubleshooting -- but that's really, really rare. In > both of these use cases, AspectJ seems to fail -- the result of its > changes are too heavy and clunky (adding numerous levels to call stacks > for around advice, for instance) and its weaving performance is > sub-optimal. Lower-level byte-code weaving libraries like ASM, > Javassist, and cglib are critical underpinnings to various higher-level > libraries, frameworks, and containers in use today, however (just take a > look inside many a jar to find a repackaged ASM inside...) > > -- > Jess Holle --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
