OO and AOP

[Alexandru Popescu]

I would like to know what do you think about:

AOP is just the stuff that makes OOP work.

./pope

[Alexandru Popescu]

It seems that the interest in AOP is not high enough here .

./pope

[Pradeep bhatt]

AOP is just the stuff that makes OOP work

Who said this ? Doesn't OOP work without AOP ? It works.

AOP complements OOP.
[ November 19, 2004: Message edited by: Pradeep Bhat ]

[Pradeep bhatt]

Which is better - AspectJ or AspectWerkz ?
I think AspectJ was popular some time back.
Thanks

[Alexandru Popescu]

Originally posted by Pradeep Bhat:


Who said this ? Doesn't OOP work without AOP ? It works.

AOP complements OOP.

[ November 19, 2004: Message edited by: Pradeep Bhat ]

Unfortunately I cannot remember this, but I really believe it .

./pope

[Marlene Miller]

It seems that the interest in AOP is not high enough here

Hi ./pope,

I think Valentin is interested in AOP.

Regards, Marlene

[Gerald Davis]

I wonder how AOP relates to Procedural programming

[Lasse Koskela]

Originally posted by Marlene Miller:
I think Valentin is interested in AOP.

Interested? In love, I'd say.

The rumor has it that Val is working on something that might become an article or two in the journal...

[Madhav Lakkapragada]

AOP huh?
Anyone care to expand that for me, please.

- m

[Alexandru Popescu]

Madhav here is another thread that made some intro.

./pope

[Alexandru Popescu]

Originally posted by Lasse Koskela:

Interested? In love, I'd say.

Have you used it on real project till now? If not why? If yes again why?

./pope

ps: I am trying to figure this out because I feel that the general understanding in what regards AOP is somewhere/somehow wrong. As always when something new comes to life (in fact AOP is around for at least 5 years ), the rumours are moving around with high speed, and these rumours are not always (I might say that almost never) true.

[Lasse Koskela]

Originally posted by Madhav Lakkapragada:
AOP huh?
Anyone care to expand that for me, please.

Abuse Of Power. No, seriously, it stands for Aspect Oriented Programming.

[Lasse Koskela]

Originally posted by Ali Pope:
Have you used it on real project till now? If not why? If yes again why?

Ah. A communication problem. I meant that Val is in love with AOP, not me. Well, I might be but I haven't really used it beyond trying out a couple of exercises and reading a bit about it.

(PS. I can't believe you wrote 2 posts while I was googling for a good link to go with "aspect oriented programming"... And I didn't even find one...)

[Marlene Miller]

Interested? In love, I'd say.

Yes, Philippe told me Val is very experienced in AOP.

[Alexandru Popescu]

Originally posted by Lasse Koskela:

(PS. I can't believe you wrote 2 posts while I was googling for a good link to go with "aspect oriented programming"... And I didn't even find one...)

Probably I think fast and I write faster ... don't know .

./pope

[Jeanne Boyarsky]

We've looked into AOP, but we haven't found any practical applications (besides logging.) Since our code generator writes the log statements for us, AOP isn't worth it for that.

Other examples I've seen are transaction and security support, but the J2EE container handles those. I guess we are still waiting for a good application.

[Alexandru Popescu]

Have you checked this: link?
What do you think?

./pope

[Ilja Preuss]

Originally posted by Ali Pope:

Unfortunately I cannot remember this, but I really believe it .

Than perhaps you can explain it for me - because I don't get it...

[Ilja Preuss]

Originally posted by Ali Pope:
Have you checked this: link?
What do you think?

I only read until I hit the sentence "As a preamble I would say that in order to be able to test some parts of the product a developer would need a very long/complex/repetitive fixture."

Well, a "very long/complex/repetitive fixture" is a code smell, telling you that your design wants to be refactored to be easier to test.

I will continue reading the article should I ever come into a situation where I don't find a way to do that...

