AOP

[Pradeep bhatt]

Hi all,
Can some one tell me what is Ascpect Oriented Programming? How is different from OOP S.
Thanks
Pradeep

[Hung Tang]

AOP allows you to implement cross-cutting concerns in a highly-modular fashion. It is my understanding that AOP does not replace OOP but rather complements it. AOP is mostly about improving modularity in code designs which is always a good thing.
Currently AspectJ is the leading framework for AOP implementation for Java. But there are others such as AspectWerkz and Nanning, albeit not as feature rich as AspectJ.
AspectJ is built on top of Java adding a few new concepts to the language such as introductions, joinpoints, pointcuts, and advices. An Aspect brings all these together to enable AOP implementations in your design.
For me in explaining AOP to someone, I would just tell them to think of "interceptors" and that each interceptor picks out a specific execution point (whether it'll be at class level, method level, constructor level, exception level, etc) and do something useful at those points. And I would also tell him AOP is just a stack of interceptors, encapsulated into something called an "aspect". Of course, AOP is not as simple this and it'll be the wrong thing to tell to someone if they have any idea of what AOP is =)
To see how this can be useful, AOP can be used to implement Design By Contract where an Aspect can be created to check for a particular method (or methods) for proper argument values. Logging is another famous example where AOP can be used to implement that particular functionality. Classes will not need to know anything about logging and can just concentrate on what they are responsible for. The key point is that Aspects impose behaviour on classes; classes don't know a thing about "aspects"
Hope this makes some sense.
More information can be obtained at AspectJ's web site.
[ August 06, 2003: Message edited by: Hung Tang ]

[Pradeep bhatt]

What is cross-cutting concerns?

[norman richards]

