I just heard the comments of the posse and am quite disappointed. Not because they seem to dislike it (as it's up to everybody to build one's own opinion) but rather that the argumentatzion was build on a good bunch of halfknowledge. Here are my points:
1) AOP is a concept. So how can one blame a concept "overkill". This reminds me of late Pascal an C programmers not grasping object orientation and claiming that this would be overkill. As already stated, AOP targets crosscutting concerns that are - and here is the point - mostly of technical nature not directly related to the business domain problem you actually have to tackle. So AOP is a mean to distill problem domain code from the fuzzy technical stuff that buzzes around in average joe programmer's code. If you just take exception handling, transaction management, caching and logging/ tracing code out of your legacy code, how much time would you save on trying to understand what problem this code *actually* solves. Even more business related tasks, like notifications and so on can be effectively solved with AOP means. It simply aims to build more loosely coupled systems. 2) AOP is not widely adopted. Hey guys? Have you used an app server these days? Almost all app current servers provide technical services to hosted components by leveraging AOP means. So often times you use AOP without even noticing it? Which leads me to the next point... 3) Accessability: As AOP is a concept, the question of accessability is more one of the implementation. As you could have found out there are several ones. Spring container e.g. uses a proxy based approach that does not bother you with build time constraints or runtime JVM option requirements. Use the container and you (as already mentioned) probably use AOP without even knowing. There are a few other weaving options available (complie time, runtime...). 4) Fuzzyness because of indirection. Well... how many levels of indirection do we already have in the Java language? If this counted as an argument, we'd have to complain about a lot more things. *I* am really open to take this burden as it allows modularize my application, make it more extensible and helps distilling the code i have to write to solve my business problem from the one I have to write to plumb that stuff together. 5) Annotations replace(?) AOP. I don't know how you got into that but that was the point that made clear that a little more investigation would have been good before answering the question. One more time: AOP is a concept and leverages the notion of pointcuts to define *where* to apply a specific behaviour. They (in the an example case) can be formulated onto plain method signatures. That serves point 4, as the code that gets the advice applied does not know about that fact. Adressing that problem you typically use annotation *in conjunction* with AOP to achieve a more declarative style of adding functionality that is not directly related to the code to the code. @Transactional or its derivates are the perfect example. So this is not an either/or but rather a cooperation. 6) Tooling. AJDT is really a helper when it comes to make relations between advices and their targets visible. You can debug stuff seamlessly, see, where which advice get's applied and so on. Doesn't the whole Java space already rely on tooling? Wouldn't any newbie wonder when its method does not get executed because it was overriden by someone else? Ahh, we have markers in the IDE... we have @Override... I think you get my point. Phew... quite a lot point. I hope you don't get me wrong. It's totally okay to me for you guys to build opinion different than mine, but you shouldn't doom something a "tiny magic toy" without deeper knowledge on it. I guess someone badly informed could argue the same way on Scala, too: "Whoo... all that scary stuff!" :). One thing I entirely agree with you that AOP seems to be a Java related thing due to the limitations of the language. But I doubt that things are less obscure and fuzzy when implemented in other languages means (Groovy meta class stuff and so on=. Regards, Ollie On 23 Jul., 05:51, Alan Kent <[email protected]> wrote: > Jess Holle wrote: > > So what is AOP good for? It's a powerful tool for building certain > > types of library/framework capabilities. ... > > Just relating a personal experience, I had read various bits on Aspect > Oriented Programming (or aspects in general) but they always seemed to > be vague descriptions - "they are cross cutting concerns". Err, ok, but > like what does that really mean??? I never "got it". So just in case > anyone else is in the same camp of not quite getting the point of > aspects, I thought I would share an example that suddenly made it make > sense to me. If nothing else, this post might give others the enjoyment > of saying "gee this guy is just slow to understand isn't he!" ;-) > > I came across a concrete example recently in the Alfresco content > management system. (Not really programming, but it was a concrete > example that made sense to me.) Expressing in programming terms, in > Alfresco you can define a class hierarchy for different document types > (e.g. generic base class that stores an array of bytes representing the > file contents; a subclass say for Office documents with metadata > properties common to Word, Excel, and PowerPoint; then a subclass per > exact file format with additional properties specified to each file type > and maybe saying how to index the file contents appropriately). > Inheritance makes complete sense here. Now for aspects. Within an > Alfresco repository you might want *some* instances of documents also to > be under version control, or record management control. This is not per > document type - it "cuts across" different document types. Similarly > some instances of files maybe under Record Management control (e.g. > "this file cannot be deleted for 5 years"). So in Alfresco you can add > an aspect (in this case "records management") on a per instance basis. > The aspect is not part of the class hierarchy - but it does give the > instance more properties. > > I am not saying this is exactly the same as AspectJ - I have never used > AspectJ. I just found it helped me understand terms like "cross cutting > concern" in a much more concrete way. I now at a conceptual level read > "aspect" sort of like "Java interface", but one that can be added to > object instances at run time irrespective of what class they belong to. > > Well, I hope the above helps at least one other person out there! It > was a penny dropping moment for myself. > > Alan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