[Ilja Preuss]

Originally posted by Jeanne Boyarsky:
We've looked into AOP, but we haven't found any practical applications (besides logging.)

Same here. At least none that couldn't be done as effectively with pure OOP.

[Gerald Davis]

Then it is settled then AOP not worth the effert at this stage. Mind you, guys would say that about Procedural programming to.

[Alexandru Popescu]

Well, a "very long/complex/repetitive fixture" is a code smell, telling you that your design wants to be refactored to be easier to test.

I would say that in maybe 99% this is true, but the case I was investigating is exactly the rest of 1%. I know that there are points where I could reduce the complexity, but finally the idea will remain. I have also evaluated at that point the mocking perpective which helped me a lot to refactor but still... believe me I am right on that .

Gerald I wouldn't jump so far. If you would follow mailing list of the AspectJ and/or AspectWerkz you would see that there a lots of real products already taking advantage from AOP.

./pope

[Jeanne Boyarsky]

Well, a "very long/complex/repetitive fixture" is a code smell, telling you that your design wants to be refactored to be easier to test.

In keeping with this week's theme, this could also happen if you try to write a test for a legacy class that is not written a way ammenable to testing. I do agree that it is better to refactor the code (once you have a working test) than use AOP to hide the problem.

Ali,
Could you give some examples of what AOP is used for in practice. I can see uses if an application is not running on an application server - the support for transactions, security, ... I don't have anything against AOP. It's just finding a good use.

[Alexandru Popescu]

Two nice examples of usage:

assuring the correct usage of Swing threading

management of parent-child relations with Hibernate (you must always code 2 steps: add child to parent, set parent to child; with AOP you just need to do one side)

./pope

[Jeanne Boyarsky]

Ali,
Thanks for the examples.

I don't use Swing, but the first one looks like it could be extended to do various forms of static analysis. We currently have a tool for that, so we wouldn't use AOP directly here. It does seem like something the tool or IDE providers could use to enforce coding rules.

The second one is interesting. It creates less redundant code. This is something I can see looking out for when trying to find potential AOP usage. Most redundant code can be refactored away, but if I find some that can't I'll keep this in mind.

[Alexandru Popescu]

I was very short for the 1st example . It is not a static test, but rather something that will catch bad usages of Swing threading and assures everything is run in the correct thread. As you may know quite a few drawing methods are thread safe, and this aspect is based on this idea. It will go for any other paint/draw/redraw method and check if it is run on the good thread, otherwise it will run the job using the SwingUtilities.invokeLater(). In order to conclude, it is not a checker, but a runtime aspect.

As regards the 2nd, you will not be able to refactor as those (coding) constraints are imposed by Hibernate .

./pope

[Gerald Davis]

Originally posted by Ali Pope:


I would say that in maybe 99% this is true, but the case I was investigating is exactly the rest of 1%. I know that there are points where I could reduce the complexity, but finally the idea will remain. I have also evaluated at that point the mocking perpective which helped me a lot to refactor but still... believe me I am right on that .

Gerald I wouldn't jump so far. If you would follow mailing list of the AspectJ and/or AspectWerkz you would see that there a lots of real products already taking advantage from AOP.

./pope

Absolutley correct dude

[Jeanne Boyarsky]

Originally posted by Ali Pope:
I was very short for the 1st example . It is not a static test, but rather something that will catch bad usages of Swing threading and assures everything is run in the correct thread. As you may know quite a few drawing methods are thread safe, and this aspect is based on this idea. It will go for any other paint/draw/redraw method and check if it is run on the good thread, otherwise it will run the job using the SwingUtilities.invokeLater(). In order to conclude, it is not a checker, but a runtime aspect.

As regards the 2nd, you will not be able to refactor as those (coding) constraints are imposed by Hibernate .

./pope

Ali,
Thanks for clarifying #1.

For #2, I haven't use Hibernate, but the idea is valuable for similar code.