Imagine you are writing an class and you need to write a method to read data from a database. That task, reading the data, is the primary concern of the class. Now, to use standard AOP examples, suppose you need to check if the user is allowed to access the database before reading the data. Or maybe you need to check each individual data item after reading it to make sure the user is allowed to see those items. Or, perhaps you simply need to log your database access.
These other functions are secondary concerns. They aren't really what your readData() method is concerned with, but you still have to spend a lot of time when writing the method to deal with them.
Sometimes these secondary concerns show up over and over in the code base. Maybe you have a number of places where you have to think about security checks or logging or other secondary concerns. This is what is meant by "cross cutting" concerns. You can visualize this by imagining your methods as vertical bars. Then imagine a horizontal bar (labelled "logging" cutting across all of them. The secondary concern of logging cuts across all of your primary concerns. (like reading data from the database)

[Ashik Uzzaman]

Great explanation Norman!

[Ilja Preuss]

Originally posted by norman richards:
Sometimes these secondary concerns show up over and over in the code base. Maybe you have a number of places where you have to think about security checks or logging or other secondary concerns. This is what is meant by "cross cutting" concerns. You can visualize this by imagining your methods as vertical bars. Then imagine a horizontal bar (labelled "logging" cutting across all of them. The secondary concern of logging cuts across all of your primary concerns. (like reading data from the database)

Interestingly, I have just implemented something similar (logging RMI access) without AOP by using a Dynamic Proxy. It was quite straight forward...

[Brian Kapellusch]

Using a Dynamic Proxy assumes that the client is calling a method on an interface. I was not so fortunate as to "think ahead" when I was designing my first application at my current employer.

[Ilja Preuss]

Originally posted by Brian Kapellusch:
Using a Dynamic Proxy assumes that the client is calling a method on an interface. I was not so fortunate as to "think ahead" when I was designing my first application at my current employer.

Sometimes you are fortunate enough that you can introduce the interface later, when you need it. Of course it's not always possible (for example when working on a published API)...

[Stan James]

A neat part of AOP is the little language they use to identify the intercept points. You can identify a spot like the beginning of every method, or the beginning of methods that start with "get" or methods that have int,int parameters or other points in the middle or just prior to return, to an extremely fine grained level of detail. Then you can say what to inject at this point. Logging and security checks were mentioned above. Sounds pretty cool.
I have real doubts about how one comprehends a system with a lot of AOP thrown in. It's tough enough getting your head around static and dynamic object models; throwing in things you can't even see in the code sounds frightening. It won't be sufficient to read a method to know what it does; you must also somehow discover and understand all the AOP intercepts that might affect the method. Yikes!

[Phil Chuang]

Can AOP determine who the caller is?
Say I wanted to protect all the "set" methods of a bean, but in such a way that only a few classes had access to it - with AOP, would I be able to code an intercept such that it would be able to check what class is calling the method?

[Brian Kapellusch]

yes

[Ilja Preuss]

Originally posted by Stan James:
A neat part of AOP is the little language they use to identify the intercept points. You can identify a spot like the beginning of every method, or the beginning of methods that start with "get" or methods that have int,int parameters or other points in the middle or just prior to return, to an extremely fine grained level of detail.

That's actually what I am most sceptic about regarding AspectJ defining join points based on method *names*. I find it to be somewhat dangerous being able to change the behaviour of a method *by renaming it*!
There are other implementations, which use other mechanics of defining join points, though.

It won't be sufficient to read a method to know what it does; you must also somehow discover and understand all the AOP intercepts that might affect the method. Yikes![/QB]

I guess a good IDE (like the plugin for Eclipse) could be of great help here.

[Maulin Vasavada]

Hi all,
This discussion seems to help me
I'll explain my problem and I think that this AOP thing is the one I need. Though I see the Logger mentioned already for "cutting concerns" I want to confirm it...
I have a simple class called Debug and that does log a provided message to pre-configured log destination. Now, in my application I don't want to create Debug object in every class. I just want that "somehow magically" (may be this is too much but I am just throwing my mind here) it should log System.out or something to log via Debug object...
I might sound complete idiot but I just want to see if there is some way to solve this. The reason I want to do this is I have some pre-existing classes which accepts "Debug" object as argument!!! Now that doesn't make any sense to me at all. May be I can create a singleton and then make every object have private reference or just put static log() method in Debug....I donno I am confused..
How does the Logger thing would work with AOP? Can anybody point to some help?
Regards
Maulin

[manish ahuja]

Hey Guys

This was really good info.
Can someone list pointers to some white papers & docs where i can get more info on AOP

[Pradeep bhatt]

Manish,

Here are some links

http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/
http://www.onjava.com/pub/a/onjava/2004/01/14/aop.html
http://eclipse.org/aspectj/
[ November 19, 2004: Message edited by: Pradeep Bhat ]

[Alexandru Popescu]

Originally posted by Hung Tang:
Currently AspectJ is the leading framework for AOP implementation for Java. But there are others such as AspectWerkz and Nanning, albeit not as feature rich as AspectJ.

I think this aspect ( ) is not so important. I guess what is very important in this matter is that some solutions are pure java others are bringinning new syntactical contructions for enabling AOP implementation.

AspectJ is built on top of Java adding a few new concepts to the language such as introductions, joinpoints, pointcuts, and advices. An Aspect brings all these together to enable AOP implementations in your design.

In fact all of those are the definitions of AOP theory.

For me in explaining AOP to someone, I would just tell them to think of "interceptors" and that each interceptor picks out a specific execution point (whether it'll be at class level, method level, constructor level, exception level, etc) and do something useful at those points.

This is explanation might create confusion (look for the JBossAOP first tries). AOP is about - as you already said - crosscutting concerns. The way it is implemented is some other discussion.

./pope

[Alexandru Popescu]

Originally posted by Pradeep Bhat:
What is cross-cutting concerns?

Everything starts with describing an application in concern terms (persistence, validation, logging, security, etc). Working with objects (in OOP without AOP) will result in creating some entities that must manage concerns that are not belonging to itself (for example: logging is not specific to a model class, or to a service). AOP was created/imagined for allowing solving these concerns (cross-cutting ) also in a modular way.

./pope

[Pradeep bhatt]

Does application performance go down in AOP when compared to plain OOP? Isn't there an overhead in AOP because the calls are intercepted?

[Alexandru Popescu]

Originally posted by Ilja Preuss:


Interestingly, I have just implemented something similar (logging RMI access) without AOP by using a Dynamic Proxy. It was quite straight forward...

Who is saying this is not a form of AOP? . It depends on what do you think AOP is.

./pope

[Alexandru Popescu]

Originally posted by Ilja Preuss:

That's actually what I am most sceptic about regarding AspectJ defining join points based on method *names*.

Unfortunately this is a common misunderstanding and a miss-usage. Indeed you are defining the joinpoints using some rules (including rules on names), but I would say this is the same way as you call a method on another object for example (using a naming convention).

Originally posted by Ilja Preuss:

I find it to be somewhat dangerous being able to change the behaviour of a method *by renaming it*!

The same concern would exist for refactorings, and still it is not there. It is a matter of tools and experience.

./pope

[Alexandru Popescu]

Originally posted by Pradeep Bhat:
Does application performance go down in AOP when compared to plain OOP? Isn't there an overhead in AOP because the calls are intercepted?

It is highly dependent on the way you are implementing the aspects and also on the complexity of required information in joinpoints. It is indeed a possible problem of the solutions using interception, but some of the most advanced AOP implementation (AspectJ, AspectWerkz) are far away from this.

./pope

[Pradeep bhatt]

Originally posted by Ali Pope:


It is highly dependent on the way you are implementing the aspects and also on the complexity of required information in joinpoints. It is indeed a possible problem of the solutions using interception, but some of the most advanced AOP implementation (AspectJ, AspectWerkz) are far away from this.

./pope

Thanks Ali. You seem to have worked a lot on AOP

[Ilja Preuss]

Originally posted by Ali Pope:
Who is saying this is not a form of AOP? . It depends on what do you think AOP is.

Good point. It's probably similar to a procedural programmer saying "but I can do the same using function pointers" when he discusses OOP.

And in fact he would be right. It's just that in OO languages it's so much easier to do that it fundamentally changes the way you program.

Of course that could be true for AOP, too. I guess it's still too early to say. For now I'd call myself an "interested sceptic", and the main reason for not having tried it yet is that there are just so many other things out there which currently have a slightly higher priority to me. When the tools get better and the communities experience grows (it will be interesting to see wether AOP patterns emerge), that might change...

[Gerald Davis]

Do yoou think AOP favours weak typed or strongly typed languages

[Alexandru Popescu]

Ilja good luck with your other priorities and I hope that by the time you will evaluate AOP we will be able to offer more than you expect to find .

Gerard, I cannot see any direct link between AOP and weak/strong typed languages.

./pope