Hello everybody! I have to say a very good discussion about AOP and its pro and cons!
After some experience I mostly agree with the sceptic view of Jess: Leave AOP to the frameworkers. When pondering about the different mindsets and attitudes towards AOP, I spontaneously wrote this (please do not take too seriously): Which kind of AOP hater are you? ;-) To me the AOP antagonists can be divided into three different groups: 1. The Innocent These are the people who do not see the point in attempting to manage the complexity of crosscutting concerns. They value the costs and risks of bloated, repetitive code as non-critical for their project success. When you have a big team of not so top-notch developers and you need only to care about short-term performance (say getting out a first release), this is a perfectly viable strategy (with known downsides). Of course, many times you find yourself in such a situation, even if you do care. And then there is the group of Java developers, who never did anything else but Java and who still think that for every decently challenging task on hand you have to develop against at least a dozen wickedly complex APIs, which you somehow have to repeat in every single business class. Wonder how much are left of those? Too many, I guess. - Please, learn a scripting language! 2. The Clever Ones (really!) The second group is fed up with LazyInitializationException, EJB 2 and leaving all the fancy stuff to the RubyOnRails kids. They want clean and simple, but with the complexity there under the hood. They want to persist, transact, catch, log, notify, … and still have a business class, which looks like a junior java programmer’s first POJO. It seems they want to take a shower without getting wet. This sounds like magic - and it is! Whether it is the doable sort is still wildly debated. But some progress has been made (in and out the Java Community) with many seemingly different approaches: code generation, IOC, Dynamic Proxy, AOP, Meta Programming, Mixin, low-level byte code enhancement, etc. To me all those approaches have one thing in common: They attempt to enhance a class or a source base outside of the direct reach of the (application) developer who wrote that class. They somehow put in the “magic” without bothering (too much) the poor bastard who only wanted to write a class which manages taxes. And what is important, they do it in a transparent way: The app developer can still come back to his original unbloated class, change this and that and not have it explode in their faces. Of course, transparency is relative. Depending on the approach, not everything might work too smoothly: Debugging, performance, deploying and too much transparency might all get you in trouble. But the biggest problem probably is the language Java itself. It is statically typed. Meaning that with many approaches the very thing we want to achieve (post-enhancing what must not change) is evil. We want to do black magic. And many Java developers still think that they would have to take unbearable risks when loosening up Java’s ability to type check everything at compile-time. Of course, they already take those risks everyday (or someone in the background quietly bends the rules of nature for them). But if you actually are in group 2, your need is great: You have accepted to resort to drastic measures. Only, you disagree about the right kind of drastic. You have good reasons to refrain from AOP: Tooling, deployment woes, performance issues, lack of transparency, etc. To me, this is a perfectly acceptable point of view. You have realized what the problem is, but you just found other remedies more suitable to your tasks. Let us swap our findings and see what gives. 3. Those who always knew (aka The Concerned) The third group has recognized the worries that drive group 2, went into the laboratory, fumbled with the mighty mojo and got themselves badly burned. Or more likely, sent their minions into the lab and simply waited for the cry. The deficiencies that concepts like AOP or Meta Programming attempt to overcome - sort of the sonic barrier of invariant source code – should not be easily tempered with. But then again quite a lot of developers should be stripped of the right to use inheritance. They simply have not understood when not to use it. Thus, yes, apply with caution. Know the risks. Search for the big wins. Or come up with a better way! Best, Achim. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
