Well there is a political undercurrent to this whole thing, but I'll save you from knowing about that part.

My view:

AOP is a work around for Java having neither multiple inheritence nor a language meta-model. The only real addition being a declarative application of said langauge meta-model.

What that means:

With Java reflection you can "get" the methods, constructors, fields, etc associated with a class. You can even "execute" them. You cannot however *redefine* the class or "put" fields, constructors, etc.

Audience:

The main audience for AOP itself is NOT the application developer. Meaning, you guys get to write business logic. Its really for the system developer. There is one exception for all of this which is security because it is a crosscutting concern which is both system-level and application-level.

Concrete examples:

In CMP 1.1 you had to make certain fields public so that the CMP engine could read them. However, since the CMP engine couldn't tell when they changed the lifecycle was quite concrete and all update statements had to be "set" on basically all fields. In CMP 2.0 these became abstract which limited some of the functionality one might have put in calculated fields, etc, but you could relay on the appserver to do the right thing with updates. in EJB3 persistence, you can have concrete setters or fields and just put a @ tag marking them as persistent. The appserver can automatically know when they have been changed or called. Why? Because AOP lets us add the necessary code through pre/post compilation or dynamic application of pointcuts.

Consider a Servlet.  Lets say you do this in a clustered environment:

//HTTPSession session = ...
Account account = new Account(request);
session.setAttribute("account",account);
account.setUserState(created);
....

Presently, Is the change to account (user state) replicated? Nope. You must call session.setAttribute("account",account) again to trigger replication. AOP gives us a way to express that we want state changes on "Account" to be replicated.

Moreover, consider complex object graphs! What if Account is several layers deep? Do you want the whole thing to trigger serialization? Wouldn't it be cool if you could just say which fields are important enough to watch when they change or specify default behavior?

Thats all AOP is. Most of you guys will just learn some new @annotation tags and leave the AOP to someone else. Its no more "harmful" than dynamic proxies. Forrester didn't research enough about the proper usecases and focused strictly on should *everyone* use AOP. That's pretty clueless "research". Directly programming your own aspects and pointcuts might be "harmful" for what BEA euphamised as the "corporate developer" doing every day stuff. Of course that would be silly, that is what OO is good for.

AOP fixes problems that OO "introduced"? I bet you former small talkers have an earful on why thats bull.

-Andy

David Spitz wrote:
Thought some of you might find this interesting...
http://developers.slashdot.org/developers/05/04/24/0343224.shtml?tid=156
(The actual Forrester document is $249 but the ./ discussion is still
interesting).
Sorry if it's a repost, I've been traveling.
David




------------------------------------------------------------------------

_______________________________________________
Juglist mailing list
[email protected]
http://trijug.org/mailman/listinfo/juglist_trijug.org



_______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org

Reply via email to